Insights.
Notes on UX engineering, design systems, and shipping the gap between Figma and production.
Notes on UX engineering, design systems, and shipping the gap between Figma and production.
Product · 7 min read
Close ✕Dec 2024
Most UX frameworks were built by people designing for users who have reliable broadband, a flagship smartphone, and mental models shaped by a decade of Silicon Valley products. I'm not one of those people, and most of my users aren't either.
Building products in Accra has forced me to question assumptions I didn't even know I was making.
The default assumption in most products is that data is cheap and fast. In Ghana, mobile data costs are a real consideration for users. An app that casually loads high-resolution images, autoplays video, or makes a dozen API calls on page load is an app that costs money to use.
The UX implication: performance is accessibility. A 4-second load time isn't a technical debt item — it's a usability failure for a significant portion of your users.
"When I started optimising for data-light experiences, I wasn't downgrading the product. I was actually designing for the real user."
Standard phone number inputs expect a 10-digit local number. Ghanaian numbers are 10 digits — but formatted differently, with a leading zero, and users often switch between local and international format depending on context. A form that rejects a valid number because it doesn't match a regex built for US numbers isn't just a bug. It's a signal that you didn't think about your user.
Not every user in Accra is a digital native, and the ones who are have often learned on mobile — not desktop. Drag-and-drop interactions, hover states, right-click menus — these are desktop affordances that don't translate. When I stopped designing for how I use interfaces and started observing how my actual users do, the product changed significantly.
I test on real mid-range Android devices, not emulators. I design for intermittent connectivity by default. I consider the cost of every network request. I question every input label, every error message, every empty state — and ask whether it makes sense to someone who didn't grow up with the same digital context I did.
The irony is that designing with these constraints makes better products for everyone. A faster, lighter, clearer interface is better regardless of where you're building it.