The Process of Design

This image is the Process of Design Squiggle by Damien Newman (Creative Commons Attribution-No Derivative Works 3.0 United States License). He created it to show his clients what the creative process for his design projects looks like: chaotic and unpredictable at the start, and later settling into a consistent, focused concept.

Many programmers’ first impulse is to approach problems the opposite way. We attempt to pick a direction and stick with our original design decisions come hell or high water because change is bad for deadlines and we’re stubborn. We like this approach because it allows us to make progress immediately on the final product, and a stationary target gives us a sense of security.

What happens in the real world? The project starts out well: lots of code hits repos right away and the team feels very productive. Then, cracks in the foundation start to appear. Unanticipated use-cases pop up, performance issues prevent original implementation choices, and it becomes apparent that the original direction didn’t put the product where it needs to be now. The team fights original design choices to salvage what they can, entropy increases, and eventually the product resembles the beginning of the design squiggle.

How do we avoid that situation? By making better decisions (and avoiding unnecessary ones) at the beginning of the project. We can do that by taking an approach more like Damien’s. Embrace the uncertainty of creation and try things out. Don’t be afraid to write a quick and dirty prototype to test an idea. Accept that some of your ideas will fail miserably and try anyways. Allow yourself to leave unimportant details ambiguous until they need to be defined.

Great, but not everyone works at a startup.

Neither do I, this is a copout answer. No matter where you work design is a messy process. You won’t get everything right on the first try. If you refuse to acknowledge that fact you’ll make life more difficult for yourself and your team.

What if my manager thinks I’m slacking off?

There is a perception among ourselves and managers that productivity means checking code into the release branch. This mindset creates a lot of pain for everyone. It pushes us to check in more code today at the expense of quality and future planning. We’re passing the buck to our future selves. Increasing design quality requires maturity and trust from all parties. Managers need to trust the team to act in good faith, and team members need to share the results of their prototyping and testing to inform future design decisions.

Take the time to test the bolts before you build the bridge, you’ll thank yourself later.

Inspired by Professor Daniel Keefe.

Originally published at blog.kevanahlquist.com on July 18, 2014.