one.O Engage
Live has no undo.
Most software fails quietly. You see the error, you fix it, you ship again, and almost nobody noticed.
A live shopping show fails in front of everyone watching, at the moment it matters, with no rollback and no second take. That single fact decided most of the design in this product.
01: Start with nothing and decide the shape.
I built this one from zero. No existing product to audit, no screens to inherit, no decisions already made by someone else.
That is the rarest brief a designer gets and the easiest one to waste. With nothing in place, the temptation is to start drawing the interesting screen, the one with the video player and the chat. The useful thing is to decide the shape first: who the product has, what each of them is doing, and which of those people is actually blocked without it.
TO ADD: what existed before, what triggered the project, and what you were given on day one.
02: Four surfaces, one event.
Live shopping looks like one product. It is four, and they share nothing except the show.
| Surface | Who is on it | What they are doing |
|---|---|---|
| The backend | An operator, at a desk, days ahead | Creating and scheduling shows, attaching products |
| The streaming app | A host, on a phone, about to go live | Presenting, reacting, selling |
| The shop embed | A shopper, in the retailer's webshop | Watching, asking, buying without leaving |
| The clip player | A shopper, any time afterwards | Watching on demand, buying from the video |
Four contexts, four states of mind, four tolerances for complexity. The operator can handle density because they are planning. The host can handle almost none, because they are on camera. The shopper did not come for your interface at all.
Designing these as one product is how live shopping tools end up with a backend bolted to a player.
03: Design for the minute you cannot fix.
Everything in a live show is irreversible. The host cannot undo a tap. The operator cannot push a fix mid-stream. A shopper watching a broken moment is watching it with everyone else.
So the rules are different from a normal product. Destructive actions during a show need more friction, not less. States that are merely annoying elsewhere become unacceptable here, because there is no time to read. Anything the host has to find while talking has to be findable without looking.
The test I used for the host interface: could someone operate it while holding a conversation with a camera. If an element failed that, it moved to the backend or it went away.
04: Make the backend hold the complexity.
The scheduling backend is where everything difficult goes. Creating a show, setting the time, attaching the product list, preparing what the host will need.
That is deliberate. Every decision made here in advance, calmly, is a decision the host does not have to make live. The backend absorbing complexity is what lets the streaming app stay almost empty, and an almost empty streaming app is the whole reason a single person can run a show.
05: Let one person go live from a phone.
The streaming app exists so a show does not need a production team. One host, one phone, and the show that was prepared in the backend is already waiting.
Which means the app’s job is mostly restraint. What the host needs while live is small and does not change: what is on air, what is selling, what is being asked. Everything else was either decided beforehand or is not needed.
06: Keep the shopper in the shop.
The player is embedded in the retailer’s own webshop with a single snippet, and the show runs inside the shop rather than sending anyone to a separate destination.
This matters more than it sounds. Every step between watching and buying costs conversion, and a shopper who has to go somewhere else to watch is a shopper who was never going to come back. Chat, products and checkout sit in one view, and the shopper buys without ever leaving the page they were already on.
07: Give the show a second life.
A live show is an expensive thing to produce and it is over in an hour.
Shoppable clips are the answer to that: the content becomes a shoppable video afterwards, with the products still attached, available to anyone who was not watching at the time. Existing social content comes into the same system the same way.
It changes what the product is worth. Live shopping on its own is an event business. With clips it becomes a content library that keeps selling.
08: Let the assistant answer what the host cannot.
During a show the chat moves faster than one person can read, and most of what arrives is the same handful of questions about sizing, delivery and stock.
The Live Shopping Assistant handles that layer: suggesting answers to live questions so the host can keep presenting, and answering on the clips long after the show has ended, when there is no host at all.
09: Inherit the system instead of building one.
A new product is normally where design systems go to be reinvented. Different team, different deadline, nothing to reuse, so it grows its own components and its own idea of what a button is.
This one runs on the same design system as one.O Create. Same tokens, same
components, same interaction patterns, with secondary carrying its own product
identity and primary shared with everything else in one.O Product Cloud.
Adopting rather than inventing costs something up front. It means accepting decisions you did not make, and occasionally designing around a component rather than drawing the perfect one.
10: That decision is the reason it is still here.
one.O Create is the best-funded project in the company. Engage is not.
Because they share a system, the investment that goes into Create arrives here too. A component improved for Create is improved for Engage. An accessibility fix lands in both. Engage is maintained at a cost no one has to argue for, because the maintenance is already happening somewhere else.
That is the strongest argument I have for design systems and it has nothing to do with consistency. A shared system is how a small product survives a budget round. The products that get cut are the ones that cost their own line item.
11: Test it before it is live in front of customers.
We ran tests with hosts and shoppers. We found that hosts had little time to reply to users, so we integrated an AI bot replying messages with the possibility to review by the host before launch or launch without reviewal. With users we discovered that they could not read small texts or missed interaction emojis.
12: It runs in production, for real retailers.
GRUBE, Otto, Casio, Super Streusel, Einhell, Sport1, mey, ROFU, EMP, Brandsome and Channel21 are clients.
Build it so someone else can keep it.
I built this product from nothing, which is the part that sounds impressive.
The decision I would defend hardest is the unglamorous one: putting it on somebody else’s design system instead of its own. It is still running, still maintained, and still getting better without a budget of its own, because of that. Although there is room for improvement, the maintenance is sometimes harder, and we need to review the processes.
