Design has always been the work of figuring out what to build, who to build it for, and whether it’s actually valuable to them. Long before AI entered the picture, designers captured, verified, and documented that thinking into a plan to build. They did this through artifacts and practices made for the purpose: sketches, wireframes, flows, prototypes, user testing. Each one externalized a judgment call so a team could react to it, argue with it, and build on it. That work used to unfold at a human pace (sketch, review, revise) over days or weeks.
This work has never been the designer’s alone, but designers often lead on viability, usability, and desirability. The job hasn’t changed. What’s changed is that it now happens with an LLM in the loop, and under real pressure to move faster. There’s pressure to organize concepts, drive alignment, and make decisions more quickly than before. That pressure strains more than the artifacts. It strains the whole system around them: the approach, the process, the tools, the way we gather knowledge, make bets, and build shared understanding as a group. That system was tuned for a slower rhythm, and the LLM is compressing it. It shows up as two things at once: a partner you create with, and a stakeholder whose output you have to account for.
It’s a familiar arc, with a new partner and stakeholder in it.
Designers already have a process for this: discovery, then definition, then development, then delivery. What’s new is that an LLM is now present at every stage of that arc, and it isn’t playing one fixed role. It’s partnering with you to explore and generate, and at the same time acting as a stakeholder whose output you have to align to and build on. Early in the arc it’s mostly a partner. The closer you get to shipping, the more of your attention goes to managing it as a stakeholder. And the balance shifts again as the model’s own capabilities improve underneath you. The last two stages have also started to run together, because once you’re building in the live codebase, the prototype is the product.
Discovery: surveying wide before narrowing.
Discovery has always meant surveying a wide space before committing to a direction, sketching several framings of the problem rather than jumping straight at one. Voice and chat with an LLM fit naturally here, because the goal is exploration, not precision, and talking something out loud mirrors how a designer thinks through a few framings before one sticks.
Even here, the LLM is already both things at once. It partners with you, thinking through framings alongside you, but it’s also a stakeholder, because whatever it says starts shaping the space you’re exploring. You have to stay deliberate about what you feed it and what you let it steer.
Using voice with an LLM here has proven to be valuable. Start by giving it context: a short handoff brief at the top of a chat session, or whatever you already know about the problem, so it has something real to work from instead of guessing. Then use the back and forth to shape your ideas, staying clear on what you actually want out of the conversation rather than letting it wander. And close the loop by capturing what came out of it and pulling that back into the project’s shared knowledge, so the thinking doesn’t evaporate when the session ends.
Definition: point and shape, don’t just describe.
Definition is where it all comes together. The work becomes shaping an experience that meets the user’s needs and values and delivering it in a way they can feel, while balancing that against the technical constraints and making sure the feature is valuable to the product as a whole. It’s the team holding desirability, usability, viability, and feasibility in the same frame. The artifacts that capture that thinking haven’t gone away: you’re still producing the research synthesis, personas, journey maps, flows, and requirements that align everyone. What’s new is that you can lean on an LLM to help shape them: synthesizing notes, pressure-testing a persona, drafting requirements, and poking holes in them. You still make the artifacts, and the LLM helps you get to sharper versions of them faster.
Getting Concrete
But it’s a tool, and it cuts both ways. You can use it to aid your thinking and get to better artifacts and decisions than you’d have reached alone. Or you can take the shortcut and let it do the work for you, which quietly hollows out the understanding and judgment that definition depends on. The output can look the same either way, so the discipline is to keep doing the thinking yourself.
As definition gets more concrete and you start shaping actual screens and flows, it helps to have more than words to communicate with the LLM. You can still describe what you want, but showing is especially useful when you don’t have the words readily available for what you’re thinking or feeling. If part of a layout isn’t working, the fix is usually the easy part. The hard part is breaking down what’s wrong and translating a vague feeling into a precise verbal spec from a blank page. That’s daunting, and it’s easy to stall out there. Having other tools in your belt, ways to show intent rather than only describe it, gives you a way through.
A Tool Like Paper
This is where a tool like Paper earns its place. The diverging concepts themselves come from the LLM, and Paper handles the translation. It takes a rough concept built in HTML, JavaScript, and CSS and nearly instantly brings it onto a canvas where you can manipulate the components directly as vectors. That lets you diverge and converge in one motion. Instead of describing what’s wrong, you point at it, rearrange it, and pull the pieces you like from several concepts into one consolidated version right on the canvas, then feed that back to the LLM as your next instruction. A canvas with real layout underneath it lowers the cost of shaping and gives you something concrete to react to instead of a blank page. None of these concepts are meant to ship. They exist to help you decide what to build.
The stakeholder side gets louder in definition. Now you’re negotiating with what the LLM already produced, curating and overriding it the way you’d push back on a stakeholder’s first cut of a request, to keep the work aimed at real user value. And you often can’t tell whether it’s right or wrong. The output reads as confident either way, so you have to think critically about it and give it specific, well-scoped asks rather than taking what it hands back on trust.
Development and delivery: building it for real is where the understanding gets spent.
Once you know what to build, the work becomes building it, and with an LLM the last two stages of the arc run together. The concepts from definition did their job and get converted. The prototype is now the product: a working build in the real codebase, with the real components, data, and constraints, refined until it ships. Building it and getting it ready to ship are the same work, with no handoff between them.
That’s why Figma has felt increasingly slow at this stage. Part of it is the manual building, but mostly a Figma file becomes a second source of truth that quietly drifts from what’s in the product. Working against the live codebase keeps design and reality locked together. When you want to change something, you change the thing itself, and the LLM can turn a well-scoped ask into working UI in minutes.
Where Understanding Is Spent
This is also where everything you learned in discovery and definition gets spent. You know who the user is, what they’re trying to do, and where the problem actually hurts, and now you apply that to hundreds of small calls about how the product behaves: which edge cases matter, what an empty state should say, whether a step can be cut. Those calls decide whether a solution works for real people or only works in the demo.
This can go well or badly. Done well, the understanding carries through faithfully, and the shipped product feels like the one you defined. Done badly, it gets watered down. Moving fast with an LLM makes that easy, because when your ask leaves a gap, the LLM fills it with a plausible default. One default won’t sink anything, but dozens of them, made in a hurry, add up to a product that has drifted from the user you spent weeks understanding, without anyone deciding it should.
One Thing at a Time
The way to protect it is to work one thing at a time. Pull a single piece of the UI, or one step of a flow, out on its own, refine it with the LLM without disturbing the rest, and merge it back into the shared product. An isolated change is one you can describe precisely and check against what you know about the user. By now the way you communicate intent has tightened all the way down, from wide exploration in discovery, to shaping concepts in definition, to small, specific changes here.
The merge is where the LLM is at its most stakeholder-like. It writes into the shared product, so whatever it gets wrong lands where everyone else is working. And it can easily work from a stale picture: an old screenshot, a concept from definition, a pattern the product moved away from weeks ago. Keeping it aligned takes the same discipline you’d use to keep a stakeholder from working off a stale deck. Before anything goes back in, check it against the product as it stands, and against the user you set out to serve.
The Takeaway
There’s no single right way to work with an LLM on a product, because it’s never just one thing. It’s a partner you explore with and a stakeholder you have to align with, in different proportions at each stage. In discovery, lean on it as a partner and stay aware of what you let it steer. In definition, use it to sharpen your artifacts without letting it do the thinking. When it comes to development and delivery, keep it pointed at the real product, and make sure the understanding you built is what actually ships.
The job underneath is the same one designers have always had: figure out what to build, who it’s for, and whether it’s valuable. What’s changed is the pace of that work and how intent gets carried through it. And because the models keep getting more capable, the balance between partner and stakeholder won’t hold still. Re-check it on each project instead of assuming last year’s habits still fit.