SafeSize · adding a buy flow to a foot-scanning app without breaking the product around it

SafeSize scans your foot in a shop and tells you which shoe will actually fit. The scanner already worked, and it was already out in the world, on screens inside big retailers like Nike and Intersport. What the app could not do was let you act on the answer. You could learn your size and then have nowhere to go with it. No cart, no checkout, no path from knowing to buying.

I was brought in through Code.Hub as an external consultant, for three months, to design that missing piece: the commerce flow that turns a fitting tool into something you can buy from. SafeSize already had a senior designer in-house. She stayed on the product as a stakeholder while I led this phase, and we set up a way of working early. The collaboration was genuinely good, which is not a thing you can count on when you parachute into someone else's product for a quarter.

The scope no one drew at kickoff

The brief sounded contained: add a buy flow. The real work was not.

SafeSize was an established product with an established user experience, one that had been settling for a long time before I arrived. Dropping a commerce flow into the middle of it was never going to be a clean insert. It would touch existing flows, existing screens, existing patterns, and the job was to add all of it without disturbing what already worked. None of that was defined in the first meeting. The size of the change only surfaced once I started studying the product and tracing where the new feature would actually land. So before I designed anything, the real first task was mapping the blast radius that nobody had drawn.

Learning a product that was not mine

Three months is not long to understand a product you did not build. So I spent the early part of it on the unglamorous work. Desk research. A competitive analysis of how other e-commerce products handle the parts I had to design: the add to cart, the checkout, the moment of deciding to buy. An audit of SafeSize's current app, flow by flow. And underneath that, learning their design system, how it was built, what the brand guidelines were, how the pieces were meant to fit together.

The audit turned up more than the commerce gap. I found elements in the existing product that were a little off, and I said so. Part of what I handed back was a set of consulting notes on things worth changing, some to make room for the commerce feature, some to set up flows they had not built yet. That is worth being clear about, because the tidy version of consulting is that you touch nothing and admire the house. The honest version is that if you audit a product properly, you find things, and the value is in telling them.

Two flows, feasibility first

I designed two options for the commerce flow, and I took neither of them to the stakeholders first. They went to the developers, the technical team, the business analysts, and the project owners, so we could agree on what was actually buildable before anyone spent a meeting reacting to a picture. What the systems could return, what was feasible, what would break if we did it a given way. That conversation happened up front.

Both flows carried their full state coverage, the happy path and the unhappy one, the errors and the edges, so everyone was aligned on how the thing behaved when it did not go to plan, not only when it did. Then the two options went to the stakeholders. We talked, they left comments in the files, and we settled the direction together. With the flow agreed, I expanded their existing design system to carry it and built the components the new screens needed. I was extending their system, not replacing it.

The part that outlives the engagement

The buy button was the visible deliverable. It was not the important one.

Because I had to learn their system from the outside, I also had to write down what I learned. The documentation had gaps, so I built guidelines as I went: how the colours were meant to be used, how the buttons worked, how the expanded components sat next to the existing ones. By the end, the flow was not the only thing I handed over. There was a documented way to extend it.

That is the part I care about, and it is a pattern I have watched repeat on most projects I have worked on. Documentation is the piece designers skip, especially when we work alone, because the whole system is already sitting in our heads and writing it down feels like the least urgent thing on the list. It is also the thing that quietly saves you. When it is missing, you loop, you rebuild the same reasoning twice, you rediscover a decision you already made. When it is there, the next person, or the next version of you, does not start from nothing.

Here it paid off straight away. I delivered the flows, and the development team built the whole thing over the following month, running a sprint or two behind me while I stayed ahead, the way this kind of project tends to work. The handoff was fast, partly because I had worked with these developers before, and partly because the decisions were already written down. Nothing had to be explained twice.

What I keep from it

What made SafeSize genuinely hard was also what made it worth doing. Three months to understand a product I had not built, its flows, its visual language, its history, and then to propose, recommend, and add new flows inside it without damaging a user experience that had taken years to settle. That is a real skill, and it is a different one from founding a product on a blank page.

If I did it again, I would change the order. I found the true scope, which existing flows the commerce feature would touch, in the middle of the project, when I should have found it at the start. I would study the whole product first, map every place the change would reach, and only then design the commerce on top of it. Front-load the understanding and you buy back time for everything after it. That, and the documentation, are the two things I took from SafeSize, and they are the two things I now do first.