The generation worked. Everything around it was the product.
In a chat window, generation is the product. In an enterprise system it is not. There the image is not finished on its own, it has to travel through a process before anyone can use it, and the value sits in the layer around it: how you start a job, how you experiment and refine, how you pick what is good, and how you hand it on. And on the other side: where things get configured, what happens to the work once it is handed over, and how you know where it stands. That layer was the job here. It was made under an NDA, so there are no screens, no client name and no product name.
Senior Product Designer
- Product Design
- Systems Thinking
- Prototyping
The most important moment is the one where someone starts. What greets them is an almost endless form with no visible end to it, and some of the fields ask for knowledge they do not have. They did not come here to learn. After a while you also stop knowing where you are, and what will happen when you press something.
The team explained what they were planning on the data side, and a different route came out of that. The user answers only what is strictly needed, and nothing sits empty in front of them. A breadcrumb in the top bar says where you are and gives you a way back. An empty form asks whether you know the answer. If you do not, that is where you stop. A filled-in starting point asks whether this is right, and anyone can answer that.
Context
People are used to it by now: talking to an LLM gets them to information and through tasks faster than before. That kind of integration has become ordinary, and it is no longer a separate feature, it is part of the process.
It worked well here too, and part of the work was making it carry people further through the flows.
Approach
After the brief I did not start designing, I started with a UX audit. I went through the system the way its users do, and while doing that I gathered information and feedback from the decision makers as well: what they see, where the pain is. I did not look at it screen by screen but flow by flow, because the trouble is rarely inside one screen. It is between two steps.
What I found only went on the list if I could anchor it to something: a case I had watched, a principle the brief itself set out, or a transition that leads nowhere. Anything that did not fit went on a separate list as a suggestion.
Starting point
What we knew
What we didn't know
What we knew
- The generation worked, and a lot of the functionality was already built.
- There was a list of what they wanted next.
- Some of the people using it are not technical.
What we didn't know
- Whether there were blind spots, gaps they had not seen themselves.
- What I could build on: whether a design system existed, and whether I would see the code.
- How they would review the work: in a Figma file, or in something they could click through.
The question was never what to fix. Most of the individual items were symptoms of the flows. Of the three above, the last one is what decided how the rest of it went.
System
An example, not from this project, but the same situation. There is a Delete button on three screens. On one it asks whether you are sure. On another it deletes straight away and offers to undo. On the third it does not delete at all, it moves the thing to an archive. Same word, three different consequences. By the third time you stop pressing it. What had to be standardised was which solution belongs in which situation. Not that every screen looks the same, but that the same task gets the same treatment everywhere.
The library
Built alongside the prototype, with do and do not use notes, so the developers had less to work out.
- 01
Tokens, not raw values
Components could not carry raw values. Whenever a new one came up it stopped me, because there was a decision to make: does this become a token, does an existing one cover it, or is it not needed at all. The question is the same every time. Is this part of the system, or a one-off?
- 02
Reuse before building
Where a component already existed I used it rather than building another one next to it. So if something has to change, it changes in one place, and there are no individually assembled elements to hunt down one by one.
- 03
The same stack
They worked in the stack I usually work in: Next.js, Tailwind, TypeScript. The components and the tokens did not go over as a reference, they went over as code that runs. What I built could be lifted across as it was.
The rules the repository kept
A set of rules I built by, enforced by the repository rather than by memory.
- 04
Pushing is blocked by default
The resting state is not that it goes, it is that it waits until I say it can. Checks run before every commit, and they have to pass.
- 05
Linting, types, tests
The linter and the type checks ran alongside, and the logic got tests. That way the prototype behaves the same every time, and a demo cannot surprise me.
Iteration
The first time I showed the prototype was the turning point. From then on I was not sending a Figma link with an explanation next to it. I sent the prototype route, the link to the part I had just built, and after a pull they could look at it. Or I recorded myself clicking through it. Or we jumped on a quick call and I showed it there.
The whole iteration got faster because there was less to explain. I was not describing what would happen, they pressed it and saw. And when they did not understand something in the prototype, that was a signal in itself: something there is not clear enough, and the problem is not that they were not paying attention.
Lessons
Figma was part of what had to be delivered. It was a required piece, so dropping it was not an option.
The prototype, though, became the thing I developed first. Whatever got approved in it, I carried into the file with the Figma CLI, as screens, with the explanation alongside.
Then it turned out they much preferred working with the prototype. I wrote notes and rules next to the Figma screens, but the prototype speaks for itself without them. You click, and you see what comes next, what changes, and what disappears. States and flows became clear faster that way.
From then on the prototype was what I showed and what decisions were made on. Figma did not become less useful, its job changed. It stopped being the place where the decision is made and became the place where it is recorded.
See another case study
