The Challenge: Why Default Address Forms Fail Globally

The existing club application form relied on Google Maps Autocomplete as its sole address input method. While this pattern works seamlessly in the UK and North America, it created a severe accessibility barrier in the Foundation’s fastest-growing international markets like Kenya, South Africa, Malawi, and Cambodia.

When local club leaders typed their address, the system returned zero suggestions, leading users to abandon registration or enter dummy data. Local partners had to compensate by manually submitting applications on behalf of users, wasting hundreds of operational hours.

‍

The Hidden Metrics Trap

The data masked the severity of the issue: an overall metric showing "78% completion at step 3" hid the fact that the 22% dropping off were disproportionately the non-Western leaders the Foundation most needed to empower.

The Solution: A Multi-Modal Input Architecture

Instead of treating non-standard addresses as fallback edge cases, we redesigned the UX around three co-equal input modes presented together:

1. Unified Search (Plus Codes & Google Links): Accepts street names, pasted Google Maps URLs, or Open Location Code (Plus Codes) like 62M9+MV2. Plus Codes are widely used across Kenya and Rwanda as primary location identifiers because they encode exact geographic coordinates without relying on street names.
2. Mobile-First Map Pinning: Rather than using a draggable pin (which is prone to user error on small mobile screens), we designed a fixed centre crosshair with a panning map beneath it. Moving the map behind a fixed center pin turns precision finger targeting into a gross motor task, radically improving mobile UX.
3. Structured Manual Entry: Treated as a primary, first-class path rather than a hidden fallback option.
   ‍

Country Selection as the Controlling Variable

Selecting the country first triggers dynamic field rules inside the design system component:

• Dynamic Field Labels: Adapts contextually (County in the UK/Kenya, State in the US/India, Province in South Africa, Region in Malawi).
• Flexible Validation: Makes Postcodes required in Western markets but completely optional in markets without postal infrastructure.
• Optional Address Line 1 + Alternative Fields: In low-infrastructure regions, forcing Address Line 1 produces fabricated data to bypass validation. We made Address Line 1 optional and introduced two required alternatives:
  • Decimal Coordinates Field: Accepts lat/long pairs (e.g., -1.286389, 36.817223) copied directly from mobile map apps.
  • Landmark Location Description: A dedicated text input with explicit microcopy ("Include nearby landmarks, crossroads, or instructions to find your venue").

Design System Architecture

The component was built as a scalable design system pattern governed by a single country configuration object: This architecture allows product teams to launch into new international markets by editing a single configuration file without touching UI layout or validation logic.

‍

Results & Key Learnings

• Global Inclusivity: Unblocked registration paths for thousands of club leaders across Kenya, South Africa, Malawi, and Cambodia.
• Operational Savings: Freed local partner organizations from manually completing registrations, reallocating hours back to club operations.
• Trade-Off Transparency: Postcode format validation and multi-language localization (Swahili, isiZulu) were intentionally scoped for future iterations to prioritize immediate market access.