The problem with adopting a global design system is not the components. The components are fine. The problem is the assumptions baked into every single one of them — assumptions about how users read, what they trust, how they enter their name, where they live, and how they pay. Those assumptions were made in San Francisco, London, and Seattle. They were not made in Gaborone.
What mobile-first actually means in global design systems
Every major design system claims to be mobile-first. Most are lying.
Material Design, Fluent UI, and Apple HIG were all built by companies whose primary products run on screens with reliable internet, predictable viewport sizes, and users who interact through a combination of touch and keyboard. Mobile-first, in their context, means we added responsive breakpoints. It does not mean we designed for a user who owns one device, uses it on 4G with a variable signal, and has 2GB of monthly data they are actively managing.
The difference shows up in component weight. A standard Material date picker loads a calendar grid, a month/year selector, and animation transitions — all to capture a single date field. On a mid-range Android device in Gaborone on an Orange Botswana connection, that component can noticeably lag. A plain text input with format validation is faster, lighter, and equally usable. Global design systems rarely make this tradeoff because their authors never had to.
Building for Botswana means being honest about what mobile-first requires: fewer network requests, lighter components, and layouts that hold at 360px without compromising information hierarchy.
The form fields that quietly exclude your users
Form design is where global design systems fail local products most concretely, because forms encode assumptions about identity — and identity looks different here.
Consider the standard name field pattern: First Name, Last Name. In Botswana, many people go by their Setswana name in daily life and a different name on their national ID (Omang). Some names do not split cleanly into a first/last structure. A form that rejects or mangles a name at registration has already told users something about who the product was designed for.
Address fields are worse. Global components default to Street address, City, State, ZIP. Botswana uses plot numbers. A significant portion of the country's addresses are structured as Plot 1234, Block X, Gaborone — not 42 Main Street. A form field labelled Street Address with a ZIP code input below it is not a minor UX friction. It is a form that cannot be completed accurately.
Phone number inputs are another tell. Most global components default to a US country code with a 10-digit validation mask. Botswana numbers are +267 followed by 8 digits. Getting this wrong at signup — or forcing a user to hunt through a 200-country dropdown — is a small moment of exclusion that accumulates.
None of these are hard to fix. They all require a local product team to override the defaults, which means knowing the defaults were wrong in the first place.
What local design system decisions actually look like
This is not an argument for building from scratch every time. Global design systems offer genuine value: accessibility groundwork, consistent component behaviour, well-documented patterns. The argument is for treating them as a foundation you adapt, not a specification you implement wholesale.
In practice, three decisions separate products that work for local users from products that do not:
- Override form components entirely for identity fields. Name, address, phone, and national ID fields should be built to match local data formats — not inherited from a US-centric component library. This means custom validation, appropriate labels, and input patterns that reflect how users actually fill in their information.
- Test on real devices at real network speeds. Not Chrome DevTools throttling. An actual mid-range Android phone on a mobile data connection. If a component lags noticeably on that setup, it is too heavy for your primary user. The design system default is not the right answer just because it is the default.
- Audit trust signals for local context. Global design systems use visual cues developed in specific markets — padlock icons, SSL badges, blue for links, green for success states. These are broadly understood, but they are not universal. In markets where digital fraud is a real concern and digital literacy varies, the signals that communicate safety and legitimacy may need to be more explicit, more prominent, and reinforced through copy — not just iconography inherited from a system built for a different context.
The right design system for a product built in Botswana is a global system that has been interrogated, overridden in the right places, and tested by people who actually live there. That is a different thing from a global system installed and left to run.
