I have seen teams convince themselves that shipping fast and iterating later is the same as getting it right. It is not. The cost does not go away. It just moves to a place where it is harder and more expensive to fix.
The risk I see most often in fast-moving environments is what is called context loss. Design does not happen in a vacuum. Processes change. Policies get updated. Legal requirements shift. Product decisions get made in rooms design was not in. A design that was correct on Monday can be strategically wrong by Thursday, not because the designer made a mistake, but because something changed outside their line of sight and no one caught it before it shipped.
Design review is not just a quality check on the design. It is a forcing function for cross-functional communication. When you remove it, you remove the moment where misalignment gets caught. The faster teams move, the more intentional that communication infrastructure needs to be, not less. That is a counterintuitive truth that I have had to advocate for more than once.
Speed changes how I execute. It does not change what I am responsible for.
I hold an unconditional line on quality whenever a compromise would meaningfully degrade the user experience, especially for users who already know the product. When you change something a user has already learned, the bar is higher, not lower. Regression in a known experience erodes trust, and that trust erosion has real product impact that shows up in retention and support volume.
The practical way I hold that line without slowing teams down is making it explicit before work starts, not negotiating it in the moment when everyone is under pressure. At the beginning of any sprint or release cycle I make sure the team knows what design will not compromise on. Non-negotiable: accessibility standards, established design system component behavior, core user flows that have been validated with users. Negotiable: visual polish on edge case states, animation timing, iconography selection. When people know the boundaries in advance there are no surprises and no time wasted on conversations that were always going to have the same outcome.
This is the question I get asked most often right now. My answer is direct: AI changes the speed of production. It does not change what requires design judgment.
When a developer generates a UI in Lovable in 20 minutes, design still owns:
- The design system as the source of truth — which components exist, how they behave, when to reuse and when to introduce something new.
- Accessibility — because generated UI passes visual inspection and fails screen reader testing with regularity.
- Information architecture and user flow logic — because AI generates screens, not systems.
- The craft review — the trained eye that catches what is technically correct but experientially wrong. Spacing that is mathematically even but visually unbalanced. Hierarchy that follows rules but does not guide the eye.
- Prompt quality as a design skill — writing precise, on-system prompts that produce components aligned with the design system, so quality happens at the point of generation, not as cleanup downstream.
One thing I would add that I do not hear talked about enough: prompt quality is a design skill now. The designer who can write a precise, on-system prompt that produces a component aligned with the design system is more valuable than one who only reviews output after the fact. Quality at the point of generation is more efficient than quality assurance downstream. I think about this as the new front line of design craft, and I think design leaders who do not develop fluency here will struggle to stay relevant.
The framing I would use with my teams: AI generates, design governs. The speed of generation increases the importance of governance. It does not decrease it.
Traditional end-of-sprint design review was built for a two-week cycle. It does not scale. Here is how I think about structuring review when the pace accelerates.
I would use three models depending on the risk level of what is being shipped.
For higher-stakes work, significant feature launches, anything touching a core user flow, I would use what I call a Design Review Board. A standing cross-functional group with a pre-agreed checklist and a time-boxed window. The practices that make it fast rather than slow: the checklist is defined before the sprint begins, the review window is non-negotiable (24 hours, not whenever you get to it), and the default is approve. Silence means nothing was flagged. The board reviews for system-level concerns only, not personal preference.
For routine sprint work, I would use an Async Checkpoint System, review built into the sprint rather than bolted on at the end. Three checkpoints: flow and information architecture before visual design begins, component selection and design system alignment before build begins, final quality gate before handoff. Each checkpoint has a designated reviewer and a fixed response window. This catches problems when they are cheap to fix, not after they have been built.
For high-velocity teams shipping continuously, I would use a rotating Design Critic role, one senior designer per sprint whose explicit job is to review all work against the design system and quality standards. Not everyone reviewing everything. One person with clear authority and a defined checklist. It is faster, more accountable, and it keeps every senior designer calibrated across the whole product, not just their own area.
In practice I would combine all three based on risk: the Design Critic as the ongoing baseline, the Review Board for significant launches, and the Checkpoint System as the infrastructure underneath both. The design leader's job is to define which level applies to which type of work and to make that call before the sprint starts.