What's wrong with Big Design Up Front (BDUF)?

Updated September 30, 2018

Summary: Big design upfront isn't the problem. There's something else going on with your organization that makes your work less awesome. You can't work more awesome until you get to the bottom of what's really going on. Here's how.

"Big Design Up Front", or BDUF, when used as a slur, masks a problem in the organization. Smart people use "BDUF" as a mental shortcut rather than understand the underlying organizational dysfunction. Instead of understanding the problem, they resort to cries of "BDUF!!!"

Unfortunately, this mental shortcut masks two problems:

  1. They confuse design and build activities with Designer and Developer roles. Activities are process. Roles are people.

  2. They’re biased toward build activities over design activities. (This suggests build and design activities are mutually exclusive. Of course, this isn't true.)

Rather than argue about some BDUF straw man, let’s dive into the underlying organizational problems, so we can fix them. First, let’s clarify the difference between design activities and build activities, so you can leverage the right one at the right time to create the most value. Second, let’s identify the source of the organizational problem, so you can reduce its effects.

To accomplish these two goals, we'll look at five assumptions that lurk inside bogey man, Big Design Up Front:

  1. design vs. build

  2. BDUF is waste

  3. BDUF is documentation

  4. BDUF does not do "real" validation

  5. BDUF does not validate with developers

After unpacking each assumption, we'll address the underlying problem, so we can get back to building better stuff.

Assumption: It’s design vs. build

In large organizations, it was common to set fixed deadlines for launch, and it wasn't uncommon for plan and design phases to run long and leave less and less time to build, test, and launch. While it wasn't uncommon for launch dates to slip, Engineering was still left in a bind, the last group holding the late stick.

Though often characterized as one reason waterfall fails, this has nothing to do with waterfall and everything to do with bad client and project management. The organizational problem is resource constraints, perceived or actual, and how they’re dealt with. It has nothing to do with design or BDUF. Resource problems are management problems, not design problems.

The solution is better project management.

If a deadline slips, all deadlines slip. Team members must respect the time of other team members. You can't add work or reduce time for someone else without their explicit permission. This is basic respect.

If someone on your team adds scope, you must have a process to manage the change. The PM adage to pick two (features, time, or money) isn't just a happy thought. It reflects project management's constant struggle to get things out the door as expected.

If design and build fight over scope, you need better project management.  

Assumption: design is waste
TRUTH: design reduces waste and maximizes the value of code

Some believe you can build without designers or design. First, that confuses design as an activity with the role of Designer. Second, that suggests design activities are waste. 

First, design activities precede build. Always. You must think about what you will do before you do it. It's impossible that design activities are waste. They are a precondition. That said, design activities are not the sole province of Designers. I've seen countless engineers design.

So, if design as an activity is not waste, what's left is the idea that design activities performed by a Designer are less useful than those performed by other team members. This shows a fundamental lack of respect for a fellow team members and ignores the strengths a design specialist brings to the team.

You may not need the strengths of a design specialist, but you always need design.

If you perceive design as waste, then you don’t understand design activities or how to leverage them for maximum value. This requires understanding whether you are framing problems or solutions, whether you need to understand your user, the interface, the interaction, or a system, and it requires you understand what fidelity you need to validate the end product and who you need to validate with.

If you don’t have time to understand those things, then you probably need a design specialist, née Designer, to help you out.

Assumption: design is documentation (and documentation is waste) 
Truth: DOCUMENTATION LET’s you test without code

Many associate design with deliverables and argue that documentation is waste. This reveals a misunderstanding around what a deliverable is, as well as what deliverables are used for.

The deliverable of any design activity is not the document. The deliverable is understanding. You document understanding, so you can share that understanding with others to can validate it. Documentation lets you share and test ideas without code.

A conversation is one type of documentation, one that is synchronous. If you write a conversation down, it becomes asynchronous. If you need to share your understanding with someone who isn't present with you at the same time, then your understanding must be documented. This isn't waste. It's communication.

Some documentation, like a whiteboard drawing, may only need to last as long as the conversation it supports. Some documentation needs to last for days, weeks, or months. For as long as you will need to share an idea with someone, you need that idea to be documented.

If you believe documentation is waste, you probably document the wrong things for the wrong reasons for the wrong amount of time. Document what you will need to share or validate later. And always document what you need to test.

Assumption: BDUF does not do "real" validation
Truth: Design tests ideas in the most efficient way

Though documentation lets you test ideas without code, some will say BDUF conducts fake validation. Thee validation can be fake for three reasons:

  • The validation isn't done with real customers (they use representative users)

  • It's not done in a real context (it's tested in a lab)

  • It's not done with real product (they use a prototype)

This assumes every idea you want to test must be tested in the crucible of the market place.

Of course, this isn't true. Many engineers validate design decisions as proofs of concept in the safety of gray cubicle farms. Performance, unit tests, and browser tests validate design decisions without real users in real environments with real product. Why would other design validation be any different?

If you slight design validation because it is not "real" enough, then you should strive to understand what you need to validate, when, and with whom. It is wasteful to validate the hard way when the easy way would do.

Assumption: BDUF does not validate ideas with developers
Truth: You’re teams aren’t balanced

Perhaps the worst charge levied against BDUF is it doesn't validate design solutions for technical feasibility. This is not a symptom of waterfall, nor of big design upfront. This is a symptom of bad design.

All design decisions, regardless of whether they're made in the C-suite, by the UX team, or by developers, must be validated with the entire team. You must ensure every design decision respects business goals and constraints, user goals and constraints, and technical goals and constraints, the three legs of the tripod.

If a decision doesn’t respect each leg of the tripod, then it’s sub-optimal. Not validating against each leg of the tripod is symptomatic of an organization that doesn’t respect all team members. It violates the rule of respect: you don’t add scope to someone else without their express permission.

If your design decisions are not validated with all members of the team, you need to implement balanced teams that combine business, UX, and technical expertise on one team to design, validate, and build solutions. It really does takes a village. 

Waterfall vs. Agile

Many circles cast waterfall and agile as arch enemies. In truth, waterfall and agile live on different ends of one continuum. It's not about waterfall versus agile. It's about validating your understanding, so you can deliver better products and services. 

Agile and waterfall are approaches to building products. Design is an activity for validating products.

Every design activity exists, so you can test an idea. Design is how you validate. If you do not need to ensure your product works for your organization, engineering, or customers, then you do not need design. But, I've never seen a situation where you didn't need design. 

Stop worrying about how much design is or isn't done upfront. Identify what you need to validate before, during, and after you build. Design to share ideas and validate your understanding, so you build what the team understands as the right thing.

Of course, understanding changes every time you launch. So you get to start the process all over again.

Go forth. Design big.

Was this useful?

Enter your email address, and I'll send you a quick note when the next post is up.

For more information about hacking UX to fit your team, checkout my  Hacking UX Zombies  presentation on Slideshare.

For more information about hacking UX to fit your team, checkout my Hacking UX Zombies presentation on Slideshare.