I’ve been reading “The Design of Design" with the goal of understanding which parts of my somewhat-informal design process have worked well for me, what I can do to further solidify good practices, and what I can do to smooth out any bumps.
A quick mental review of the way I do things now revealed that, on the surface at least, my process varies pretty wildly depending on the scope and nature of the problem I am trying to solve. That left me wondering, “Is my process really that dissimilar each time? What are the constants?”
Brooks presents several concrete explanations of the components that he believes make up a good design process. I’ve used a few key concepts from those explanations to help me better define my own process.
The purpose of design isn’t just to satisfy requirements, but also to discover them.
When I begin work on a new design, I usually start by thinking through the “obvious” solution. This is the solution that your competitor uses, or the one everyone shouted out at the feature budget discussion, or the one that you’d already made up in your head when you first heard about the feature. Then, I start to poke holes in it.
Because most of the features I am asked to design are user-facing, sketching is the best way I’ve found to do this. It gives you an immediate visceral sense for whether or not your current solution even makes sense. Beyond that, it gives you a chance to think about when/why/how a user might try to use the feature by considering exactly what a user would see.
This is all sort of obvious for people used to designing software, but the thing that Brooks points out that I found so helpful is that what I’m really doing here is working to satisfy and discover requirements simultaneously. Finding more problems during design is both useful and necessary for creating a good design. Moreover, getting it wrong the first time doesn’t make you a bad designer; a bad designer isn’t ready to get it wrong and iterate towards a better solution.
Design isn’t just picking between alternatives. It is realizing their existence.
It’s easy to fall into the trap of thinking of the my job as simply delivering solutions. And while the results of my work are certainly the measure by which my performance will be judged, this idea, that design isn’t just picking between alternatives, is furthering the argument that the purpose of design is discovery. Therefore, when I am evaluating a design solution, I should look not only at it’s “correctness” in terms of how well it satisfies the requirements but also at the alternatives that it suggests.
Execution still matters
A lot has been written about execution here and elsewhere. In fact, the tap tap tap article that I linked to yesterday is a good example. Without a doubt, good execution is critical. But the key piece of learning that Brooks’ essays have provided me is that understanding and exploration are the prerequisites for good execution. Put another way, defining the solution is a critical part of any design process, but ensuring your ability to explore requirements and alternatives is equally important because it helps define a higher fidelity solution.
I sorta knew this already, but…
After reading Brooks’ explanations I was able to more clearly see the parallels between my design activities. And it’s mostly good news because he suggest that a good design process is close to the one that feels natural to me. According to Brooks, a good process is iterative and consists of:
- Requirements definition/discovery
- Alternative exploration/discovery
The order isn’t explicit, and iteration can happen within a step or across several steps. It is this natural variation which gave me the sense that my process was highly variable even though, in reality, I do all, or at least most, of these each time I sit down to work on a design. My problem was only that I am a designer by trade and not by education, so I hadn’t yet learned an explicit model to build from.
Having an explicit mental model for my process is already proving helpful to me. The biggest immediate benefit is the ability to more explicitly make trade-offs. When constraints make it hard for me to do a great job at every phase of the process, I can identify where trade-offs can be made, decide where I would prefer to make them, and explain those decisions to my teammates. Beyond that, I can work to improve my ability in each of these areas by examining my day-to-day work through the lens of this model and better identifying successes and failures. I’m pumped.