YONA · Product design engagement · Nairobi
From managing appointments to running a business
YONA is a Kenyan startup building booking and business software for service businesses — salons, barbershops and spas. I came in as product designer to take it from a booking tool to a platform that could run the whole business.
- businesses mapped in discovery
- 2
- roles served — owner, cashier, staff
- 3
- pillars in the final architecture
- 5
- current stage
- In pilot
01 · The opportunity
The Business Behind the Booking
A salon is not a simple business. Behind every appointment sits a web of dependencies — staff schedules, service pricing and duration, commission structures, client preferences, payment collection. The brief that came to me was a booking product. What the discovery work showed was that booking was the smallest part of the problem: these businesses were losing time and money in everything that happened around the appointment.
02 · Discovery
Mapping how two real businesses actually run
Research method
I sat with two business owners and mapped their end-to-end journeys. We walked through every step from booking arrival to payment collection, then played back the flows to validate them. This was participatory playback/validation, not a formal co-creation workshop, but it gave us the operational reality of each business.
Comparative journeys
01.
The owner who works the chair
A booking arrives by call or WhatsApp.
The owner runs the session herself, writes it down afterwards, takes payment in cash or mobile money, and notes her commission by hand.
Operational reality
Nothing is recorded until the day is over — and often not then.
02.
The business with a cashier
Bookings land the same way, but the money takes a longer route.
The cashier records the session, works out the commission, and pays the staff. The cashier then reconciles with the owner.
Operational reality
The same appointment passes through three pairs of hands before anyone knows what it earned.
03.
The owner with more than one branch
Branches consolidate monthly and send money up.
Until that happens, the owner’s only view of a second location is a WhatsApp message or a spreadsheet someone remembers to update.
Operational reality
A branch can have a bad month and the owner will not know until the money arrives.
Validated insight
I mapped end-to-end journeys with two business owners, then validated the flows with them. The key takeaway: the same booking follows a completely different path depending on who handles the money. This insight transformed owner, cashier, and staff from permission levels into three distinct roles in the architecture.
Design consequence
Runs the session and records the day
Needs a simple, immediate view of bookings, cash taken, and commission earned.
Records sessions and reconciles money
Needs a workflow that captures every payment, calculates commission, and keeps the owner informed.
Delivers the service and earns commission
Needs visibility into upcoming work, completed sessions, and earnings without managing the cash flow.
YONA needed to be more than a booking app. It needed to become the operating system for the business itself.
The product architecture came from understanding the business, not from studying other apps.
04 · Information architecture
Structuring the Product
YONA is structured around five interconnected pillars accessible from a persistent bottom navigation. The home dashboard synthesises them into a single view.
05 · Wireframes to interface
From Lo-fi to Pixel-Perfect
The design process moved from low-fidelity wireframes to high-fidelity screens. Lo-fi explorations established navigation patterns, content hierarchy, and core flows before any visual design decisions were made.
Lo-fi wireframes
06 · Solving real-world transactions
Solving Real-World Transactions
Designing for how money actually moves, not just how screens look.
The most complex design hurdle in YONA wasn’t mapping the calendar — it was solving the transaction flow.
As a designer, the initial instinct is a clean digital toggle: service done → marked as paid → earnings updated. But real-world field research blew that assumption apart. In a busy salon or studio, transactions are rarely a single button tap. Money splits across multiple channels — M-Pesa code confirmations, cash handed over at the front desk, bank transfers, and tips distributed separately. And the person running the session isn’t always the one reconciling the cash drawer.
The solution: a granular transaction flow starting from the Services Summary (handling tips, discounts, and client loyalty points), moving into Payment Details (explicitly separating M-Pesa verification, cash collection checks, and bank transfers), and culminating in a Success Screen that cleanly breaks down net earnings versus commission deducted. This transformed YONA from a simple status tracker into a reliable ledger that mirrors actual salon operations.
07 · The product
A Business Platform, Not Just a Booking App
The final product brings together five interconnected pillars — Home, Bookings, Earnings, Clients, and More — into a unified experience that serves owners, managers, and staff.
See it in motion
YONA, walked through
