A mechanical engineer by training, I’ve always chaffed at using the word process to describe something as messy and nonlinear as design. At MIT, I learned about processes for solving problems like how quickly heat moves through a block of metal, or how to calculate the impedance in an electrical circuit. To me, a process is something with a set list of procedures you have to do (draw a diagram of the system, then sketch the force vectors, then calculate the forces on an object in the X and Y directions, etc.)
I remember the story my thermodynamics professor told about the importance of order of operations in a process. He described a professor who’d brought a gun into the classroom (apparently rules were a little looser back then). The professor proceeded to point the gun at his head and pull the trigger. Then he lowered the gun and loaded it. This was a reminder to the class that the order in which you do the steps is important, and every step matters in getting to the final answer.
“The order in which you do the steps is important, and every step matters in getting to the final answer.”
What is this design process you speak of?
The Stanford d.School uses this fairly straightforward diagram to explain the steps a design thinker goes through during a project:
This diagram is often presented with the caveat that you can do the steps in roughly any order, and often need to iterate through many of the phases multiple times. It is a fantastic teaching tool, and helps simplify design down to its essence so beginners can learn. However, saying these honeycombs represent a professional design process is like saying my attempts in a barre exercise class are just a simplified form of what professional ballerinas do.
Tim Brown, CEO of IDEO, comes a bit closer to describing a professional workflow with his diagram of how design can transform organizations:
What’s the problem with a formal process?
When one has learned that good design has a certain number of steps, it can make you feel like you’re a bad designer when you don’t do every step for a given project.
Weren’t able to access end users to interview? #fail
Didn’t have a chance to brainstorm a hundred different Post-Its worth of ideas for that new widget? #fail
Didn’t have time to test out prototypes for that new landing page before shipping it? #fail Too busy with your next project to iterate on the landing page you just shipped without testing? #doublefail
When one is working in a company or startup, things are often much messier than what you’d encounter in a school or consultancy setting. The sense of failure that comes from not being able to do every step of a process can be immensely demoralizing, especially to young designers who are still finding their footing and often have the least ability to change the way an organization works.
I think it’s fair to say that every designer, at some point or another, will play fast and loose with her work. Whether it’s because there’s a tight deadline at work, or we’re building a personal project that scratches an itch we don’t care if anyone else has, we designers all have our times when we skip a step (or two or three). And I think that’s okay. Let’s not let perfect be the enemy of the good.
If design isn’t a process, then what is it?
I prefer to think of a design approach to solving problems, which often feels like plain old common sense. Below are a set of roles I believe a good designer (from entry level to leader) can own in an organization, or at least within the slice of the organization she has control over:
- Defining the problem a product is solving, and continuing to redefine the problem as time passes and the landscape changes.
- Communicating the story of the product and the problem(s) it’s addressing across an organization in order to inspire and direct those who build and support the product.
- Building consensus from diverse stakeholders throughout an organization on what problems the team is solving.
- Connecting product decisions to a larger purpose, like a company’s mission, values and design principles.
- Rejecting the obvious solution when a more nuanced approach could cleanly solve multiple (sometimes seemingly unrelated) problems.
- Advocating for everyone who touches the product (not just the end user).
- Curiosity about how things work with a drive to improve upon the status quo.
- Seeking critique and feedback regardless of where it comes from, but with an opinion about whether it’s relevant.
- Driving a timeline by understanding the features to prioritize, and the teams to collaborate with in order to ship the product.
The list above is not meant to be comprehensive, and I expect to add to it over time. I’d love to hear thoughts and comments from other designers about what they believe they own (or should own) within their organization.
“Designers are people who are curious, and relentless in their pursuit of optimizing what they’re working on.”
While there are similarities to our methods, designers must be able to adapt to navigate the constraints of the organizations or clients they’re working for, and the timeline and resources of the particular issue. Every project requires a slightly different approach to arriving at a shipping product; there is no single process that makes sense in every situation.
With my thoughts on process out of the way, next time I’ll share my opinions on the narrow way design thinking defines the Empathize step.
This article was originally posted on Laura’s Medium page.