Troski (2026)
Version 2 of a live transit app for Accra commuters, designed for Troski Technologies: see your queue before you leave, find the fastest way there, and pay at the bus door.
Client
Troski Technologies (version 2; version 1 is live and not my design)
Role
Lead Product Designer, solo: PRD, field research, IA, UI, visual language, motion, specs and handoff
Timeline
7 weeks, from April 2026
Platform
Mobile App · iOS & Android
The Challenge
What needed solving.
Most of Accra moves by trotro, the privately run minibuses, and the system runs on guesswork. You can't see a queue until you're standing in it, fares are cash-only and rarely exact, and a cross-town trip can mean a bus, an okada and a taxi with nothing to say which combination is fastest.
Troski's version 1, live on iOS and Android, is a community app built on riders reporting fares, queues and traffic. Samed Walker, the founder, asked me to design version 2: order a ride from Troski, check traffic, check queues from live data, and know how close the next bus is. We agreed to judge it by hitting the launch date and getting five Troski buses running for a live demo.
The Approach
How I solved it.
I built version 2 around three promises: make the wait visible before you leave home, replace loose change with a wallet that works at the bus door, and let one search plan a trip across every mode in the city, from bus and okada to train, taxi, van and charter.
Key Insights
What the research told me.
01 · Finding
The wait is the whole anxiety
23 of 30 riders interviewed at Tema and Adum stations named 'not knowing how long the queue is' as their biggest source of commute stress.
What I did about it
People weren't afraid of the trip; they were afraid of not knowing. So the queue is everywhere a rider looks first: the onboarding promise is 'Know your queue before you leave', Queue Status sits on the home screen next to 'Where to?', and the Terminals tab opens on live queue depth and bay status at the nearest terminals. I considered opening on a destination search, the way most transit apps do, and gave the queue equal weight beside it instead.
02 · Finding
Cash is a tax on trust
About 10 riders estimated losing GH₵4–6 a week to 'no change': drivers rounding fares up, conductors short-changing in the rush, or riders not boarding because they couldn't pay the exact amount.
What I did about it
The Troski Wallet is the default, not an add-on: top up once by card or mobile money, then tap to pay or scan the driver's code at the door. No counted coins or rounding arguments, a balance one glance from the home screen, and a receipt for every fare.
03 · Finding
'Where to' is the real front door
In moderated sessions, 8 of 10 participants opened a maps or transit app already sure of their destination and undecided on how to get there. Mode always came second.
What I did about it
So search starts from the destination, not the vehicle. Type where you're going once, and Troski ranks every way there, from bus and okada to taxi and charter, by time, cost and live traffic, with one 'Go now' to commit.
Process
How I worked through it.
01
Field research at the terminal
Four mornings at Tema and Adum stations, shadowing riders from arrival to boarding and timing each stage of the wait by hand, plus 30 structured interviews. That's where the three insights came from.
02
Mapping a multimodal model
Most transit apps are built around one mode. I designed an information architecture where bus, okada, train, taxi, van, courier, EV and charter share one search and one results list, then tested it against 15 real Accra commutes.
03
Wallet, queue & trust system
The visual language for queue and bay states (short, moderate, long, boarding now) and the wallet's top-up, tap-to-pay and scan-to-pay flows. Every state had to read in under a second, in midday sun, from across a station forecourt.
04
Onboarding, motion & handoff
An onboarding that leads with the queue promise before asking for an account, with one action per screen. Then annotated specs for every state and motion curve, and two QA passes with engineering before handoff.
Selected Screens
A closer look.
Outcomes
Where it stands.
7 of 10
completed a booking unaided in prototype testing
1m 50s
median time to first search
30
rider interviews behind the design
I've completed the handoff, and version 2 is in development with Samed's team; release timing is theirs. 10 people tested the prototype. More than one person said, unprompted, that seeing the queue made the trip feel like it had already started.
Reflection
What I'd do differently.
I designed the whole concept at once: live queues, ride ordering across eight modes, and a wallet. Next time I'd score every feature on impact and effort first, then design and build the highest-impact, lowest-effort ones before the rest. Version 2 would reach riders sooner, and the launch demo would rest on the features that matter most.
Now you know.
A queue nobody trusts? A status that sends people to support?
That's the work I do, and I'm open to new projects. Tell me what you're building, and I'll tell you honestly if I'm right for it.
Next Project
Denials Desk (2026)
Designed a denials work queue where an AI suggests the next step on each denied claim and the biller decides, with the evidence one click away.