My Design Process

As a self taught designer, I had to figure out a design process on my own. Thankfully, in the past 10 or so years, big wigs in the tech and design space have been sharing their processes through books, blogs, and articles. Also proven quite beneficial has been my degree in neuroscience. Because of it, I spent my fair share of time surrounded by scientific research in labs, and became familiar with the scientific method, which is not too different from many design processes.

When reading books like “Creative Confidence” (Tom Kelley, David Kelley), “Insight Out” (Tina Seelig), “Creativity Inc.” (Ed Catmull, Amy Wallace), and “Sprint” (Jake Knapp), I came to notice many similarities amongst their design processes and the scientific method. In general, both the design process and scientific method look like this:

Untitled_Artwork 7.jpg

On a slightly more granular level, the scientific method looks like this:

Attribution: Wikipedia Creative Commons

Attribution: Wikipedia Creative Commons

In addition to reading books and leveraging my academic experience, I’ve taken to online courses. The most recent being IDEO’s course in Human-Centered Design. This course put me through their design thinking process. The course’s emphasis on teamwork (I worked with a partner throughout), building empathy, and solving real world human problems (not just those faced by the tech elite) showed us the importance of fostering a deep level of empathy for the people your product serves.

To get a better grip on the nuts and bolts of how product design functionally works, I’ve read through Google’s Design Sprint Kit and often reference back to it. It clearly outlines how they run things and even walks you through specific types of research methods and decision making exercises. This resource, in addition to their material design system, has most directly influenced how I work.

Now, after designing a few websites for people, creating personal projects, and joining Insurify’s Product Design Team, I have been able to refine and define my own process.

IMG_0038.JPG

PHASE 1: DEFINE

Step 1: Understand the problem

This stage is about information gathering and idea forming. From researching the problem with google searches or analyzing user data, the point is to determine the scope of the issue. Then, as is done by Google and IDEO, I brain dump the possible areas for improvement. Both Google and IDEO use the “How Might We” approach, where a team of designers and stakeholders come up with opportunities for improvement. In the case of a telemedicine app, you could ask “HMW speed up the user onboarding process?” or “HMW make it easier to schedule a doctor’s appointment?”

Step 2: Empathize with Users

This might seem like a “woo woo” stage to some, but I find it important to intentionally try to put yourself in the user’s shoes. It’s way too easy to fall into the trap of assuming your users are like you. So, we must actively work to avoid that trap!

For me, that mostly looks like interviewing friends, creating user journeys, and just trying to look at a project with the eyes of someone who hasn’t seen it before. But, on a team, that could look like conducting user interviews or observing other people attempt to accomplish a critical task with your app. These observations should helps identify points of friction (and therefore problems to solve).

Step 3: Define the problem and desired outcome of solution

After the initial steps of information gathering, empathizing, and brain dumping ideas, the team (or individual, in the case of working on a project solo...as I often do) must cull the most important information and best ideas. Once done, I like to describe the problem AND the desired outcome of the solution in a sentence or two. This forces concision and focus.

Then, it’s important to get more granular and outline the success metrics. How will success be measured? What data points will we be analyzing to determine success? Describing the ideal solution and its metrics gives a clear vision of what to shoot for, making this a very pivotal part of the process.

Another exercise I like to do during this step is to write a future press release. Google’s Design Kit does a good job explaining how to do it and what purpose it serves, but in short, this forces you to define what your ideal case scenario looks like for people not involved with the project.

PHASE 2: IDEATE

Step 4: Research the problem and existing solutions

This is the step of a thousand tabs (for me, at least). Now that the problem and ideal solution are clearly defined, I can focus my research efforts on the best way to serve our users. For me, this usually encompasses doing market research to see how others attempt to solve the same problem and looking into existing user data again to identify their pain points within the context of our more refined question.

Step 5: Sketch solutions

Now onto the most “creative” part! Here, I whip out the pens, pencils, highlighters, post-its, and maybe a rudimentary Sketch document to get some quick wireframing done. The point here is to visualize many potential solutions to the problem without investing too many resources.

PHASE 3: CREATE

Step 6: Decide on the concept to move forward with

After coming up with many low-fidelity solutions, the team needs to pick the best, most viable option. Ideally, the best options are selected by a process that includes voting and gathering input from stakeholders on all teams that would be involved with the development of the solution.

Step 7: Prototype selected concept

Now that the best option (or options) have been selected, it’s time to create high-fidelity designs, refine them, and send them off for development! I usually do this using a combination of Sketch, Adobe Illustrator, and InVision. Depending on the scale of the solution, some user testing can be done with the high fidelity designs so as to iterate and improve on the solution before sending it off to the more expensive development process.

PHASE 4: TEST

Step 8: Test to validate, invalidate, or refine

Once built, the concept must be tested to determine if it actually solves the user problem. Doing so should either validate the solution, invalidate it, or highlight ways it does work AND ways it still needs to be refined. Assuming refinements are needed, which they usually are, repeat the design process as needed until the user problems are solved.

Though I’m fairly certain the “spine” of this process will remain the same throughout my growth as a designer, I look forward to improving it along the way! My hope is that by focusing on learning and continually refining a systemic approach to product design, I can most efficiently serve all stakeholders involved, including the users and the C-suite executives.