Menu About

R.I.P. – Big Design Up Front

Can a waterfall sprint? Can a greyhound slow down?

I’ve run my own independent design business for 18 years. Starting back when waterfall was all we had, then transitioning to extreme agile, and all the variations in between.

As a freelancer, I work for a variety of clients — large and small — on a broad range of digital products: from simple brochure websites to complex web and mobile apps. I still use a BDUF waterfall process when it suits the project. Other times the atmosphere demands a highly iterative and agile approach.

I often switch between these polar-opposite design methodologies on a daily basis, as I shift focus from one project to another. It’s helped me adapt to both, and realise the strengths and weaknesses of each process. Practising both methodologies regularly makes me uniquely positioned to understand when one works better than the other. And it’s got me thinking about whether BDUF still has a place in the modern design and development world.

Before we discuss BDUF vs. Agile, let’s start with a few definitions:


A relatively linear sequential design approach where progress flows in largely one direction (“downwards” like a waterfall) through the phases of research, conception, design, construction, testing, deployment and maintenance.

Zooming in or out

In design, zooming out means focusing on the wholeness of a design system, evaluating its effectiveness, and ensuring it works together consistently and harmoniously.

Zooming in is the act of focusing on a smaller piece of the whole — a feature, page, user flow, etc.— hands-on design work that crafts individual design solutions.


A cyclic process of prototyping, testing, analysing, and refining a product or process. Based on the results of stakeholder feedback or testing, changes and refinements are made.


An act of combining into an integral whole.

Cost, cheap, expensive

In this context, it refers to the time and effort spent on design or development, not necessarily a direct relation to monetary cost.

Engineering, development, coding

Used somewhat interchangeably — to draw the line between where design stops and technical implementation begins.

What is BDUF?

Big Design Up Front is an approach where a website, app, or software design is completed and perfected up-front, before its implementation is started. It necessitates a waterfall process, and relies on prediction. This was the prevailing methodology for decades before the advent of Agile. Websites and software used to be very expensive to build, so it was necessary to iron out as many kinks as possible before the costly engineering happened.

Think of it like charting the course of a ship. If you already know the route, the weather, the currents and tides, you can plan the trip before you hit the water. Once you leave port you don’t have to waste time getting your bearings.

Designers who’ve been around longer than a decade — or work outside of the Silicon Valley “product” bubble — probably honed their craft using BDUF. It’s their design comfort zone.

BDUF assumptions

BDUF strengths

BDUF weaknesses

Agile & Emergent Design

The agile development methodology was designed for complex, non-deterministic, non-linear projects. It prioritises being adaptive rather than predictive, reducing the leap of faith that’s needed before evidence is obtained.

Agile aims to break a project down into smaller chunks. Cross-functional teams then use sprints with short-time frames to work through accelerated versions of the entire waterfall process — with the goal to design, produce, and test something in each sprint. Their learnings are then integrated into the project’s evolving scope, and help shape the direction of the next sprints and iterations.

If BDUF is a very well-documented trip planned in advance, Agile is getting your ship out of the port with only a vague idea of where you’re going, and then exploring, planning and adapting in the water. It’s a series of small bets rather than a single well-calculated wager.

The Manifesto for Agile Software Development is based on twelve principles (via Wikipedia):

  1. Customer satisfaction by early and continuous delivery of valuable software.
  2. Welcome changing requirements, even in late development.
  3. Deliver working software frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the primary measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity — the art of maximizing the amount of work not done — is essential
  11. Best architectures, requirements, and designs emerge from self-organizing teams
  12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

Emergent Design

Agile methodologies require a new way of thinking which has been described as emergent design. Emergent design aims to do the opposite as BDUF — minimal or no design up front so we can get to shipping, testing, and validating as quickly as possible.

Emergent design assumptions

Emergent design strengths

Emergent design weaknesses

Just Enough Design Up Front

“Big design up front is dumb, but doing no design up front is even dumber.”

– Dave Thomas

I used to think agile was the enemy of good design, but then I realised it’s just that bad agile doesn’t leave room for good design. I resisted embracing an agile way or working because many of my experiences highlighted the weaknesses of emergent design, and didn’t make up for them with their strengths.

In Is Agile the Enemy (of Good Design)?, John Cutler says “Good” waterfall beats abused Agile any day.

I would have to agree.

Any product development methodology is trying to answer design questions when it’s cheapest to do so. Agile supporters strongly believe it’s cheapest in small increments during short sprints. BDUF works when it’s cheapest up front and considered as a wholeness. But neither of them work for designers when they don’t produce a good design result.

I don’t believe either BDUF or Agile find the right balance. It’s somewhere in between. Therefore my preferred design methodology is Just Enough Design Up Front (JEDUF).

JEDUF to the rescue

JEDUF recognises that some overarching design is required in order to enable more detailed work. We can’t always shoot from the hip with “cowboy development”. First, we need a few goalposts. We need architecture and design to create a foundation for our sprints.

Beyond JEDUF

My own version of JEDUF includes opportunities for design decompression and integration at various stages during the project. I call it Just Enough Design Up Front & Middle.

JEDUF&M balances small sprints — zoomed-in focus — and opportunities for holistic design integration from a wide perspective. When a critical mass of functionality has emerged, the sprint cycle can be paused for deeper design to be considered.

Think of it like another up-front design session, only its goals are about cohesion rather than exploration. Once the design system feels holistic and under control — integrating and harmonising the revisions from previous sprints and learnings — the next round of sprints begins. It’s up to the designer to recognise when the need for a “middle” design break is required, and not let the project get too caught up in the minutiae.

I’ve found JEDUF&M to be the ultimate design methodology. It balances the adaptiveness, quick iterations, and focus on validation which makes agile so powerful — while also allowing for periods of rest, integration, and holistic design system thinking that can get lost among sprints and feature delivery.

If, even under this ideal balance of methodologies, you find yourself anxious about the number of uncertainties, think of it this way instead: embrace the uncertainty. Now you’re in a position to shape what those constraints become, rather than having them predetermined and dictated to you. This is more responsibility, but also more flexibility. If you handle that role with aplomb, you’ll deliver a result with no regrets or compromises, even if the process is more challenging along the way.

There’s still plenty of room for BDUF

You can’t afford to dismiss this dinosaur completely. Big Design Up Front is a very valid and efficient model when used on the right projects.

The benefit of up-front design increases as the system complexity decreases.

Not all designers are working on complex, enterprise apps, with variable stakeholder goals and uncertain solutions. Not every project requires massive exploration, testing, and customer validation.

I can’t imagine taking an agile approach to designing and building a simple brochure or portfolio website. My clients would think I’m mad. In these cases, BDUF is still alive and kicking.

BDUF and Agile are two ends of a single spectrum. Identify what you need to validate before, during, and after you build, and then tailor your process to facilitate the right design at the right time. Most projects will fall somewhere in the middle of the spectrum, not the radical fringes.

And let’s not forget that the waterfall process doesn’t have to be as rigid and linear as its critics make it out to be. BDUF can still “deliver early and often”, collect stakeholder feedback, iterate rapidly, and evolve over time. It’s just that this evolution happens completely in the realm of design.

We can make mini-waterfalls within our big waterfall. There are plenty of useful ways to achieve small validations and move forward without an entire cross-functional team pushing it straight into code and rushing to ship.

BDUF doesn’t mean there’s no ability to learn, adapt, and improve design through feedback and iteration. If that’s what you think BDUF is, maybe you’ve been doing it wrong all these years?

Want to comment?
See this story on Medium
Benek Lisefski

Hi, I'm Benek Lisefski. Since 2001 I've run my own independent design business. Join me as I unfold 20 years of freelance business knowledge: honest advice and practical tips to help you take your indie career from good to great.

MediumTop writer in Design, Business, Creativity, and Entrepreneurship.