Last modified: 18 April 2012
Design is a purposeful process that seeks to solve a problem. We have a healthy focus on our design process in much the same way we have a healthy focus on code reviews
What do we get out of our design process?
The purpose of the process is to answer some key questions before you actually start committing to an implementation by creating detailed interfaces or writing code. Those questions are:
- What problem am I solving? (vision/objective)
- Why is this a problem that should be solved now? (background of how we arrived here)
- At a high level, how do we plan to solve it? (roadmap and how it integrates with the rest of the product)
- Where do we start? (details for v1, and things cut for vFuture)
The goal of answering these questions is not to produce some long-lived piece of documentation but to create a focal point around which you and your team can rally to understand and communicate the nature and scope of the problem and proposed solution.
The actual form that the answers to these questions takes is much less important than the fact that you and whomever is working with you can easily answer them clearly and succinctly. Ultimately, the goal is to use these questions as a framework to define, visualize and validate your idea before you actually build it.
Why is it worth doing this before I start implementing?
Quite simply because our work is creative and that creation is an act of love. It's hard to kill something you love. Solidifying your answers to these questions before makes it more likely that you will:
- Surface major problems faster, and with less unwanted momentum, than diving immediately into implementation
- Be more willing to throw out bad ideas because we've invested much less in them
- Avoid creating a great thing that solves the wrong problem
- Have other folks in the company able to tune-in to what you're doing to give you great constructive feedback.
How does the process work?
It depends largely on the size of the team and project, but the three major pieces of the process are:
- This is questions 1-3. The litmus test here is whether or not you can quickly and easily describe what you're doing to someone not on your team.
- Pick your weapon of choice and lay out your ideas in the fastest, lowest-fidelity manner you choose. Balsamiq Mockups, pencil and paper, and whiteboards are all great. If you need a license for some piece of software, we'll get it for you.
- Find somebody else (users are somebody else's too) and present your idea to them. This can be as simple as throwing a screenshot of your design in your team's Slack channel and asking for feedback. For larger bodies of work, we may schedule a presentation for the whole product team. It'll depend on how sizable and controversial your work is.
- Get feedback from this "somebody else." Maybe argue a bit. Go back to the drawing board and iterate on your design.
- Repeat steps one and two with more and more people until you feel good about what's about to be built.
Arguing about rounded corners, underlines, and style nitpicks is not
the purpose of this design process. Design iteration is an essential part of product hygiene and our ability to move fast, try many different ideas, and throw out mistakes before getting attached to our code.
An Aside on Process
The term process is sort of loaded, but the important thing here is that you should examine the work you do and be able to identify what sorts of motivations you have for doing the work you are doing. While my process differs from the process listed above, it always includes the validation step. I don't know that one process is better than another, but it's certainly useful to understand what your process is good at doing and what it overlooks. For example, here's my process:
- I'm making some change, I'm doing some thing, Some Thing is being changed. Why?
- Conversely, what do i want this thing to inspire or motivate among the people who consume it?
- Basically: understanding what the internal/external motivations are. This is less accurate than the 'definition' process above, but it is good at providing benchmarks for recognizing if the design is succeeding or failing from an aesthetic perspective.
- Research and Exploration
- What have others done (not just visually, but conceptually). You can generally pick some field, any field, and find an example of whatever you're doing playing out there. Sometimes you can't, but it's still useful to see what other inroads others have made. There's nothing new under the sun and all that.
- What sorts of things inspire the feel you are going for (gather examples of them, save them in a folder, or ffffind them)
- What are counterexamples? Things you do not want to emulate. Understand them!
- Research the idea not the thing. Others have approached similar problems before but in different domains, it's useful to understand the intangible successes within other domains to inform why you are drawn to it.
- Basically: understand the idea and its kernel. This understanding is important when you cut features. It's easy to get attached to things which make an idea good but are not essential to its good execution.
- Show other people what you've been thinking and what sorts of atoms you've been using as the elements of your future work.
- Notice, you still haven't done any sketching yet, you've only been understanding the problem domain and trying to distill the parts that you like.
- Sketch, Critique, Implement, Critique, Iterate
- This is what i would normally call 'implementation' but i want to embed all those stages into it because they're part of that. The first part is understanding the visceral guiding principles you're crazy about, the second part is making those dreams come true through iteration and refinement.
What makes for a successful design iteration?
For design owners:
- Strive for clarity. Being able to easily articulate an idea is important. Not being able to state your design goals/direction simply is a sign that you haven't understood the problem/solution well enough. Don't knock it.
- Stay low-fidelity to get core feedback fast. The whole point is to have a healthy debate. If you've spent a ton of time documenting your idea in excruciating detail or designing the perfect UI with perfect colors and perfect margins, it's going to be really hard to throw out 50% of your work if the root idea was simply off the mark.
- Recognize when you get attached, and take a step back. It's only natural to get attached to your designs and defend them. This will happen, it's impossible to avoid, and it can be healthy. However, be aware of yourself. When this happens, you'll need to focus extra hard on what others are suggesting to make sure their ideas are given proper consideration.
For those giving feedback:
- Respond promptly. If somebody on your product team posts a screenshot and asks for feedback, don't leave them hanging. If you don't have time to give the new feature adequate thought, take the time to explain that.
- Respect the design. You've almost certainly thought about this problem for less time than the original designer. That both makes you very valuable (you're not suffering from the curse of product knowledge) and somewhat naive (you haven't considered all the edge cases). Don't blow a design out of the water just because you don't personally love something.
- Speak up if something feels off. If the design doesn't make sense to you, that's an enormous warning sign. Don't be afraid to simply say, "I find this confusing." That's valuable feedback. It's hard to get, because once you understand the design you'll never go back to your state of naivety. Don't waste it by being quiet.
What does the output of the process look like? (Examples)
This seems like a lot of work. Do I have to do this for every little thing?
Even if you're working alone, it's healthy to answer these questions. If you're working with someone else, or with a team, or on something that affects other teams it becomes much more important that you all share the same understanding of what you're doing.
As a result, the thing that changes is what form the output of the process takes. If you're working alone or with one other person maybe it's napkin with a bullet list and rough sketch. If you're working on a team or on a piece of the product that has far-reaching implications maybe it's a doc that you can share around or a storyboard that you present, photograph and share in Slack.
Use your best judgement here. There are no pre-set requirements. Just realize that if you want good feedback from others, at some point you will need to be able to communicate this to them somehow.
K, I'm feeling good about my design. What next?
Now you start building! But the design process doesn't stop there. It's your job is to continually get more feedback and validation as you go along.