A Bias For Making

Step into the Wayback Machine, Sherman, and set the dial to 1994. You’ll find me in a conference room, explaining to a room of developers and product owners (back then, we called product owners either product managers or business analysts) how we would design their new product in less than a week. The expression on their faces would be one of OMG! This dude is insane. (Though, “OMG” or “dude” wouldn’t be common parlance for at least another half decade).

We look at paper prototyping now and we think how quaint. Yet, back in 1994, it was a radical departure from established practice. In those olden days, design wasn’t done the way it is today.

Instead, each project would have a requirements phase where the product owner would define every little item the design needed to accomplish. Developers didn’t have much of a say in this process. Their only weapon was the old triangular logic of “Features, Price, Time. Pick 2.” Pile a lot of features into the requirements and you got to spend more money, especially if you wanted to hit a particular deadline.

1994: Paper Prototyping’s Incredible Super Power

Paper prototyping was radical in that it predicted the future. With a paper prototype, you could demonstrate what it would be like to use the design you were thinking of building.

Our typical paper prototyping project would last a week. On Monday and Tuesday, we’d create the prototype of moving parts. Every little message and dialog would be drawn on a little piece of paper. Want a pull down menu? Another piece of paper. Want a status message to change? Another piece of paper.

On Wednesday and Thursday, we’d have users come in to use the mock computer made of paper. Each user would use their finger as the mouse, “clicking” on items and interacting with the design. Mostly, they’d stop and stare, then explain how the design was confusing them. We’d leave a couple hours in between each session for the team to make changes to eliminate the confusion and optimize the design’s flow.

By Friday morning, we’d have a design that was tested by as many as a dozen users, where the major problems had been worked out of the design and replaced with simpler, more straightforward flows. We’d spend the rest of the day documenting the design (thank goodness for photocopiers) and reporting our amazing learnings to senior management who funded the project.

We accomplished in five days what it had taken teams a minimum of six weeks to do previously, and with better results. We had iterated a dozen or more times on the design. We learned a ton about what worked and what didn’t.

More importantly, we’d made something. We’d built a full working version of the design. Having that design in front of users showed us what the experience was like and a peek into what it could be. No amount of planning up front could deliver that.

Making something changed everything. For the first time, design was taken seriously.

2004: A New World of Agile

Fast forward ten years. Developers, frustrated with over-specified projects were ready to adopt the new Agile methodology.

Agile promised better software. Developers thought they could do better by iterating quickly instead of trying to plan the entire design up front. And, in many cases it worked.

“Working software over documentation,” the Agile Manifesto declared. By experimenting with fast iterations, developers could see how the software was turning out.

Iterations vs. Salmon Jumps

Those fast iterations meant they could learn what the design needed by building it. In many ways, Agile was similar to what we did with paper prototypes.

In both approaches, the team is learning through iteration. In paper prototypes, they’re learning the right user experience. In Agile, they’re learning the architecture and right way for the program to function.

This was a complete change from what happened previously. In a waterfall-style development process, any learning requires that you jump back up the waterfall, like a salmon trying to return to its breeding grounds. The force of moving forward was often victorious, preventing any serious change from occurring even though everyone knew it wasn’t going to work.

A Bias for Making

Waterfall was a bias for planning. Whenever a project wasn’t going well, the team would try to specify harder. They’d come up with more review checkpoints, more types of documents, all in the name of getting it right the first time.

Teams employing paper prototyping and Agile development are showing a bias for making. Instead of waiting for the plan, they start building something. They know that what they’re making is likely to be wrong, but that doesn’t stop them.

A bias for making doesn’t mean the team never plans. On the contrary, plans happen fluidly throughout the entire design process. The difference is they are evolving as the team learns from the process of making.

2014: Responsive Design Pushes Harder

Before all these devices and different screen sizes, it was easy to specify what the design should look like. Before the new world of gesture and touch-based interfaces, it was simple to use a small collection of interaction patterns to accomplish everything we needed.

The onslaught of new technology has changed all that. The chances are very low that an upfront design will work the way we intend.

Responsive design makes it blatantly obvious that pushing new designs over the wall doesn’t work. It comes at a time when experiences need excellence.

Once again, designers and developers are turning to fast iterations to learn what they should be building. They are using a bias for making.

By building quick prototypes and playing with them, they can learn what the experience needs to be. They also learn the underlying architecture. The subsequent planning they do is informed by what they’ve made.

A New Age for Developer-Designer Collaboration

We got away with poor developer-designer collaboration when our organizations accepted shipping products with poor experiences. Our users and customers won’t tolerate poor experiences like they used to.

Designers and developers need to work together in a way we’ve never seen before. They must have a common understanding of the designs they intend. They must learn how each other do their jobs. They must learn to speak in a common language.

Developers need to not only see what the design wants to be, they have to understand how it got that way. They need to see how the designer gets to their decisions. By understanding the designer’s intent and underlying principles, they can help get to a better design faster.

Similarly, the designer needs to understand the underlying architecture of the system. They need to know how the data model works. They need to know how that model gets fed into the system. And they need to know the libraries the developer has to work with.

Adopting the Right Bias

With a bias towards making, the best way to learn is to build something and then deconstruct what you’ve made. By seeing what works and what fails, the designer-developer team comes to a common understanding of what can get them closer to a better design.

It’s from this collaboration that the real ability to plan emerges. Armed with all the knowledge fed by the experience of making, the team now is better at planning results.

Teams with a bias for making end up producing better designs than those teams that have a bias for planning. They’re more informed about how they build and what their options are.

Next time you find yourself thinking you need to plan out the design, ask yourself, “Could we plan better from what we’d learn if we just started making something?” The answer might just surprise you.