Journeys, states and edge cases designed first, including empty, loading, error and permission states, because those are where products feel broken and where engineering otherwise has to improvise. Interfaces for AI get particular attention: showing where an answer came from, and giving someone a way to disagree with it, is the difference between a feature people trust and one they abandon after a single wrong reply. You get a design system small enough to maintain and specific enough to build from, not a deck of concepts.
The same four moves on every engagement of this kind. No discovery phase that bills for months before anything runs.
We learn the job your users are actually doing, and where the current path fails them, rather than starting from an inventory of screens.
Journeys, states and edge cases get designed first, including empty, loading, error and permission states, because those are where products feel broken.
You click through the real thing before anyone builds it. Changing a flow here costs a conversation; changing it after the build costs a sprint.
Components that map to real code, accessibility built in rather than audited later, and the design decisions recorded beside them.
What someone is trying to get done, in what order, and where it currently goes wrong. Screens drawn before that question is answered are decoration, and they are expensive to undo once they are in code.
Empty, loading, error, partial and permission-denied states designed alongside the ideal path, because those are the states where a product feels broken and where engineering otherwise has to improvise.
Showing a confidence level, citing a source, and giving people a way to disagree with the machine. A model that is right most of the time needs an interface that handles the rest, or trust goes on the first bad answer.
Components with named tokens and states, built to match what the front end will actually implement, so the thing that ships looks like the thing that was approved.
Need the product designed before it gets built?
Scope this with usDesigning for a system that is right most of the time is a genuinely different problem. The interface has to make uncertainty legible without making the product feel unreliable, and that is a design decision rather than a model one.
Citations, sources and freshness in the interface, so someone can check the reasoning rather than being asked to trust a paragraph.
Correct it, escalate it, or ask for a person. A product with no route around the model loses trust permanently on its first bad answer.
Model responses arrive slowly and in pieces. What that looks like, and what someone can do while it happens, is designed rather than left to a spinner.
The design is reviewed against what the front end can build this fortnight, so nothing is approved that quietly needs a rewrite to implement.
Contrast, focus order, target size and screen reader behaviour are decided in design, where they cost nothing, rather than in QA where they cost a rebuild.
Interfaces are drawn against realistic content, including the long names and the empty lists, not against placeholder text that always fits.
A flow, the states, and a component set your team can build from. Not a deck of concepts that impresses in a review and helps nobody on Monday.
The questions that come up most on a first call about this practice, answered the way we would answer them on the phone.
Yes. Design engagements stand alone and the handover is written so any competent front-end team can implement it.