The pros and cons of Big Design Up Front — and what I do instead

Can a waterfall sprint? Can a greyhound slow down?

Photo by Alvaro Reyes on Unsplash


Zooming in or out



Cost, cheap, expensive

Engineering, development, coding

What is BDUF?

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

  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

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

JEDUF to the rescue

  • 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

There’s still plenty of room for BDUF

Subscribe to get my best articles in your inbox.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Benek Lisefski

I’m a UX/UI designer from Auckland, New Zealand. Writing about freelancing & business for indie designers & creatives at