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 will use, "BDUF", as a mental shortcut rather than understand the underlying organizational dysfunction. They don't take the time to understand the problem, resorting, instead, to cries of "BDUF!!!"
Unfortunately, this shortcut masks two problems:
- They confuse design and build activities with Designer and Developer roles. Activities are process. Roles are people.
- Their role biases towards build activities instead of design activities. (This suggests build activities exclude design activities, and vice versa. Of course, this isn't true.)
My goal isn't to defend "BDUF". Nor do I want to defend "agile". (That's doesn't mean defending one precludes defending the other.) Instead, my goal has two parts:
- Clarify the difference between design activities and build activities, so you can leverage each when they create the most value.
- Identify the source of the organizational problem, so you can reduce its effects.
To accomplish these goals, we'll examine five assumptions hidden within "Big Design Up Front":
- design vs. build
- BDUF is waste
- BDUF is documentation
- BDUF does not do "real" validation
- BDUF does not validate with developers
After unpacking each assumption, we'll look at how to fix the underlying problem, so we can get back to building better products, teams, and experiences.
Problem 1: 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, leaving less and less time for engineers to build, test, and launch. And it wasn't uncommon for launch dates to slip, but never enough.
Engineering was always left in a bind, the last group holding the late stick.
This is often characterized as one of the reasons waterfall production fails. However, this has nothing to do with waterfall and everything to do with bad client and project management. Regardless, it was entirely understandable that time on the project schedule was viewed as a zero-sum resource where any additional upstream activities took away from engineering activities.
However, the organizational problem is resource constraints, perceived or actual, and how they are dealt with. It has nothing to do with design. Resource problems are management problems, not design problems.
The solution is to have a better project management.
If a deadline slips, all the deadlines slip. All 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.
This goes double for those in leadership. Just because you're CEO doesn't mean you can swoop in and change scope at the last minute. 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.
Problem 2: design is waste
Some believe you can build without designers or design. First, that confuses design activities with the role, Designer. Second, that suggests design activities are waste.
First, design activities precede build. Always. You must think about what you're going to do before you do it. It's impossible that design activities are inherently waste. That said, design activities are not the sole province of Designers. I've watched countless engineers design.
What's left is the suggestion that design activities performed by a Designer are less useful than those performed by other team members. This shows a lack of respect for one of your fellow team members, and ignores the strengths a design specialist can bring to the table. Of course, you may not need the strengths of a design specialist.
However, you always need design.
If you perceive design as waste, then you need to better understand the design toolset, so you can understand how to use it 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.
Problem 3: design is documentation (and documentation is waste)
Many associate design with deliverables and argue that documentation is waste. This lacks an understanding of what a deliverable is, as well as what it is used for.
The deliverable of any design activity is not a document. The deliverable is always understanding. You document your understanding in one form or another to share that understanding with others (so you can validate it).
A conversation is a 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.
If you believe documentation is waste, then you need to learn why you need to document, and when. You need to understand who you will validate your understanding, and why, and understand what channels you must use to validate that understanding.
Problem 4: BDUF does not do "real" validation
Many accuse BDUF of conducting fake validation. Either the validation isn't done with real customers (they use representative users), or it's not done in a real context (it's tested in a lab), or it's not done with real product (they use a prototype).
This assumes every design decision must be cast in the crucible of the market place, complete with invisible hands.
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 for you, 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.
Problem 5: BDUF does not validate with developers
Perhaps the greatest charge levied against BDUF is that 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.
If a decision does not respect any leg of the tripod, then it is sub-optimal. You choose to implement sub-optimal solutions (or not) based on your team's benefit analysis. (This is how teams allow business, UX, and technical debt into a project.)
Not validating against each leg of the tripod is a symptom of an organization that does not respect all team members who contribute to a project. It violates the rule of respect where you do not add scope to a team member without their express permission.
If your design decisions are not validated with all members of the team, then you need to implement balanced teams that combine business, UX, and technical expertise 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 ends of the same 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 tailors itself towards validation. 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 the things you need to validate before, during, and after you build. Design to share and validate your understanding, so you build what the team understands as the right thing.
Of course, your understanding will change once you launch. Then you get to start the process all over again.
Now, before we part ways, I have a favor to ask. I need your help to get the word out that big design upfront is a lie. If you found this post valuable, please tweet, post to Facebook, LinkedIn, mailing lists, and anywhere else you think the message should spread.
Go forth. Design big.