Illustrative line chart titled “The Accordion Effect: Design Roles & Stages Over Time.” Relative number of roles and process stages rises from about 1995, peaks around 2014, then falls toward 2025. Era labels: Web craft; Specialization boom; Components & systems; AI / vibe-coding. Markers for Sketch (2010), Sketch Symbols (2014), Figma + Atomic Design (2016), and AI agents (2025). Footer notes the chart is illustrative, not survey data.

I have watched design organizations inflate and then fold for more than a decade. Call it a fashion cycle if you like. I see a systems response to the cost of change. From the mid-1990s through the early 2010s, building a web product meant more specializations and more process stages every few years. One person shipping a site became designer plus developer. Graphic design split from UX. Interaction, motion, content strategy, CX, research, and dedicated QA each claimed a seat. The process followed: requirements, wireframes, clickable prototypes, Photoshop comps, sliced assets, then code, with hallway tests and prototype reviews stuck in the seams.

That structure was not vanity. It was insurance against expensive rework. Today the insurance premium has changed. Components, shared libraries, and now AI-assisted production collapsed the cost of changing pixels and flows. The accordion is closing. One person can once more build a near-final product and redo the UI in half a day by directing an agent. That is real. The fantasy is that the cost of being wrong collapsed with it.

The accordion opened for a reason

In enterprise products I’ve worked on, role multiplication tracked friction more than ego. When changing a button color meant opening hundreds of flat mockups, editing, re-exporting, and re-slicing, you paid people to catch mistakes early. Grayscale wireframes were cheap relative to high-fidelity comps. Axure (from the early 2000s) and Balsamiq (from 2008) existed because clickable intent was expensive to get from Photoshop and even more expensive to discover only after engineering had built the wrong thing.

The informal rule many of us internalized was roughly: each later phase is an order of magnitude harder to change. That intuition has a named ancestor. Barry Boehm’s Software Engineering Economics (1981) popularized a steep cost-to-fix-or-change curve across the software life cycle, based on industrial data showing that late fixes cost far more than early ones, often by roughly an order of magnitude per phase on a logarithmic view of the data (Boehm, 1981; see also contemporary discussions of the curve’s evidence and limits, e.g. ReworkCost on Boehm’s curve). The curve was born in waterfall-era software economics. Design borrowed the logic: freeze early artifacts, specialize handoffs, and treat high fidelity as a late, costly commitment.

From a systems-thinking view, roles and stages were buffers against rising change cost. When change is expensive, you insert gates. When change becomes cheap, gates become dead weight. Organizations that keep the gates after the cost structure shifts call it “maturity”. They are optimizing for yesterday’s economics.

Components closed the first fold

The first mechanical collapse came years before AI, and it was boring: reusable UI.

Sketch shipped in September 2010 as a Mac-native UI tool. In April 2014, Sketch 3 introduced Symbols: update once, propagate everywhere. That single capability undermined the Photoshop-era justification for endless parallel mockups. Figma opened to the public in September 2016, with multiplayer editing and, soon after, components that made shared systems practical across teams. Brad Frost’s Atomic Design, also published in 2016, gave the industry a shared language for atoms → molecules → organisms → templates → pages. Clickable prototypes moved inside the design tool. Separate grayscale theaters and Axure/Balsamiq-only click paths became optional rather than mandatory.

Roles merged in practice before org charts admitted it. UX and UI collapsed into product design in many teams. Motion stopped being a specialty-only gate for every screen. The accordion started closing: fewer stages between intent and a testable interface, fewer people required to keep a system consistent.

Illustrative grouped bar chart comparing cost of change (teal) versus cost of being wrong (terracotta) across three eras: Waterfall/Photoshop, Components & Figma, and AI/vibe-coding. Change cost falls from 9.5 to 1.5; wrongness cost stays near 8. Subtitle: “Production friction fell. Problem-framing risk did not.” Footer states bars are qualitative indices.

AI collapses production further, and that is the easy part

The second fold is sharper. With AI-assisted and “vibe-coding” workflows, a working near-final product can appear faster than a requirements document, a polished prototype, or a finished design system. You can put something in front of real users before the old process would have finished arguing about wireframe fidelity. Changing the UI is no longer a multi-week cascade; it can be a half-day conversation with an agent plus a cleanup pass.

I am not romantic about this. Quality still varies. Agents still invent inconsistent spacing, dubious copy, and decorative nonsense. But the marginal cost of visual and interaction change has fallen far enough that many production stages no longer pay for themselves. If the only job of a stage was to make pixels cheaper to revise, that stage is obsolete.

This is where teams get it wrong. They see speed and conclude that design collapsed. What collapsed is production ceremony. Design judgment did not get cheaper.

The cost of change collapsed. The cost of being wrong did not.

Boehm’s curve described the cost of changing or fixing software late. Component systems and AI flattened the part of that curve that lived in UI production. They did not flatten the cost of misunderstanding users, shipping the wrong information architecture, encoding a brittle data model, failing accessibility, or violating regulatory constraints. Those failures are still expensive, sometimes even more expensive, because you can now produce the wrong product at impressive speed and scale it before anyone notices.

In enterprise work, “wrong” usually means:

  • Solving a proximal workflow while the real job-to-be-done sits elsewhere.
  • An IA or domain model that forces every feature into a dead-end taxonomy.
  • Accessibility failures that exclude users and create legal exposure.
  • Security, audit, and compliance paths that cannot be retrofitted cleanly once the product shape is set.

Faster production without better framing is a high-throughput error amplifier. The accordion should close on stages that buffered change cost and stay open on stages that buffered wrongness.

Where collapse works and where it does not

Collapse works where you can ship, observe, and revise against real usage with low blast radius: internal tools with friendly users, early B2B wedges with a handful of design partners, consumer surfaces where analytics and rapid release are honest feedback loops.

It works less cleanly in the enterprise and regulated contexts I know best (healthcare, oil and gas, biotech, finance), and the reasons are structural:

  • Limited user access. You often cannot put half-baked software in front of clinicians, operators, or traders without approvals, training constraints, or safety review. “Test on real users tomorrow” is not always available.
  • Security and tenancy. Multi-tenant boundaries, audit trails, and permission models are not vibe-coded safely as an afterthought.
  • Compliance and accessibility law. Accessibility is not a polish pass. In the EU, the European Accessibility Act (Directive 2019/882) has applied accessibility obligations to covered products and consumer services from 28 June 2025. Getting a11y wrong means remediation work, legal risk, and lost trust.
  • Domain coupling. If the data model is wrong, no amount of agent-driven UI regeneration saves you. You rebuild the product’s bones.

So the accordion does not close uniformly. Consumer and early-stage product teams can collapse further than regulated enterprise teams. Pretending otherwise is how you get beautiful demos that cannot ship, or shipped systems that fail the first compliance review.

Design systems after the accordion

Components already collapsed a generation of prototyping. The next job of a design system is different: keep AI-generated UI on-system.

Tokens, spacing scales, typed components, content patterns, and accessibility rules are no longer primarily documentation for humans who might forget the brand. They are constraints for generators. A system that only lives as a Figma library will lose to a system that also lives as code, lint rules, and a11y checks the agent must satisfy. Specs matter more when production is cheap, because production without constraints floods the product with near-misses that look finished.

In practice, that means fewer people painting screens and more people owning the contract: what is allowed, what is accessible by default, what breaks tenancy, what must never be invented by a model. The design system’s value migrates from “speed up designers” to “make fast generation safe.”

Two-column diagram “What Collapses vs What Stays.” Left (terracotta): stages collapsing now: static hi-fi mockups for every screen, redlines and pixel-spec handoffs, pixel-polish before real users touch it, hand-drawn variants and edge states, “design, then code” handoff queues, and UX / UI / UX-writing role walls. Right (teal): what stays valuable: problem framing, IA/data model, real-user validation, accessibility/regulatory fitness, design-system tokens and a11y rules, systemic trade-offs.

What leads should drop and what to keep

If you manage design or product in 2026, treat the accordion as an economic instrument.

Safe to drop or heavily compress

  1. Static high-fidelity mockups for every screen when a working build can carry the same intent.
  2. Redlines and pixel-spec handoffs; the coded component is the spec.
  3. Pixel-perfect polish before real users have touched the flow; polish is cheap to add once you know it’s the right flow.
  4. Hand-drawn variants and edge states; let agents generate them from the system, then review.
  5. “Design, then code” handoff queues when a near-final build can be the learning artifact.
  6. Role walls between UX, UI, and UX writing when one owner plus agents can span the surface.
  7. Documentation that only exists to survive a handoff you no longer need.

Keep, and staff more carefully

  1. Problem framing and job-to-be-done clarity before you generate volume.
  2. Information architecture and domain/data-model decisions (the expensive wrongness).
  3. Real-user validation in context, especially when access is limited and you must design the research instead of skipping it.
  4. Accessibility and regulatory fitness as first-class acceptance criteria, not a late audit.
  5. Design-system tokens, component contracts, and a11y rules as the rails for AI output.
  6. Systemic trade-offs: security, auditability, multi-tenant boundaries, operational failure modes.

Change got cheap, so the accordion is closing. The senior part of the job is knowing which folds to push shut, and which ones will crush the product if you close them.