The challenge

The Raspberry Pi Foundation’s club registration flow relied on Google Maps Autocomplete as the only way to enter a venue address. It worked reasonably well in the UK and Ireland. But in Kenya, South Africa, Malawi and Cambodia, people were getting stuck. Sometimes their venue simply didn’t appear in search results. Some abandoned the form, while others left fields blank or found their own workarounds.

When I looked through existing submissions, I found landmarks in address fields, Google Maps links in Address Line 2 and other information that didn’t fit the structure we had designed. The problem wasn’t that people couldn’t describe where their venue was. Our form had a narrow definition of what counted as an address.

Looking beyond the overall numbers

The problem was visible in the data, drop-off was higher in the countries where conventional street addressing and Google Maps coverage were less reliable. There was also an operational cost. Partners in these countries were sometimes completing applications on behalf of club leaders or helping groups submit applications, in areas where internet access was more reliable.

The badly filled address fields became useful research. Instead of treating them as bad data, I looked at what people were actually trying to tell us. That changed the question from:

How do we improve address autocomplete?
to
What does someone actually need to locate a venue?

‍

Three ways to enter a location

Rather than making autocomplete the default and everything else a fallback, I designed three ways to enter a venue.

1. Search

- The search field accepts a conventional street address, Google Maps link or Plus Code.
- They all use the same input because asking someone to identify which type of location information they have adds an unnecessary step.
- Once a result is selected, the manual form fills the available address fields and shows the location on a map for confirmation.

2. Map

- People can also locate their venue directly on a map.
- Instead of dragging a small pin around the screen, the pin stays fixed in the centre and the user moves the map underneath it.
- This makes the interaction much easier on mobile. Moving a map is a forgiving gesture; positioning a tiny pin precisely isn't.
- I also kept the map on a separate screen so the address form doesn’t need to constantly update as someone pans and zooms.

3. Manual entry

- Manual entry remains a first-class option rather than something hidden behind a fallback.
- Someone can enter or correct address information without losing the rest of their location data.
- Sometimes autocomplete works. Sometimes the person filling in the form knows better.

Country controls the form

Country is selected first because it determines what a useful address looks like and labels change depending on the market: County, State, Province or Region; Postcode, ZIP code or Pin code. More importantly, the requirements change too. Address Line 1 and postcode are required where we can reasonably expect them. In Kenya, South Africa, Malawi and Cambodia, they’re optional. In those markets, the form instead provides coordinates and a field for describing the location. A required field doesn’t make the information inside it accurate. If someone doesn’t have a meaningful street address, forcing them to provide one just gives us neatly structured bad data.

‍

Giving landmarks somewhere to go

One of the simplest additions was a field to describe the location. It gives people somewhere to add nearby landmarks, road names or anything else that helps someone find the venue. This came directly from the audit. People were already giving us this information, they were just putting it wherever the form would accept it. Coordinates followed the same logic. Some club leaders were already copying latitude and longitude from Google Maps on their phones to share venue locations. Rather than treating that as a workaround, I made it a supported input. The form needed to catch up with how people were already describing location.

‍

Building it for reuse

The work started with club registration, but the component needed to work across the Raspberry Pi Foundation design system.

I designed three variants:

• Full flow: country selection, search, map and address confirmation
• Search and autofill: for contexts where geocoding is reliable
• Manual entry: for postal or correspondence addresses where precise physical location isn’t necessary

I also defined how the different input methods interact; Selecting a search result fills the form and sets the map location. Saving a new map pin resets the address fields because the underlying location has changed. Manually editing an address field supplements the existing information rather than resetting it. Those behaviours are less visible than the UI itself, but they’re what make the component reusable.

‍

What’s still unresolved

There are still limitations, the map requires a data connection, so manual entry remains important when it can’t load. Postcode validation currently checks whether a value is required, rather than validating every country-specific format. The component is also English-only. Supporting more languages will need more consideration than simply translating field labels. There are other things I’d like to explore later, including offline map support and venue photos as another location signal.

What I want to learn next

The next step is understanding which paths people actually use?

- Are people searching with street addresses, Plus Codes or Maps links?
- How often do they use the map?
- Who goes straight to manual entry?

The original form wasn’t necessarily badly designed. It was designed around assumptions that happened to work in the places where it was first used. Once the product moved beyond those places, those assumptions became part of the problem. An address doesn’t always mean a street name and postcode. Sometimes it’s a pin. Sometimes it’s coordinates. Sometimes it’s “behind the petrol station, next to the school”. If that’s how someone finds the place, the form should be able to understand it too.
‍
‍

‍How I used AI on this project‍

I used Claude to help analyse 420+ malformed address entries, synthesise interview findings, critique prototypes, draft the field behaviour matrix and developer documentation, and edit this write-up. The research, design decisions and final work are my own, and several key decisions came from challenging its assumptions with real data and lived experience.