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:
Waterfall
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.
Iteration
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.
Integration
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
- We can fully know the goals, requirements, and scope of design up front — and these are unlikely to experience significant changes.
- Design revisions are generally harder and more expensive to make after code has been written. Efficiency is gained by sorting out as much as possible in design.
- We can and must judge if a design solution is good or effective before it’s fully functional.
- Engineers can pinpoint development challenges while still in design, so we can find alternative design solutions before hitting code.
- If left to their own devices, engineers will make a mess of things. Design needs to lead the way or UX and aesthetics will suffer.
BDUF strengths
- If you know exactly what you want, this is the most efficient way to get there.
- Since all design is done at once, there’s ample opportunity for zooming out, integrating often, and designing holistically.
- User experience is designed and refined by designers, and that design documentation dictates the functionality for engineers to develop. Each role plays to their strengths.
- Easy to cost and schedule design, as it’s a known quantity from the start.
BDUF weaknesses
- Not easily adaptable to changes in scope, or pivots in purpose. You may have to swim back up the waterfall to start again if goals or requirements move.
- Design is not as easily tested and validated, because no part of it is fully functional until near the end of the linear process.
- Doesn’t take advantage of new learnings or better solutions that may arise during later stages of the waterfall process.
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):
- Customer satisfaction by early and continuous delivery of valuable software.
- Welcome changing requirements, even in late development.
- Deliver working software frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the primary measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity — the art of maximizing the amount of work not done — is essential
- Best architectures, requirements, and designs emerge from self-organizing teams
- 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
- We can’t fully understand the problem or its ideal solution without a lot of testing and learning. The requirements and design must be deduced, so it’s better to start building the testing ASAP.
- Change is cheaper in code than it is during design. (Or at least equally expensive).
- Design cannot be judged or validated until it’s built and usable in the real world.
- Designers may create technically impossible or expensive solutions if their work isn’t frequently integrated and tested.
- Too much design up front (and any documentation) is wasted effort, as requirements will change or new solutions will emerge before that design is even implemented.
Emergent design strengths
- Design evolves over time and can take advantage of new learnings.
- Design is a collaborative effort and not a solo, reclusive process. As Manuel Dahm said: “This requires the designer to move from the lonely ivory tower of creative genius into the shared apartment of the team mind.”
- Design and development happen in parallel, which facilitates tremendous cross-team collaboration and rapid problem-solving. Fires can be put out at the first sign of smoke.
- Little is left to assumption or intuition. Design is only implemented if it’s proven by data to succeed. Uncertainty about design effectiveness is removed.
Emergent design weaknesses
- Agile can be too output-focused, and encourages the feature factory.
- Ironically, the context of sprints allows for more frequent integration on the macro level, but provides fewer opportunities for deep, holistic design thinking. Too much narrow focus and not enough wide vision means less chance for integration on the level of design systems. This can lead to a mediocre, inconsistent design which lacks polish and wholeness.
- Design is difficult to cost because it’s a moving target dictated by stakeholder feedback and sprint cycles. Full scope of design may not emerge until halfway (or further) through a project.
- The sprint and repeat cycle often concludes when “good enough” design emerges. Then it ships without much opportunity to elevate design past mediocrity. Designers lose their priorities of quality control when decision are dictated by data alone.
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.
- Early design work can be rough, but should always be as good as it can be, given the available information at the time. Yes, much more design work will have to emerge later, but we don’t want to redo any design if we can get it right the first time.
- Up-front design should be considered the most fundamental aspects of a project or product, so it informs the priorities to build and test during early sprints. In other terms, identify the highest risks, and then design for them first. This lays the foundation for a design system, stress-tested early and often by developed pieces of highest value. Some call this necessary up-front design the “primitive whole”.
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
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.
