one.O Create
Give the idea a story.
A capability on its own is a demo. It becomes a product when someone can say what it is for.
Generating a scene around a product is a trick. Letting a team show the same product in forty contexts, in a week, without a studio — that is a different job, and it needs a different interface.
The useful question is: what does this let the user do that they could not do before?
Ask that before designing anything. The answer is what the screens have to make possible.
01: Start with what a commerce team can’t afford.
They need product imagery faster than any studio can shoot it. Not better imagery — faster, and more of it, for more channels, in more variants.
That gap is the product. one.O Create exists because the alternative is a photo shoot that costs weeks and a budget most teams don’t have for a seasonal banner.
02: Name the user who isn’t a creative.
The temptation with a generative tool is to design it for the person who knows how to art-direct. That person already has options.
Our user is the one who has to produce a visual by Thursday and has never written a prompt. Every decision in this case study follows from that: if a feature only works when you already know what to ask for, it doesn’t work.
03: Write down what the product refuses to do.
Before designing screens, we wrote the refusals. A generative product without them becomes a prompt box with a logo.
| The product does | The product does not |
|---|---|
| Generate the scene, background and lighting around a product | Alter the product itself — what is shown has to match what is sold |
| Replace catalogue and variant photography | Replace art direction for brand or campaign hero creative |
| Guide a non-expert to a usable result | Offer an open-ended playground for prompt experts |
| Let the user correct part of an image | Promise the right result on the first generation |
| Mark every generated asset as AI-generated | Let that marking be switched off |
| Produce the channel formats from one approved asset | Publish to channels, or act as the asset library of record |
The first row is the one that does the work. In commerce, an image is a claim about the product. Every other decision in this case study exists so that claim stays true.
04: Audit what the product became.
one.O Create was born to do one thing: write a prompt, upload an image, and put new clothes on a model. One trick, done well.
By the time I audited it, the product had outgrown that description. It was no longer a garment tool — it had quietly grown to cover most of what a content production team does: product shots, staged scenes, campaign variants, formats per channel. The features had kept arriving. The story about what the product was had not.
That gap matters more than it sounds. A product described as a trick gets navigated like a trick: one entry point, one flow, no need to choose. A product that serves a whole department needs structure — somewhere to start when you don’t yet know which tool you need, and a shape that will still hold the next five features.
The audit is what made the rest of this case study necessary.
05: Design the shell before the features.
A suite of AI tools grows unpredictably. Features arrive before anyone has decided where they live, and the navigation absorbs the damage.
So the first thing I designed was not a feature. It was the shell: what is always on screen, where a new tool lands, and what a user sees when they don’t yet know which tool they need.
06: Choose labels over icons.
We argued about this for weeks, and it was the right thing to argue about.
The generic app-switcher pattern — a grid of icons behind a waffle — is compact and familiar, and it fails the moment your products are abstract. Our tools don’t have obvious shapes. An icon for “generate a scene” is a guess the user has to decode every time.
We moved to a labelled selector that says what each product does. It costs space. It buys a user who knows where they are.
07: Give every tool the same spine.
Each tool does something different, and each one does it in the same four moves: set up, generate, review, use.
Keeping that spine identical means the second tool a user opens costs them almost nothing to learn.
Set upGenerateReviewUse
08: Treat failure as a first-class state.
Traditional software fails in ways you can enumerate. Generative output fails in ways you can’t: it succeeds technically and is wrong, or it refuses, or it produces something unusable for a reason the user can’t see.
Most AI products collapse all of that into one grey card saying something went wrong. That card teaches the user nothing and leaves them with no next action.
09: Write the vocabulary of what went wrong.
So I built an error taxonomy for generated image cards: a shared vocabulary of how generation fails, what each failure looks like in the interface, and what the user can do about it.
It is the least visible work in the product and the piece I’m proudest of. It’s also the part that scaled — every tool added since has inherited it.
10: Break the open prompt into steps.
An empty prompt field is the hardest interface in software. It asks the user to know the answer before they start.
For the more complex capabilities we replaced it with guided flows. Staging a product into a scene became a sequence of decisions a non-expert can actually make — pick the product, pick the setting, adjust — instead of a paragraph they have to compose.
11: Let people edit the result, not regenerate it.
Regeneration is a slot machine: you lose the thing you liked in order to fix the thing you didn’t.
In-painting changes that. The user marks the part that’s wrong and describes only that — the rest of the image survives. It turns a generative tool into something closer to an editor, which is the mental model people already have.
12: Make compliance part of the interface.
AI-generated imagery has to be identifiable as such under EU rules. That can be a checkbox someone forgets, or it can be built in.
We built it in: watermarking happens as part of producing the asset, not as a step the user can skip. Compliance that depends on discipline isn’t compliance.
13: Four products that had never met.
one.O Product Cloud is four products. Create generates content, Engage runs live shopping and shoppable clips, Validate checks content against brand and regulatory rules, Guard handles EU-based security and audits.
They were built separately, at different times, for buyers who overlapped more than anyone had planned for. A customer using two of them noticed immediately: the same action had a different name in each, a primary button was a different colour, and the place you went to find your assets moved. Nothing was broken. The whole thing felt like four tools from four companies.
Merging them is not a styling exercise. It means agreeing what an action is called, where it lives and what it looks like, across four roadmaps that do not share a release date. That is the work my team owns.
14: Give ten generators one spine.
Create is not one feature. It is a catalogue of generative modules: AI fashion photography, product photography, background replacement, upscaling, video, room design, image-to-image, product copy, and a content studio for brand-compliant post-processing.
Each is a different capability. Designed separately they would be ten products sharing a login. They share a spine instead, and the spine is the same four moves everywhere.
| Module | What the user brings | What varies | What stays identical |
|---|---|---|---|
| AI fashion photography | A garment | Model age, gender, ethnicity, body shape, styling | Set up, generate, review, use |
| AI product photography | A product shot | The studio setup | Same |
| Background replacement | An image | The scene | Same |
| Image to image | Two or more images | What gets combined | Same |
| Room design | Furniture images | The room | Same |
| Video studio | An image or a prompt | Length, quality | Same |
| Product copy | A product | Tone, length, locale | Same |
| Upscaler | An image | Nothing | Same, collapsed to one step |
The payoff is that the second module a customer opens costs them almost nothing. They already know where inputs go, what a result card looks like, how to fix one without losing it, and where the output ends up.
Set upGenerateReviewUse
15: Scale the guidance to the number of decisions.
The modules are not equally hard to use, and the difference is measurable: how many decisions does the output depend on?
The upscaler depends on none. You give it an image, you get a bigger image. Fashion photography depends on many, and they are decisions a non-expert does not know they are making until the result is wrong.
So guidance is not a constant in this system. Scaffolding scales with the number of decisions, and the decisions are surfaced as choices rather than requested as prose. Someone staging a garment picks a model and a setting. They never have to write “a woman in her thirties, mid shot, soft daylight” and hope.
An empty prompt field is the easiest thing to build and the hardest thing to use.
16: Make the system readable by machines, not only by designers.
“AI-ready” gets used loosely. Here it means one specific thing: the generation pipeline that builds our interfaces resolves components by querying the design system directly, rather than interpreting a Figma canvas.
That changes what a design system is. It stops being documentation developers consult and becomes the thing that defines what gets built, which means the quality of every generated screen in the company is downstream of decisions my team makes.
17: Run the governance, not only the library.
Maintaining the system is the visible half: tokens, components, documentation, versions, the Figma libraries and who can publish to them.
The other half is orchestration, and it is the one that decides whether any of it is used. It means knowing what each of the four products is about to build, spotting the moment two teams are about to solve the same problem twice, and getting there before both solutions ship. A component added after the fact is a migration. The same component agreed a sprint earlier is just the component.
I run both halves.
18: Turn the recommendation into the standard.
A design system that teams may follow gets followed when it is convenient. The next phase, one.O Connect, makes it the standard that product development has to build against.
That is an organisational change more than a design one, and it is the piece of this work I am proudest of. It moves design from something each team negotiates for itself to something the company has decided once.
19: Make it agentic only where it pays.
The direction after Connect is an agentic system: one an agent can read, query and build against without a human assembling the screen.
The condition matters more than the ambition. We go agentic where it removes real work, not where it demonstrates that we can. The test is whether it shortens the distance between a decision and a shipped screen. Everywhere else it adds a layer to maintain and nothing else. We managed to run an agent that updates the Design System in Claude at night, every 24 hours.
20: Start by auditing against heuristics, not opinions.
Every piece of work here started with a heuristic analysis rather than a redesign. It is the cheapest way to turn “this feels clunky” into a list a team can act on, and it takes the argument out of the room: a violated heuristic is a finding, not a preference.
We discovered that the user could not easily navigate through the processes, there were a tab section dividing the different steps to fill in in Stage an Outfit or Image to Video, so we delivered different proposals and the final one was a wizard that has been implemented across most of the flows in three different products (one.O Create, one.O Validate and ongoing redesign with the wizard in process for one.O Live Shopping). The information architecture was not well hierarchized and not grouped as the mental model of the users, so we optimized it.
21: Test at low fidelity, early, with AI in the loop.
We test low-fidelity prototypes, deliberately. High fidelity invites feedback on colour. Low fidelity gets feedback on whether the flow makes sense, which is the only thing worth changing at that stage.
We use LLM tooling in that loop to get from a flow to something testable faster than a prototype used to take.
We use Claude and Figma Make to build the prototype, we collect and define requirements with Claude, test under edge cases but the users are the final testers. We run testing every big feature or changes in the interaction.
22: Defend it in the room.
A prototype that has been tested still has to survive the meeting. I present and defend the work to stakeholders, where the people in the room have different roadmaps and not the same incentive to agree.
The thing that makes this work is not presentation skill. It is arriving with the finding rather than the preference: the audit said this, the metrics or test showed this, here is the decision it points to.
23: Hand off so the design survives the build.
I do the hand-offs to engineering myself. Not a file drop: the states, the breakpoints, the error cases, the empty cases, the things that only show up when the generation fails.
The error taxonomy earlier in this case study exists because of hand-off. Every gap I had to answer twice became a documented state, and every state documented is one that stops being rebuilt per feature.
24: Collect numbers, then decide what to fix.
We instrument the product and read it. Not to prove that the design worked, but to find the next thing to change.
We review signups by day per product, which campaign links are driving traffic to the signup page, drop-off (where sessions die), how users move between pages, and which errors kill sessions.
At the moment we are focusing on this metric: How many new accounts reached each step of getting started?
25: Separate the two things reported as one.
The most useful result contradicted the expectation.
| What we assumed | What the data showed |
|---|---|
| Hand-off is the bottleneck | Hand-off coordination improved sharply — several meetings per flow down to two |
| Screen production had improved too | It had barely moved, and is now the largest remaining cost |
Those two had been reported as one thing. Separating them changed where we look for the next improvement.
Start with the constraint.
Every decision in this case study came from one sentence: the user has to produce a visual by Thursday and has never written a prompt.
The model will keep getting better without me. The constraint is the part that needed designing.
