Client

what3words Ltd

Addressing & geocoding System

what3words
Year

2018

London, UK

what3words Map App

Helps everyone talk about everywhere

Lead Product Designer on the what3words map app, 2018. The company had a working address system and very few people using it, and the research found that the map was the barrier rather than the addresses. This is what we changed and what it cost.

what3words Map App
  • 30
    Languages supported
    Languages the three word address system was published in.
  • 6.9 to 24.4 characters
    Address length, average
    Average three word address length across the top 10,000 addresses per language, lowest (Chinese) to highest (French).
  • 12 to 57 characters
    Address length, maximum
    Longest three word address per language, lowest to highest.
How much detail?

Context

what3words gave every 3m by 3m square on Earth its own three word address. I joined in 2018 as Lead Product Designer and led the map app from London.

I set up the design practice from the ground up: the way the work moved, the UX strategy, and a React design system the other products were built on. I grew the team to four permanent designers and a group of freelancers, and worked with the executives and partners who shaped the product range.

Challenge

The company had a working address system and very few people using it. The research found the reason. Many of the people we watched had never used a map before, and even confident users could not point to their own front door on one. A three word address is only useful once somebody can find the square it belongs to, so the map was the thing standing between the idea and the people it was for.

That made the map itself the design problem. The grid is 3m by 3m squares, which are far too small to exist at the zoom levels people browse at, so the app had to decide what to show and when. The marker had to stay readable while the map moved under it, and it had to say something different when a place was only selected, when it was saved, and when it had been given a name. A three word address is also a different length in every language it is published in, so whatever we drew had to hold text of very different sizes without breaking.

Approach

Audit what addressing actually does

I started by looking at how addressing works in practice. Street addresses were often inaccurate or ambiguous. Road names repeated. Homes and businesses sat a long way from the centre of their postcode. Whole places had no address at all, from informal settlements to the park where people had arranged to meet. Around four billion people live without a formal address.

Bring the field research back to the room

I ran the research on site and then took it into internal workshops, where we went through the findings together and agreed what the real user problems were. Search, refine and save were not separate features but the three core scenarios from which the product needed to be designed.

Build around those three scenarios

Search accepts a three word address or an ordinary street address, so nobody has to learn a new habit before they can start. Refining is what turns a rough tap into the exact square, and it is the step the research said people needed most help with. Saving turns a square into a place with a name, which is what makes an address worth keeping. I worked alongside the engineers on the Google Maps integration, so the map underneath stayed familiar while the layer on top was ours.

Decisions

The grid appears at zoom 19, not before

The map reveals detail in stages: continents around zoom 5, cities at 10, streets at 15, the three word grid at 19, individual buildings at 20. The alternative was to draw the grid whenever the map was open, which is the most direct way to teach what the product is. We did not, because at city zoom the squares are smaller than a pixel and the grid turns into a grey wash that hides the map underneath. The cost is that a first time user does not see the idea until they have zoomed a long way in, so the rest of the interface has to carry the explanation until then.

The marker changes shape rather than carrying a status label

A location is floating while it is only selected, locked once it settles on a square, saved when it is kept, and named when it has a label. Each of those is a different marker rather than the same marker with words beside it. The alternative was one pin and a status line, which is cheaper to build and far cheaper to translate. Four markers cost more design and engineering time and one more thing for the design system to hold. What they bought is a map that can be read at a glance while it is still moving.

The address resizes itself instead of being given a fixed size

Three word addresses are published in more than twenty languages, and the same address is a different length in each. The alternative was to set the type once and cut whatever did not fit, which keeps a layout stable. Cutting an address destroys it, because all three words are needed to find the square, so the type scales to the space and to the number of characters instead. The cost is that the address is not always the same size on screen, which makes it a weaker visual anchor for everything designed around it.

Look unlike Google Maps while being built on Google Maps

We integrated Google Maps through its APIs, so the tiles underneath were the ones people already knew. The alternative was a different base map provider, which would have given us control of the cartography itself. Staying with Google kept the map familiar and the integration proven, and it cost us the ability to change the base map at all. The difference had to come entirely from what we put on top: colour, typography and iconography.

Results

We tested the MVP against the three things the product asks of a first time user: understand what a three word address is, save a location while registering an account, and use an address to get somewhere. The validation readout from those sessions is below.

After release the pattern in feedback was consistent. People found the app straightforward and it grew steadily. Bugs on Android were the clearest drag on that, and they came up more often than any complaint about the interface. The most common request was not a feature. People wanted to understand how the system works well enough to explain it to somebody else, which is the same adoption problem the research had found, showing up again on the other side of the launch.

Reflection

What I would change is the order. We treated explaining the system as something the interface would do on its own, and the strongest signal after launch was people asking for that explanation directly. Teaching should have been designed as part of the product rather than left to the map to imply. The ideas I did not get to build were about turning a saved place into something worth sharing: lists that can be private or public, locations that carry a story, and a link to the 3wordPhoto app so a photograph and a place travel together. Those are my own ideas rather than the company's plans.

Prototype

The prototype covered the three tasks end to end: find and save an address, navigate to one, and share one. It ran as a connected flow rather than a set of separate screens, so the movement from finding a place to correcting it to keeping it could be judged as one gesture instead of three.

Tools and skills

UX strategy

Set the strategy the product range was designed against.

Design system

Built a React design system the other products were based on.

Field research

On site observation of how people read maps and share places.

Workshop facilitation

Internal sessions to read the research together and agree the problems.

Prototyping

Connected high fidelity flows for find, save, navigate and share.

Team leadership

Grew and led four permanent designers and a group of freelancers.

Technology

Google Maps APIs

The base map and geocoding, integrated with the engineering team.

what3words API

Converts between coordinates and a three word address, in both directions.

React design system

The shared component base across the product range.

iOS and Android

Native apps, including the voice search that only ran natively.

Responsive web map

The same product on the web, for people who arrive from a link.

Accessibility

On a map, information density is an accessibility decision. What the app draws is tied to the zoom level, so a screen never carries more than it can render legibly, and the grid only appears once its squares are large enough to tell apart. The three word address itself is specified per writing system, with a typeface, weight and size for each, so an address set in Arabic, Chinese, Japanese, Mongolian or Hindi is as readable as one set in English.

The system supported 30 languages, and the constraint turned out to be sharper than expected. We measured the average three word address length across the top 10,000 addresses in each language: it ranges from 6.9 characters in Chinese to 24.4 in French, a spread of three and a half times. The maximum runs from 12 characters to 57, nearly five times, and all of it has to sit in the same marker on the same map.

A component sized for English fails in both directions. English averages 21.1 characters and tops out at 54, so it sits near the worst case for Latin scripts: French, German and Finnish overflow a component built around it, while Chinese and Korean leave it looking empty, which on a map marker reads as a bug rather than as a short address. That ruled out a fixed treatment and made responsive resizing a structural requirement rather than a polish item. The rule had to live in the component, not in a guideline, because every language variant would otherwise have to be caught by review.

Delivery and rollout

The work moved through staged delivery, with fixed points for review, iteration and sign off, then validation before release, and then it repeated. Research, analysis, design, build and test each had a place inside a stage rather than a phase of their own. That is what let a feature go out, come back for revision and go out again without stopping everything around it.

Disclaimers

Some of this work is not shown. What is withheld is what what3words treats as confidential, under the Data Protection Act 2018 and the Computer Misuse Act 1990. What is shown is used for portfolio purposes under fair dealing, sections 29 and 30 of the Copyright, Designs and Patents Act 1988. Every address in these screens is a placeholder from design review rather than a real saved location, because a three word address is precise enough to identify where somebody lives. The views here are mine and are not the company's positions.

Key facts

Client
what3words
Year
2018
Role
Lead Product Designer
Industry
Addressing & geocoding System
Location
London, UK
Languages supported
30
Address length, average
6.9 to 24.4 characters
Address length, maximum
12 to 57 characters

Watch the prototype walkthrough

What was the challenge in what3words Map App?

The company had a working address system and very few people using it. The research found the reason. Many of the people we watched had never used a map before, and even confident users could not point to their own front door on one. A three word address is only useful once somebody can find the square it belongs to, so the map was the thing standing between the idea and the people it was for.

Read the full section

What did I actually do on what3words Map App?

I started by looking at how addressing works in practice. Street addresses were often inaccurate or ambiguous. Road names repeated. Homes and businesses sat a long way from the centre of their postcode. Whole places had no address at all, from informal settlements to the park where people had arranged to meet. Around four billion people live without a formal address.

Read the full section

What was the outcome of what3words Map App?

We tested the MVP against the three things the product asks of a first time user: understand what a three word address is, save a location while registering an account, and use an address to get somewhere. The validation readout from those sessions is below. Measured outcomes: Languages supported: 30; Address length, average: 6.9 to 24.4 characters; Address length, maximum: 12 to 57 characters.

Read the full section

  • #what3words
  • #Addressing System
  • #Maps

Michelangelo Zampogna

AI Product & Service Design Leader

London, UK

© 2026 Michelangelo Zampogna. All rights reserved.

Built with Next.js, Three.js and a conversational agent.