Map Implementation

Auchan's platform asked new customers to type their delivery address into a form. That part worked: people wrote down where they lived.

One platform, several retailers, and their address steps were not the same. Auchan's was a form of separate fields: street name, street number, door, postal code, city. Ocado Retail's was already a search that returned addresses as you typed, and it worked for them. What it could not do was show you the place it had found.

What failed was underneath, and it failed for both. In certain cases the platform's address service could not recognise what had been entered and returned nothing at all. That was a limitation of the integration, not of the customer's typing. The order carried an address the system could not resolve into a place, and the delivery fleet had no reliable idea of where to take it.

For the customer it was a dead end. The address they had just typed was not found, and the form offered no way forward and no way back.

That is not a friction problem, it is an operations one. An order that cannot be delivered is a failed order, and it was keeping Auchan Poland from operating normally.

Whatever came next had two conditions on it, and both were written down before any of the work started.

In order to understand how a map should be designed and how the interactions on it worked, the first step was to perform a benchmarking with some grocery retailers and delivery platforms that included a map as a method for introducing a deliverable address.

I sat five people in front of the two mechanisms the project was really choosing between: Auchan's address form, a set of fields you fill in and hope for the best, and Glovo's map, which offers you real addresses as you type. The same three situations in both.

The point was never whether they could finish. It was what they said while they tried, and what changed when they moved from one to the other.

They said the flow with the interactive map was friendlier, gave more help, was less error prone and less old-looking. One stated the alternative looked like a one-time delivery address, for clothes shopping. They did like having a zip code input to reach the correct town.

The next step was to build and moderate a workshop with all stakeholders: UX Design, UX Research, Product Managers and Engineers, to look at the information together and learn from everyone what could be done and what not.

The benchmark and the interviews were presented together, one after the other, rather than circulated as two documents: five platforms and five participants making a single argument, in front of the people who would have to build whatever came next.

I brought three explorations of my own, drawn in August while the research was still warm. One was the flow the evidence pointed at. The other two changed almost nothing: a map that could not be interacted with, placed further down the flow, with the step people were already using left alone.

The two cheap ones were the point. I wanted the room to have something to choose between, including a version of my own argument that cost almost nothing to agree to.

Only then did we ideate. Anything from anyone first, with no filter and no ownership, and then the room placed what it had produced on an impact / effort matrix and voted on it.

This is what the engineering team proposed, and these are its screens as I built them: in the real flow, with the real components, so that what we were disagreeing about would be a thing on a screen rather than two descriptions of something imagined.

The map on the last screen can be navigated and the pin can be dragged. Its own banner says so. What it cannot do is change anything. The address printed under it is the one the customer typed, in the past tense, and where the pin ends up is never saved. Someone could confirm an address in Barcelona, leave the pin in Guatemala, and nothing about that would be recorded anywhere.

Which is requirement 02, the one that says the customer must be able to enter the formatted address as they wish: if the service pre-fills from the pin, they must be able to edit it. Here the pin fills nothing and edits nothing.

Built in the same weeks as the one above, in the same components, around the pattern every map search on the market already uses: one field, suggestions as you type, and a map that confirms.

It was also the smaller change for the client. Ocado Retail already had the search and it worked for them; what it could not do was show them the place it had found. This adds that, and takes nothing away.

I took it to the whole of UX, around thirty designers, in the reviews we ran every week. The agreement there was not about preference: it was the flow that met the two requirements the brief had set, and the one the benchmark and the interviews had been pointing at since August.

Then both flows went back to the engineering team in a catchup, side by side. Theirs was chosen. That is the version that went out to Ocado Retail and Auchan.

The flow went out to the two retailers that would have to run it. Both of them came back, and neither of them came back about the map.

Ocado Retail asked for a search field. Five of five participants had already put a multi-field form beside one and come away with concerns about the form, and one of them said it looked like their grandmother had built the site. Auchan asked for the floor and the door in separate fields. Five of five had entered those details differently from one another, which is where the errors were coming from.

The search field Ocado Retail asked for is the one I had put in front of the team two weeks earlier.

The catchup after the clients replied changed exactly one thing: the form was adjusted where Auchan had insisted it be left alone. The rest of the flow stayed as it was.

So I stopped arguing for my flow and started arguing for less. Their structure, their screens, their order, and one defect fixed at a time. Three rounds through the back half of October and November, each one drawn, each one taken through the UX reviews, each one returned.

All three were rejected.

Then I escalated it to the Head of Design, who came to a call to back the position. He was pushed back on as well.

Research, a benchmark of five platforms, twenty-eight written concerns, two flows built side by side in the real product, thirty designers agreeing, and finally the two clients themselves. None of it was disputed. None of it moved anything either.

So we stopped, and that was a decision rather than a surrender. The Head of Design and I agreed that the next round would cost more than it could return, and that the sensible thing left to do was protect the one line still worth holding.

The team's flow is what shipped. It is live in Auchan, in Poland and in Spain, and the address step that was sending undeliverable orders to a fleet is not doing that any more.

The forms in front of it are still each retailer's own. That is the piece I held on to, and it is the one both clients had asked for without knowing they were arguing my case.

Not the design. The timing of the escalation. I took it to the Head of Design after the third attempt at a middle ground, and the moment for it was after the first. The evidence was complete by the end of October, and nothing produced after that date changed anybody's mind. The second and the third were me hoping an argument would win on repetition.

The part I would do again is the part that cost the most: building their flow myself, in the real product, with the real components. It is the only reason this page can put two things side by side instead of telling you about a disagreement.