How it used to go
The workflow is always the same. Product defines a feature. Designer opens Figma. Development waits.
A few days later, a link arrives in Slack. The team opens it and finds the happy path, looking clean and polished. What they don't find: the empty state, the error message, the loading spinner, the mobile layout for the navigation, and what happens when someone's display name is 63 characters long.
So the developer asks. Sometimes they get answers. More often they get "just do something reasonable" or "we'll handle that later". The developer makes the call and implements it. Then someone reviews the feature, disagrees with that call, and back it goes.
In my experience, what comes out of Figma is more of a starting point than a specification. The real design work happens during and after implementation, through reviews, feedback rounds, and iterations. The mockup is just the opening move.
This is not a problem with designers. It's a process design problem. And process problems are worth fixing.
What AI tools changed
Tools like v0, Claude, or Cursor can generate reasonable UI code from a plain text description. Not award-winning design. Not pixel-perfect layouts. But something workable that covers the basic structure, handles states, and gives you something to iterate on.
That changes the calculation significantly.
If a developer can describe a feature and get back a usable first draft of the UI in a few minutes, the mockup stops being a prerequisite. Work starts. The design becomes iterative from the beginning rather than a gate everyone waits in front of.
The part that makes this stick: the design decisions that used to get deferred to implementation time are now just... made during implementation. By the developer, with AI. Which is mostly what happened anyway, just without anyone acknowledging it.
You save time. You ship sooner. You have something real to react to.
UX/UI becomes a quality gate
None of this means UX/UI designers are less important. It means the point in the workflow where they add value shifts.
Instead of producing the initial design, they review what got built and drive it toward something good. That's not so different from QA. Testers don't write the code they test. They verify it, find the gaps, and send it back with clear feedback.
UX designers can do the same thing. A developer ships a first version. The UX person goes through it: this button needs more weight, the mobile spacing is off, we need a confirmation step here before the destructive action. The developer or AI fixes it.
For teams that already do design reviews and iterate in short cycles, this isn't a big conceptual shift. It's just moving when the design contribution happens from the very start of a feature to just after the first working version exists.
Arguably, this is also when design feedback is most useful. Looking at a real screen in a real browser is different from looking at a Figma file. Edge cases surface. Interaction details become visible. Things that looked fine in the mockup reveal themselves as awkward in the actual flow.
Write specs, not wireframes
Here's the part that doesn't get talked about enough.
The most valuable thing a UX designer can produce right now is not a wireframe. It's a specification.
Not a PDF. Not a Confluence page nobody reads. A plain text file, committed to the repository, that describes how a feature should behave.
What happens when a user submits a form with invalid data? What are the edge cases for the search? What are the accessibility requirements for this screen? What does the empty state say? What is the exact wording of the error message?
These are hard, valuable questions. Right now most teams either skip them entirely or bury the answers somewhere they'll never be found again.
If these answers lived in a spec.md file next to the code, AI tools could actually use them. Instead of a developer guessing what the error message should say, the AI reads the spec and gets it right the first time. Instead of an accessibility requirement getting forgotten, it's in the file and gets implemented along with the feature.
This is something a Figma file simply cannot do. You can't ask an AI to "implement this feature according to the Figma file and handle all the edge cases". You can ask it to "implement this feature according to spec.md".
A spec in the repo is also a living document. It gets updated when the feature changes. It gets reviewed in pull requests. It doesn't drift from the code the way a design file inevitably does.
Done well, a spec also enforces consistency across the product. When the exact wording of an error message, the behavior of a loading state, or the language used in confirmations is written down and version-controlled, it becomes a shared reference. Not just for this feature, but for the next one that touches the same surface. Without it, every developer makes independent judgment calls, and the accumulated result is a product that behaves slightly differently depending on which corner you happen to be in.
What this means in practice
I'm not saying every team should immediately throw out their design process. But I do think the traditional sequence, where development is blocked until design delivers, is becoming harder to justify.
The useful shift is: start implementation with a description and AI-generated scaffolding, then bring in UX to review and refine. Write specs as text, commit them alongside the code, and let AI use them during implementation.
Design work doesn't go away. It just stops being the thing you wait for and becomes the thing you do continuously, based on something real.
Every time I've pushed a team to try this, the result was the same: features shipped faster, the feedback loops got shorter, and the design that ended up in production was better because it was shaped by a real, working screen rather than a static file.
