One system, four portals, because one screen served nobody.
Solika Arts is a creative arts studio in Nairobi. I ran the public website and the four portal system behind it as two products rather than one project, because four audiences needed four answers.
Role
Product lead and designer
Timeline
2025 to 2026, in launch
Team
A product owner, a developer and a social lead, run by me
Live
solikaarts.com ↗
01
The problem
Solika Arts had no online presence at all. Parents couldn't see class details or book a session, so everything ran on word of mouth. That's two problems rather than one: a studio with nothing public to point at, and a back office running on spreadsheets.
The studio runs children's and adult art classes out of a mall in Nairobi. Terms, class sizes, instructors, attendance and payment lived in spreadsheets and in one founder's head. That works until the studio grows, and then it stops working all at once.
The awkward part was never the data. It was that an admin, a parent, an instructor and an adult student each need a different thing out of the same rows.
02
What I did
I treated the site and the system as two products, not one project
The public page and the back office answer different questions for different people. The site has to make a warm, in person studio legible to a parent who has never walked in. The system has to make a term of admin survivable. Designing them as one thing would have compromised both, so they share a brand and nothing else.
I built four portals instead of one dashboard with role switches
One interface with permissions behind it would have been cheaper to build and worse to use. Each audience gets its own entry, its own vocabulary, and only the actions it can actually take.
I turned the bug list into a triaged product rather than a chat thread
Issues arrive through a form with owner and severity attached, so the developer receives a brief rather than a message, and nothing is lost between calls.
One screen built to serve four audiences serves none of them.
03
How I ran it
I ran a product owner, a developer and a social lead across two products at once, in another country and another time zone, so the process had to take out as much back and forth as it could.
Requests and issues arrive through forms rather than messages, so each one lands with the fields the developer needs already filled in. Seven issues were triaged with an owner and a severity against each, and the one that blocked the launch date went from reported to fixed in a day, because it arrived complete.
Every area of the system is a page with the same shell: fixed navigation beside the content, the same metric tiles, the same table underneath. That's a delivery decision as much as a design one, because it means a new area costs hours rather than days.
04
The journey
There are two journeys here because there are two products. A parent arrives on the public site knowing nothing about the studio, and an admin arrives at the back office already inside a term.
The public site is four doors and nothing deeper. Home carries the vision and a preview of the classes, offerings answers what's taught and what it costs, the schedule shows the live weekly calendar with class times, and contact closes it. Book a class sits across all four rather than living on one of them, because the only action that matters should never be more than a tap away from wherever a parent happens to be reading.
The back office is where that structure earns its keep. Terms, class categories, instructor profiles and enrolment sit across the four portals, and each audience only ever sees its own slice of them in its own vocabulary. The shell around each page then stays identical from portal to portal, so an instructor who has learned one screen has learned all of them.
Checkout is the one step I didn't control. It runs on the studio's own mobile money account, and the go live date moved when that did.
The most useful thing I learned about this product arrived after it shipped. The studio owner came back and told me the hardest part of her week wasn't the scheduling at all, it was the messages running between parents, teachers and her, which the build had never touched. That's the next thing to design, and it came from someone using the product rather than from anything in the brief.
05
What shipped
The public site carries the studio’s vision, the class offerings, a live weekly schedule and a persistent book a class route, and it was designed and built in Framer.
Behind it sit four portals covering admin, parent, instructor and adult student, with terms, class categories, instructor profiles and enrolment, plus a hub carrying the contract, the rates, the request forms and the issue board in one place.
Go live is held on the studio’s own mobile payment account, which is the one dependency that was never mine to clear.
06
Impact
Portals, one per audience
4
Issues triaged with owner and severity
7
Reported to fixed on the blocking date bug
1 day
Products for one studio, the site and the system
2
07
The work
The brief, the problem and the solution, the visual direction, the project timeline, the design process, the information architecture, the full homepage scroll, the weekly schedule, the offerings page, and the mobile experience.
08
Go deeper
Design system and Figma
All four portals run off one token set, so a change to a status colour or a card lands in all four at once, rather than in four places at four different times.
Build and handover
It’s a web dashboard on the studio’s own domain with mobile money at checkout, and a workspace holding the contract, the rate card, the request forms and the issue board, so the studio reads its own terms in the same place it reports a bug.
More
All work
→
