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

Assumption

Big up front design is “waste”

versus

Truth

Design reduces waste and maximizes the value of code

Some believe you can build without design. That suggests design activities are—in the Lean sense—“waste”. 

Design is not “waste”.

First, design activities precede build. Always. You must think about what you’ll do before you do it. Design isn’t waste. It’s a precondition. That said, Designers are not only people who do design activities. Every engineer designs.

So, if design—as an activity—isn’t waste, then the only way design is waste is if only design activities performed by a Designer are less useful than those performed by other team members. Like with missed deadlines and scope creep we discussed above, the idea that design activities by Designers are uniquely waste shows a fundamental lack of respect for fellow team members, and it 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. And if you’re doing anything used by people, you probably need a design specialist.

If you perceive design as waste, then you don’t understand design activities or how to leverage them for maximum value. Design needs you to understand whether you’re framing problems or solutions, need to understand your user, the interface, the interaction, or the system, and requires you understand what fidelity you need in order to validate product assumptions and who you need to validate them with.

Because you can validate product assumptions early on, design means you will need less rework and will release more valuable code. Design is like adding a retrospective every day instead of every two weeks. It’s the fastest, most efficient way to test your product.

versus

Truth

Documentation let’s you test without code

Many associate design with deliverables and argue that documentation is waste. This viewpoint misunderstands what a deliverable is and what deliverables are used for.

Design doesn’t deliver documents. Design delivers understanding. You document understanding, so you can share that understanding with others, and have then test and validate it. Documentation lets you share and test ideas without code, integration, or deployment.

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

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

If your documentation is a waste, you documented the wrong things for the wrong reasons for the wrong amount of time. Document what you need to share or validate, and always document what you need to test.

versus

Truth

Design tests ideas in the most efficient way

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

• Upfront design doesn’t test with real customers. (They use representative users.)

• BDUF doesn’t test in a real context. (It tests in a lab.)

• BDUF doesn’t test with real product. (BDUF uses prototypes.)

This assumes that if you want to test any idea, you must test it in the crucible of the market place.

Of course, this isn't true. Design activities let you test ideas in the fastest, cheapest way possible because it chooses the right format, the right fidelity, and the right people you need to get the answer you’re looking for.

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 strive to understand what you need to validate, when, and with whom. It’s wasteful to validate the hard way when the easy way will do.

Truth

Your teams are missing key skills and not communicating

The worst charge you can levy against BDUF is it doesn't make sure designs are technical feasible. This isn’t a symptom of waterfall or big design upfront. This is a symptom of bad design.

Whether made in the C-suite, by the UX team, or by developers, all design decisions should be validated with the entire team. Every design decision must respect business goals and constraints, user goals and constraints, and technical goals and constraints. The tripod needs three legs to stand.

If a design decision doesn’t respect each leg of the tripod, then it’s a sub-optimal design. If design decisions aren’t validated with each leg of the tripod, that’s a symptom of an organization that doesn’t respect all of its team members. It violates the rule of respect, that you don’t add scope to someone else without their express permission.

If your design decisions aren’t validated with all members of the team, staff teams that are really cross-functional with business, UX, and technical expertise on one team, so they can collaborate to design, validate, and build solutions together. It really takes a village. 

Many cast waterfall and agile as arch enemies when, really, they live at different ends of a single continuum. It’s not about waterfall versus agile. It’s about validating your understanding, so you can build better products and services. 

Agile and waterfall are approaches for building products.

Design is an approach for validating products.

Every design activity exists to test ideas. Design is how you validate. Design is how you validate your product works for the organization, engineering, and it end-users.

Don’t worry about how much design is done upfront. Identify what you need to validate before, during, and after you build. Design to share ideas and test assumptions, so the team builds what it understands as the right thing. Then you launch and you learn some more, so you start the process again. Design drives continuous improvement.