Search "agile design" and you'll get two completely different answers depending on who's talking. UX folks mean iterative product design that aligns with Scrum sprints. Software engineers mean emergent code architecture — SOLID, refactoring, TDD-driven structure. Both are right. Both come from the same agile manifesto values. And confusing them is one of the fastest ways to derail a project kickoff.
Here's the thing. Most teams need both. You can't ship a usable product without thoughtful interface design, and you can't ship maintainable software without disciplined code architecture. The trick is knowing which conversation you're in. When a product manager says "let's do agile design," she probably means Figma prototypes synced to sprint reviews. When the lead engineer says it, he's talking about agile development patterns — refactor as you go, don't over-architect.
This guide covers both. First we'll unpack the UX side — design sprints, Lean UX, dual-track agile, designOps, continuous discovery. Then the software side — emergent design, SOLID, just-enough architecture, TDD's influence on structure. Each meaning gets equal time because in modern product teams, the disciplines overlap constantly. A senior designer who can't talk about the data model is at a disadvantage. A senior engineer who can't sketch a user flow is too.
One quick reframe before we dig in. Agile design isn't a separate methodology. It's a way of applying the agile principles to design work — whether that work is wireframing a checkout flow or sketching a microservice boundary. Same values: working output over polished documentation, customer collaboration over contract negotiation, responding to change over following the original plan. The Manifesto authors weren't thinking about Figma when they wrote those four values in 2001, but the values map cleanly to design work today.
Fair warning: this is not a primer on agile itself. If you're new to the manifesto, sprints, or backlogs, start with our broader explainer first. Below we assume you already know what a sprint is. We're focused on what designers and architects actually do inside that sprint cadence — and where the two practices genuinely overlap.
One more piece of context before we move on. The phrase "agile design" started appearing in tech press around 2010, mostly from UX writers describing how they were adapting to Scrum teams. By 2013 the term had two distinct meanings circulating. By 2020 most teams had quietly accepted the ambiguity and learned to clarify it in conversation. If you've heard the term and felt confused, that confusion is real — and reasonable.
Meaning 1 — Agile UX/UI Design: iterative product design (wireframes, prototypes, usability tests) synced to development sprints. Born from Lean UX and Design Sprints around 2010–2013.
Meaning 2 — Agile Software Design: emergent code architecture using SOLID principles, refactoring, TDD, and just-enough-design-up-front. From the XP and Clean Code traditions, predates the manifesto.
Both are legitimate. When in doubt, ask the speaker which one they mean.
In a typical Scrum team, the designer doesn't disappear into a six-month design phase. She's in the room every day. Stand-ups include design status. Sprint planning includes design tasks. Sprint review demos show prototypes alongside working code. Retros surface what worked — and what felt rushed. The designer is a peer to engineers, not a vendor.
The work usually splits across two tracks. Track one is discovery: research, interviews, sketching, exploring what to build next. Track two is delivery: refining the designs the team is building right now. This is the heart of dual-track agile, popularized by Marty Cagan and Teresa Torres. Discovery feeds tomorrow's backlog; delivery ships this sprint's work. They run in parallel — same team, same cadence, two different jobs.
What does the designer actually produce? Less polished mockups than you might expect. The point isn't pixel-perfect screens — it's just enough fidelity to validate the idea. Lo-fi sketches for early exploration. Mid-fi wireframes once the flow is clear. Hi-fi mockups only when the design is locked. The goal: get to working software fast, learn from real users, then iterate.
This is hard for designers trained in agency or waterfall settings. The instinct is to polish before showing. Agile design fights that instinct. Show the sketch. Show the messy prototype. Get feedback while it's still cheap to change. A designer who sits on her work for two weeks polishing in private has wasted two weeks of potential learning.
Google Ventures formalized this in Sprint (the Knapp book, 2016). Five days. Cross-functional team. Day 1 map the problem. Day 2 sketch solutions. Day 3 decide on one direction. Day 4 build a prototype. Day 5 test with five users. The output is evidence — not a finished feature, but a clear go/no-go for whether the idea has legs.
Teams that do design sprints well don't run them constantly. Once a quarter is common. The sprint is for high-stakes decisions where the cost of building the wrong thing is high. For ordinary feature work, a lighter-weight discovery process is usually enough. Scaled agile programs sometimes embed design sprints into PI planning.
Lean UX (Jeff Gothelf, 2013) flipped the deliverable. Instead of producing documents and mockups, the deliverable is learning. Hypothesis. Experiment. Result. Next hypothesis. The Lean UX canvas replaces the long PRD. The team writes assumptions on sticky notes, picks the riskiest one, and runs a tiny experiment to test it.
Teresa Torres took this further with continuous discovery habits — interview at least one customer per week, every week, forever. The opportunity-solution tree visualizes how interview insights connect to opportunities, ideas, and experiments. It's not glamorous. It's just sustained, structured curiosity. Teams that adopt the habit consistently report that their roadmap stops being a guess and starts being a response to actual user behavior.
As design teams scaled, a new role emerged: DesignOps. Think of it as DevOps for design. Standardize the file naming. Maintain the design system. Run the research repository. Track which Figma libraries are canonical and which are stale. Without DesignOps, large design teams drown in duplicate buttons and conflicting color tokens. With it, the design system stays clean and designers spend their time on product problems.
DesignOps is invisible when it works and catastrophic when it doesn't. A team without DesignOps will have five versions of the primary button scattered across three Figma files. A team with DesignOps has one button, in one library, used everywhere. The difference compounds. By year three, a team with proper DesignOps moves twice as fast as one without.
5-day intensive framework. Map → sketch → decide → prototype → test. Best for high-stakes early-stage product decisions.
Hypothesis-driven design. Each design choice is an experiment. Output is validated learning, not pixel-perfect mockups.
Discovery and delivery tracks run in parallel within the same team. Discovery feeds backlog; delivery ships current sprint.
Now the other meaning. When senior engineers say "agile design," they're rarely talking about Figma. They're talking about how code structure evolves inside an iterative team — how architecture emerges from continuous small decisions instead of being mandated up front. This tradition is older than the Agile Manifesto. It comes from Extreme Programming, Smalltalk culture, and the early refactoring movement of the late 1990s.
The core claim is provocative: a good architecture cannot be designed in advance. It can only be discovered. You start with the simplest code that solves today's problem. You write tests first. You refactor mercilessly when the code starts to smell. The architecture that emerges from that discipline is almost always better than the one a senior engineer would have drawn on a whiteboard in week one.
This doesn't mean zero planning. The two or three decisions that are expensive to reverse — database choice, sync versus async, monolith versus services — still need thought before code is written. Everything else? Let the code teach you. Sandi Metz captured this in Practical Object-Oriented Design: "the future is uncertain, so design for change." That's the agile software design ethos in nine words.
Refactoring is the engine. Without continuous refactoring, code rots. With it, the code stays clean enough to absorb new requirements without rewriting. Most teams that fail at agile fail here — they ship features but never refactor, and the codebase becomes a graveyard of patches stacked on patches. Eighteen months in, every change takes three times as long as it should. The remedy is cultural, not technical: make refactoring a normal part of every story, not a quarterly cleanup project.
One philosophical note. Agile software design is not anti-architecture. It's anti-prescription. The senior engineer who insists on a complete UML diagram before any code is written is solving the wrong problem. The senior engineer who refuses to think about boundaries at all is solving a different wrong problem. The middle path requires judgment. That judgment comes from experience, not from a process document. Which is why agile teams that are heavy on juniors and light on senior engineers often struggle — there's no one to recognize the design pressure as it builds.
The idea that good architecture emerges from continuous refactoring rather than upfront design. You start with the simplest thing that works. You refactor as the design pressure builds. The system's shape reveals itself over time.
Emergent design doesn't mean no design. It means resisting the urge to predict every future requirement. The cost of over-architecting up front almost always exceeds the cost of refactoring later — because you don't know what you don't know.
Five object-oriented design principles from Robert Martin. Single Responsibility: one reason to change per class. Open/Closed: open for extension, closed for modification. Liskov Substitution: subtypes must be substitutable. Interface Segregation: prefer small focused interfaces. Dependency Inversion: depend on abstractions, not concretions.
SOLID isn't religious. It's a vocabulary for noticing when code is getting hard to change. Most agile teams apply SOLID selectively — when refactoring tells you something is wrong.
Test-Driven Development shapes design by forcing you to think about how code will be used before you write it. Red — write a failing test. Green — make it pass with the simplest code. Refactor — clean up while tests stay green.
TDD pushes you toward smaller units, looser coupling, and clearer interfaces — because untestable code is painful to write tests for. The design tax shows up immediately, not three months later.
The middle path between Big Design Up Front and no design at all. Sketch the high-level component boundaries. Decide the two or three architectural decisions that are expensive to reverse — database choice, sync vs async, monolith vs services. Defer everything else until you actually need it.
This is sometimes called "the last responsible moment" — delay decisions until you have enough information to make them well, but no later. The agile mindset is comfortable with that ambiguity; waterfall thinking isn't.
None of this works without cross-functional teams. A designer who reports up through a separate design org, with separate goals and a separate roadmap, can't really embed in a sprint team — the incentives pull her away. Same for engineers reporting into a platform team that's separate from product. The org chart has to match the work. If it doesn't, no amount of process change will fix the friction.
The unit of work is the user story. Format: As a [user], I want [outcome], so that [reason]. Stories are intentionally small — small enough to design, build, and test inside a single sprint. Bigger work is broken into multiple stories or into an epic that spans several sprints. The team negotiates the breakdown together. Designer, engineer, PM, QA — everyone owns the story.
Stories drive design. When the team picks up a story, the designer drafts the screens, the engineer sketches the API, and they validate the approach together before either commits to a detailed deliverable. This is the opposite of waterfall: instead of a finished design being handed to engineering, the design and code evolve in parallel. Sometimes a technical constraint changes the design; sometimes a design insight changes the architecture.
Acceptance criteria belong to the story, not to the designer or engineer alone. "Definition of done" includes design polish, accessibility, performance, and tests — not just "the code compiles." Teams that ship well bake all of those into the story itself. WCAG compliance, performance budgets, browser support — these aren't a separate review stage. They're part of finishing the story.
Story sizing is where most teams get tripped up. Engineers want to estimate in hours; product owners want to estimate in story points; designers want neither. The trick that works for most agile teams is relative sizing — declare one story as a "1" and size everything else against it. Don't anchor to hours. Hours are a trap because they invite individual commitments rather than team estimates. A team estimate covers all the uncertainty: design work, test work, the inevitable surprise.
One last note on cross-functional work. The designer is responsible for the user experience, but the user experience is not just the visual layer. It includes error states, loading states, empty states, accessibility, and the words on the page. Microcopy is design. Empty states are design. The 404 page is design. Teams that treat design as "the screens" miss most of the actual design work — and ship products that feel half-finished even when they technically work.
One story doesn't block another. Each can be picked up alone.
The team adjusts scope together — story is a conversation starter.
A real user benefits. If no one cares, don't build it.
The team can size it relative to other stories. Hours not required.
1–3 days of work. Bigger stories get split, not estimated harder.
Acceptance criteria are clear. The team knows when done is done.
Figma has eaten the design tool market. Multiplayer editing, browser-native, version history, components, auto-layout, dev-mode handoff. Sketch is still common at older shops; Adobe XD is largely on life support. For most new teams in 2026, Figma is the default. Knowing it isn't optional for a working UX designer.
But the tool isn't the point. The point is rapid feedback. A clickable Figma prototype that five users tap through tells you more in 30 minutes than a perfect mockup tells you in three weeks. Prototypes should be cheap, slightly disposable, and shared widely. Don't fall in love with your prototype. Throw it away the moment you've learned what you need.
A trap to avoid: the polished prototype that becomes the spec. Once a stakeholder sees a beautiful Figma flow, they expect to ship exactly that. The solution is to keep prototypes obviously rough during discovery and reserve hi-fi work for the moment the team has truly committed.
Every product of any size needs a design system — a single source of truth for buttons, forms, colors, type, spacing, and patterns. The system lives in Figma libraries and a parallel code library (Storybook, usually). Agile teams maintain it the way they maintain any code: small commits, code review, deprecation notices, semver.
The hard part isn't building the system. It's keeping it alive. Teams that succeed treat the design system as a product, not a project. There's an owner. There's a backlog. There's a roadmap. Stale design systems die fast — and once they die, designers start building one-off components, the visual language fragments, and you're back where you started.
The software-side meaning of agile design connects back to all of this through one practice: continuous integration. The CI pipeline is to engineering what the design system is to UX. Both are infrastructure that makes small changes safe. Both punish neglect. Both, when healthy, let the team focus on actual product work instead of plumbing. A team with a strong design system and a strong CI pipeline can ship daily. A team without either ships quarterly, and the quarterly release is always painful. The two halves of agile design — UX iteration and emergent architecture — converge here.
Where Agile Design Disagrees with Design Thinking is worth a separate paragraph. Design Thinking — the Stanford d.school framework — is sometimes confused with agile design. They share vocabulary (empathy, prototyping, iteration) but differ on tempo. Design Thinking is a problem-framing methodology. It's exploratory. It can take weeks for a single empathy phase. Agile design absorbs the spirit but compresses the tempo. The empathy work happens continuously in discovery; the prototyping happens inside the sprint. Both frameworks coexist comfortably on most modern teams.