My Process
LEARN | empathize | define | ideate | prototype & test | Other Docs
I believe that understanding my process will give you a better idea of how I work than simply showing a handful of projects and pretty pictures.
“Most people make the mistake of thinking design is what it looks like . . . It’s not just what it looks like and feels like. Design is how it works.” - Steve Jobs
“Content precedes design. Design in the absence of content is not design, it’s decoration.” - Jeffrey Zeldman
Although the context below is outlined in design thinking, I use the User-Centered Design (UCD) process.. Design Thinking (DT) is too often an over-simplification of UCD and emphasizes doing the steps like checking boxes, and doesn’t really address the ‘how’ or the quality of each step.
For example, I don’t adhere to empathy as a step in a defined process. It’s not like I’m “Ok, I’ve empathized. Now it’s on to step 2 where we define!” Empathy infuses itself throughout the entire process from beginning to end. It is not just a step at the beginning.
Following the DT process, in the “define” stage, we define the problem. Ok, we’ve found a problem. Let’s work on solving it! That’s what DT tells you. But are we even solving the right problem? Or just A problem? Are we accurately getting to the root of the issue?? Or are we simply accepting surface issues as “the” problem? DT often glosses over the “how” of the framework (and all of they “whys” that we should ask).
All of that being said, the following steps are based upon the 5 steps of the Design Thinking process model (with an extra “Learn” step thrown in - taken from various parts of the UCD model). UX is about understanding the user, and how the users inform both the product design and product management (UX Strategy). UX encompasses a range of processes, eventually culminating in workflows and product designs.
learn
Often, in order to understand where problems lie, especially after asking "The 5 Whys," you need to understand the product you are testing. Otherwise, you might miss valuable insights that the customer might communicate to you without actually saying something. “Learn” here, is similar to IDEO’s “Understand” phase in their DeepDive Design Thinking framework.
If the tech is new (to you), do research to understand it and how it works (this includes asking the experts when you aren’t one)
Understand who the users are or will be
Understand (current) or develop (new) personas. These will be malleable and subject to change and refinement over time.
Find those users, or where they are
If appropriate, start with the knowns and perhaps a few hypotheses of the problems
Here are some samples of different types of learning:
empathize
IIn this stage of the Design Thinking process, we have identified the users, and now we learn from them. The goal here is to understand the problem. For the very first iteration, this is the Discovery phase. Here we learn from users what their problems and pain points really are. We start broad within the feature or area we are working on, and let the users guide us and take us where they want. Spoken interviews and contextual inquiry are typical here as well as a hybrid approach where users screen share and walk us through their process and pain points. Once we get through Prototype and Test we come back here and repeat the process (iteration), refining in every iteration. This is similar to IDEO’s “Observe” phase in their DeepDive Design Thinking framework.
Define
Analyze user input:
look at the problems presented,
determine which are common or outliers,
Run through “the 5 whys”
If necessary, update or refine personas
In this stage we analyzing and interpreting user input in order to define the problem(s). We need to remember that our goal is to solve the users’ problems and not to just wireframe features that development or product management thinks are good. We are here to create a better user experience, not a better experience for everyone but the users’ hypotheses. In this phase we not only examine and analyze all of the user input to determine what the users’ problems are, but we then go through “the 5 whys” to determine any underlying problems surrounding the users’ issues. The end goal here is to have not only the problems defined, but the correct problems defined, and ready to build upon for the next phase (Ideation).
ideate
Break down (customers) problem statements into areas of the product or product workflows so we can figure out which chunks to start with that would provide the most powerful customer impact
Decide on an area(s)/feature(s) to begin with and build a 10,000 foot view, and potentially a mental model of the current (and malleable) end-goal. We are working on the customer problems and creating (multiple) ideas that will solve the problem
Develop workflows - current and desired
Sketch out wireframes (solution hypotheses from user input), and determine what the MVP is to get useability testing started
Define and Ideate go closely together, and the lines are often blurred. During the Ideate stage we discuss the issues and get creative and imagine possible solutions. We attempt to create a vision for the end product. The goal here is to come up with a number of different approaches so that we can ultimately narrow them down, and ultimately come up with the parameters for an MVP product to prototype and test with in the next phase. With each iteration we are either changing and/or refining the MVP, or adding new features to build upon the MVP. This is the creative phase.
prototype and test
In this phase (these phases if you count it as two) the goal is to build a prototype and bring your ideas from the previous phases to life. We build a basic prototype and test it. Then we take that input and refine it by going through the whole design process once again by repeating the steps of the Design Thinking process over and over. Each cycle is an iteration. The goal here is to eventually develop the optimal solution that meets the users needs and solves their problems.
Create a testable prototype of the MVP
Useability test it, take notes.
Analyze useability Test results:
Were the problem hypotheses correct, or did the users indicate a different problem?
Did the proposed solution solve the problem?
If so, what aspects?
Some or all?
Can we still improve?
If not, are minor tweaks needed, or a full redesign/new approach, or something in between?
Were new problems discovered?
If so, run through “the 5 whys”
Iterate through the TEST CYCLE
Has the MVP Been fully validated?
Determine next features/components to add on to the MVP
Other UX Documents
Often other documents are necessary and delivered within UX outside of the scope of the Design Thinking processes above. Some of those are style guides, UI audits, stakeholder presentations, and sometimes a UX assist is needed in developing Product Roadmaps with Product Management as well as breaking down that roadmap into release points in order to work with an agile development team.
