My Design Process - Part 1
When I first got into designing products, my first year or two was spent mostly in Photoshop designing high-fidelity mockups a single screen at a time, showing them to my team, iterating and then getting into code. While I had previous experience with critique from my Creative Writing program, my writing process - just sit down and start writing something, anything - left a lot to be desired. And while the results weren't terrible, they certainly weren't as thoughtful and holistic as they could have been.
Luckily, I’ve had a few more jobs and opportunities since then to work with more designers, get some experience, add new tools to my skill set and improve my process. Now, I’m finally in a place where I can repeat the same steps and get fairly solid results. The scope and necessity of each step shifts depending on the size and scope of the project. But, generally, I always follow these phases in some form or fashion during each design problem that’s thrown my way. And while I've certainly got some more evolving to do, my hope is that reading this will be helpful to designers just starting out and looking for a solid framework to base their decisions on.
With that, here we go.
Product Definition
This is the What are we even going to do? portion of the process. If you're not a part of helping determine your team's roadmap, try to get involved. Applying a shorter, more abstract version of design process and brainstorming techniques to product definition is a great way to establish a collaborative relationship with your PM and engineering team. Generating, editing and scoping ideas together gets everyone pretty pumped to execute. You'll also learn some cool techniques from others during that process (I learned about proper Gantt charts from my PM partner during our annual planning process last year).
The goal here is to emerge with team agreement on three things:
- What you're doing.
- Why you're doing it (problems you're trying to solve).
- What success looks like (quantitatively and qualitatively).
I usually wind up quickly creating a document that has short bullets for each of those three things. I then pass it around to everyone on the team to gather consensus, illuminate disagreement and to identify things I may have missed. Once you have a document you all feel great about, refer to it frequently throughout the rest of the process. Remind yourselves and others of the problems and goals as you review work. This will help you keep yourself and your team focused and prevent design creep: if it doesn't solve the problem or meet the goals, it doesn't go into this version.
Competitive Analysis
Looking at how others have tackled similar problems is essential, and should be done in parallel with the Product Definition part of the process. Find as many products with similar features/flows as you can, screenshot each step, print it all out, put it on a board and evaluate each experience. What are the pros and cons of each approach? Write them down next to each flow. How can you improve on the pros and avoid the cons? Having this analysis will make sure you're not reinventing the wheel, and will even help you identify common pitfalls or particularly complex areas to be aware of as you start designing.
Also, no competitive analysis would be complete without evaluating yourself. If you're designing an existing product, it's time to look inward. Print it out, put it next to the other flows and honestly write out what's working and what's not working. If you didn't design it, bring in the person that did if you can so they can explain the constraints, what they wish was different, etc. Historical knowledge is extremely valuable. Take advantage of it whenever you can, but be careful not to let it limit your thinking. History is a datapoint, that is all.
Map the Flow
Assuming your work only affects a single page is like designing a house and assuming you won't need doors, windows or hallways. It doesn't matter if you're adding a button to a page or completely overhauling user on-boarding. There's always a flow. What are the ingress points to your design? What are the exits and edge cases? Are there decisions a user needs to make before moving forward? Do people land on the page from outside your product? Is that different than discovering the page or feature while using the product? Map it all out.
There are already a ton of tools made specifically to map flows. But you can go as low-fi as a quick sketch, or even just make some grey boxes with text and arrows with your favorite design software. This doesn't have to be fancy, it just has to exist. It will relieve you of trying to keep an entire product in your head, and also help you and your team think about how what you're doing fits into the larger picture.