Case study · 01
MusawoLink
A mobile app that helps Ugandan clinics fill last-minute shifts with verified healthcare workers.
What MusawoLink is, and why I built it.
MusawoLink is a two-sided mobile app for healthcare staffing in Uganda. Clinics, hospitals, and pharmacies post short-notice shifts. Verified nurses, midwives, and pharmacy techs nearby can claim them and get paid through mobile money — usually within 48 hours.
I built it as a solo project to learn how to design for a market I know. I worked in Ugandan healthcare for seven years before becoming a designer and wanted to put my UX practice into one focused, end-to-end product. "Musawo" means clinician in Luganda.
How healthcare staffing actually works on the ground.
Across Kampala and the surrounding districts, private clinics, pharmacies, and rural health posts run on improvised staffing. A midwife calls a friend, who calls a colleague, and a 10pm shift gets filled at 9:47pm. The cost of that improvisation is real — missed shifts, unverified credentials, and a junior nurse moving across town for a three-hour call-in.
There's no shortage of healthcare workers. There's a coordination problem.
What I learned talking to people I used to work with.
I worked in Ugandan healthcare for seven years — one in a hospital, two in a medical centre, four in a pharmacy. For research, I went back to former colleagues across all three settings and listened.
-
01
Trust comes before software.
Facilities trusted referrals through colleagues, not platforms. Verification — license, training, references — had to feel airtight before any feature mattered.
-
02
Bandwidth is a design constraint, not a wishlist item.
Most users are on 3G with patchy coverage. The app had to load fast, queue actions when offline, and never gate the core flow on a heavy upload.
-
03
Money moves through mobile money, slowly and informally.
Bank rails are a non-starter. Any flow that delayed payouts beyond 48 hours would lose professionals to phone-call work.
The shape of the app: find, verify, work.
I broke the experience into three surfaces, each with a single job. Onboarding and verification live outside this loop and are intentionally heavier — they're the only place I ask for friction, because trust is the whole product.
Testing the post-a-shift form, twice.
The post-a-shift form was where I was most worried about friction. Facility managers post shifts at the worst possible moment — late, stressed, often during another emergency. I wanted to know if the form I'd designed felt as fast as a phone call.
I ran an unmoderated study in Maze with facility managers. The task: post a shift in under 60 seconds. The heatmap revealed something specific — users were clicking the right edges of dropdown fields, expecting them to expand. The Quantity-of-workers field had the highest abandonment rate. Nobody knew what to put.
Three things I changed.
-
Replaced the qualifications dropdown with chips.
Faster selection, no dropdown scanning. The chip pattern came directly from the right-edge click data — users wanted to tap, not navigate.
-
Turned duration into preset buttons (4h / 6h / 8h / 12h).
Reflected the most common shift lengths instead of asking users to type a number under stress.
-
Removed the Quantity-of-workers field entirely.
Testing showed it added confusion without value at the posting stage. Quantity gets resolved during confirmation, not posting.
What it looks like.
The final flow for the professional side: open shift → details → claim → confirmation → active shift → payout. Three taps from open shift to claim. Pay, distance, and shift type are visible in the first card so the decision happens before the tap.
What I'd do differently, and what I learned.
What I'd research next
Round one was Kampala-skewed. I'd want to re-run the post-a-shift task with rural facility managers, where bandwidth and verification trust look very different. I'd also stress-test the verification flow under intermittent connectivity, which I couldn't simulate well in Maze.
What I'd co-design
The rejection and dispute flow. When a clinic rejects a worker after they've shown up, who pays for transport? Who decides? I designed a placeholder version, but this is the kind of thing I'd want to sit with two ward in-charges to get right.
What this project taught me
That research access is a privilege I had on this project — seven years of healthcare relationships meant I could call former colleagues and get honest answers. I won't always have that. I'm thinking now about how to do trustworthy research in domains where I'm an outsider.