A design workflow is the path a UI change takes from the first question about what to build to a merged pull request. It has six working stages: frame, explore, decide, build, check and review. AI made exploring and building cheap. The 2025 and 2026 data shows the time moved to review and rework at the end. Teams that ship front-end changes faster rearranged the workflow around that.
This page is about product design workflows on software teams, not about mapping business processes.
Key takeaways
- Broken into working stages, a design workflow runs from framing a change to a merged pull request: frame, explore, decide, build, check and review.
- AI made writing UI code cheap and review slower. Faros AI found that teams with high AI adoption merged nearly twice as many pull requests, and review time nearly doubled.
- Faster teams cut the handoff, not the review. Prelude's designers went from about 31 days to 13 from idea to merged PR by changing the real product instead of a mockup.
- AI-generated pull requests get accepted far less often than manual ones (LinearB). Small changes, your own design system and a check of the real UI before the PR make them easier to review.
What is a design workflow?
A design workflow is the path a UI change takes from the first question about what to build to a merged pull request. It says what happens at each stage and where the work changes hands.
The classic models describe the thinking. The Design Council's Double Diamond has four stages: Discover, Define, Develop and Deliver. Nielsen Norman Group's design thinking model ends in Implement. A team's day-to-day workflow also has to say where the change gets built and who checks it, so this page uses six working stages:
| Stage | What happens | Where AI changes it |
|---|---|---|
| Frame | Name the problem, the screen, the states and who it is for | AI summarizes research and feedback. Deciding what is worth building stays with people. |
| Explore | Try directions and variations | Canvas and coding agents produce variations in minutes, on your real components if the tool can see them. |
| Decide | Critique, pick one, agree it with product and engineering | Little changes, except there are more options to choose from. |
| Build | Turn the decision into code | Coding agents write UI code fast. This is where the speed-up in the data comes from. |
| Check | Compare the built UI with the intent: states, content, breakpoints, accessibility | Matters more, because generated UI looks right more often than it is right. |
| Review | An engineer reviews the pull request and merges it | The new bottleneck: more pull requests, bigger ones, and longer waits. |
Figma's AI report puts the frame stage plainly: "AI can build almost anything. What it can't do is determine what's worth building." AI changed the speed of the stages after it.
What AI changed in the design workflow: the 2025 and 2026 data
AI sped up the build stage and slowed down the review stage. Whether a team ships faster overall depends on what it did about the second half.
Unlike the year before, Google's 2025 DORA report found a positive relationship between AI adoption and software delivery throughput. It also found that "AI adoption does continue to have a negative relationship with software delivery stability" (Google Cloud). More gets shipped, and more of it breaks.
Individual speed is less clear than most people assume. In a randomized trial by METR, experienced open-source developers took longer to finish tasks in their own repositories with AI tools, while believing they had been faster (METR). METR's later rerun still measured a slowdown. But many developers declined to work without AI, so METR calls that data very weak evidence and thinks AI likely speeds developers up more now than in early 2025 (METR).
Review is where the pattern is consistent. Faros AI found that teams with high AI adoption merged nearly twice as many pull requests. Review time nearly doubled too, and the average pull request more than doubled in size. Across whole companies, Faros found no clear link between AI adoption and improvement (Faros AI). Its newer report found review times about five times longer on high-adoption teams, with more bugs per pull request (Faros AI).
LinearB's benchmarks point the same way. AI-generated pull requests get accepted far less often than manual ones, and wait nearly five times as long for a reviewer to pick them up (LinearB). In Stack Overflow's developer survey, the frustration named most often was "AI solutions that are almost right, but not quite" (Stack Overflow).
The people running these workflows say the same. Mehmet Baytaş, previously a design engineer on Attio's marketing team, told the Hatch conference that his team still reviews every line AI writes. Once the team could produce far more code, it had to add error logging and regression testing.
Designers came to this later than developers. Figma's research found designers less satisfied with AI than developers, because developers used it for their core work and fewer designers did (Figma). A year on, Figma found twice as many designers joining development work (Figma). That puts designers inside the build and review stages, where the bottleneck now sits.
Design and engineering collaboration: two workflows for the same change
Every handoff adds waiting, and every round of rework after QA or review adds more. How design and engineering split the workflow decides how many handoffs a change goes through.
The handoff workflow. A change starts as a mockup, becomes a ticket and gets built by an engineer. QA compares it with the design, and it comes back for rework when spacing or states don't match. Then it reaches review. Figma reports that nearly all designers and developers think the handoff could be improved (Figma). Developers name "differences in assumptions" as their most common challenge when working with designers (Figma). We went through how that plays out in why UX breaks after the handoff. If your team starts from a Figma file, the routes from design to code cover Figma to code and the alternatives.
The design engineering workflow. The designer stays on the change through build and check, and hands engineering a pull request instead of a mockup. A design engineer is a product designer who designs in code and ships their work to production through pull requests, instead of handing off mockups for engineers to rebuild. The guide to becoming a design engineer covers the role in depth.
At Atlassian, principal designer Eduardo Sonnino describes how designers there ship code. They clone the real repository, open it in an AI coding tool and make the change in the running app. Then they open a pull request for engineering to review and merge. Changes that touch business logic, a shared platform library, fragile performance or security are left to engineering.
Engineers keep their role as reviewers. At a designer dinner, nearly everyone we spoke with wanted closer collaboration with them. Christian Bistany, a UX designer at NCCER and a customer of ours, described what that looks like when the designer works on the real codebase: "The biggest value add was being able to make changes in real time, using our design system, and immediately pushing the changes to code for senior devs to review and merge." The career side of that shift is in the new design ladder.
A designer AI workflow example: one UI change to a merged PR
Here is the design engineering workflow on one small, common change. New users see an empty projects table with no next step, and you want a short explanation and a "Create project" button.
1. Frame the change in one sentence
Write what changes, on which screen, and which states it covers: "Replace the blank projects table with our empty state component, a one-line explanation and a Create project button. Cover zero projects, loading and error." That brief becomes the prompt, the pull request title and the checklist.
2. Explore on the real product
Open the product on a branch, with its real components and data, in a coding agent or on a canvas connected to the repository. Ask for three variations that use existing components only. Claude Code and Cursor both work here if you are comfortable in a terminal or an editor. Our guide to Claude Code for designers covers where a canvas fits better.
3. Decide with the people who will review it
Share a preview link with the product manager and the engineer who will review the change, and pick one direction. Show two or three options, not twelve. Cheap exploring makes it tempting to show everything.
4. Build with your design system
Keep the chosen variation and read the diff to check that the AI used your empty state and button components and your tokens. Look for new components and hard-coded hex values. Code style is the reviewer's job. One principal designer we interviewed wants to see code changes "not to check code, but to check agent output accuracy".
5. Check the real UI before the pull request
Run design QA on the running change, not on a screenshot of it: every state, a long project name, a narrow screen, keyboard focus and contrast. Don't trust the AI's summary of what it built. Researchers found that generative UI tools often describe design decisions that their interface does not implement (Design Theater). The design QA process and checklist covers what to compare. The chapter on design QA in code shows how to fix what you find inside the pull request.
6. Open a small pull request and let engineering review it
One change per pull request, with a before and after, the states you checked, and the preview link. When the reviewer asks for changes, fix them on the same branch. The walkthrough of a designer's first pull request covers the mechanics.
How teams ship front-end changes faster with AI
The teams that ship faster removed steps between a design decision and a merged pull request, and kept code review as the gate.
Prelude, a Series A company that builds verification and fraud prevention for signups, is one example. Its designers used to explore in Figma while engineers built in the codebase, and ideas queued behind engineering capacity. After they started prototyping and shipping UI on their own codebase, idea to merged pull request for that work dropped from about 31 days on average to 13. Handoffs per feature went from five or more to one (Prelude customer story).
"It's something I'd wanted to prototype for a long time - I did it in five minutes, with real data. That prototype ended up as a PR we merged," said Quentin Le Bras, Prelude's Chief Product and Design Officer.
We tried the workflow on our own website with our own product, Modeinspect. It works on Next.js React codebases that use Tailwind, and a new project can start in it and become a GitHub repository. In July a teammate updated our pricing page on a running copy of the site and opened the pull request from it. It merged ten days later. He skipped explore and decide because he already knew what he wanted, which is fine for a small, settled change. His notes were blunt: iterating with the agent directly in code felt fragmented, with too many steps between one change and the next check. Every tool in this workflow still has rough edges like that.
Four practices come up again and again, and each answers a problem in the data:
| Practice | The problem in the data | What changes |
|---|---|---|
| Cut the handoff, not the review | Nearly all designers say the handoff could be improved (Figma) | Mockup, ticket and reconciliation steps go away. Review stays. |
| Keep changes small | Pull requests more than doubled in size, review time nearly doubled (Faros) | Small pull requests get picked up and reviewed. |
| Reuse the design system | Refactoring down and duplicated code up since 2023 (GitClear) | No parallel components or tokens to maintain. |
| Check the UI before the pull request | AI pull requests accepted far less often than manual ones (LinearB) | The visual check happens before review. |
The same logic applies to prototypes. A prototype built outside the product has to be rebuilt before it ships, so build the prototype in the production codebase and there is nothing to port.
What still breaks
Three things break repeatedly, and a better model alone fixes none of them.
Review capacity. If every designer can open pull requests, engineers see more of them. Small, scoped changes with a preview link are the mitigation. Where we have seen designers start shipping, the work is front-end and mostly visual, with a merged pull request as the goal.
Trust. Designers we interview expect what they design on the canvas to reach the code intact, and some distrust components an agent invents. Reviewers have a threshold too. A design lead told us a slightly off color is tolerable, but wrong padding or scrambled information gets a change rejected. Test any tool on your own components before rolling it out.
Accessibility. A study of AI-generated web UIs found they can look visually coherent yet "frequently violate Web Content Accessibility Guidelines (WCAG)" (A11yn). Keyboard and contrast checks belong in the check stage, before a reviewer has to catch them.
How to tell if your design workflow got faster
Measure the whole workflow. Three numbers are enough:
- Time from decision to merged pull request for a UI change.
- Handoffs per change: how many times the work passes between people before it merges.
- Corrections per pull request: how many things an engineer has to fix or send back. Our engineering lead proposed it for a team pilot in place of diff size. It counts the work a reviewer does.
If the first number falls while the third stays flat, AI is helping. If the first falls and the third climbs, the work has moved to your reviewers.
Frequently asked questions
How is a design workflow different from workflow design?
Workflow design maps business processes, such as approvals or onboarding steps, usually in a diagramming tool. A design workflow is the path a UI change takes from the first question about what to build to a merged pull request.
What are the stages of a design workflow?
Classic models such as the Double Diamond use Discover, Define, Develop and Deliver. A product team shipping UI changes can work in six stages: frame, explore, decide, build, check and review.
Does AI make front-end development faster?
Across teams, AI adoption now goes with higher delivery throughput. Review time rose with it, so the whole workflow gets faster when teams also remove the design-to-code handoff, keep changes small and check the UI before review.
Do designers need to learn to code to work this way?
No, not to write code from scratch. A designer can make a visual change on the real React codebase with an AI coding tool or a design canvas and open a pull request. Engineers still review and merge, so the designer needs enough literacy to read the diff.