Having a process for one’s work flow is important. I’m opposed to an unstructured design process because it tends to require more time to arrive at a solution. But there does not need to be a strict enforcement of every detail, just a structured understanding of how one defines a problem and then validates a solution.
My particular process follows the general design thinking explained in beautiful infinity symbols or the circular graph. It is a repeating cycle that involves iteration and forward progress.
EMPATHIZE – What is the problem?
DEFINE – Why is this problem important?
IDEATE – Brainstorm ideas.
PROTOTYPE – Build and experiment.
TEST – Get people to use it and provide feedback.
The process feeds into itself. A problem is identified and defined. The solution is explored and built. Testing this solution validates or invalidates the initial assumptions. If the test revealed that the solution was not working, more empathy and defining is required. This further research would provide more insight for the ideating and prototyping phases.
Another way of looking at this falls inline with the Double Diamond design method. This method seeks to discover and define the problem through a process of diverging to understand a variety of problems and then to converge on a solid, single, well defined problem. Once defined, another phase of divergence occurs exploring solutions to finally converge on a solid, single, well built solution.
The first diamond
Working through these methods during a design project reminds me of this quote,
Fall in love with the problem – not the solution.
I keep this at top of mind always. Digging into the problem and learning why that problem exists becomes a major part of my process. This involves a lot of questions, or more specifically, at least five – the 5 whys. The 5 whys is an interrogative technique originally developed by Sakichi Toyoda, and used at the Toyota Motor Corporation to ensure the quality of their product. Asking why once or twice does not really get us to the root of the problem, but asking it five times gets us much closer. Often this questioning can reveal deeper rooted problems that exist systemically and take much more work to solve. However, understanding my own agency within the project helps determine which level of severity I can tackle and design around.
Creating a UX research plan helps keep the important things important. There are plenty of times I could go off the deep end and start building around the wrong problem, so making sure the research is targeted and purposeful comes with a plan.
BACKGROUND – What is the research for and why?
OBJECTIVES – What I hope to learn from the research.
METHODOLOGY – What methods I plan to use to uncover insights.
PARTICIPANT PROFILES – People I am targeting.
GUIDELINES – Interview questions and/or scripts to follow.
TIMELINE – How long I expect the research to take.
For me, a lot of the questions I ask, and the research I conduct all live in one place. That place is often in a Figma file divided into many pages. Below is an example of research I did for the Query block, a robust site-building block for the new full-site editing experience in WordPress.
The findings are then accumulated and shared with teams and stakeholders so that everyone is on board. Gathering more feedback from developers and stakeholders is important to the process to ensure we are all on the same page and understand the problem.
The second diamond
While the first diamond explored the problem, once that is defined, the second diamond explores the solution. This requires a lot of iterations and prototypes to be built. Again, much of this exists inside Figma in the early stages. If the project necessitates more interaction for the prototypes, I have jumped into applications like Codepen.io or Codesandbox.io.
This process is about nailing down which path we would like to see built into something that a user can test. I enjoy collaborating with developers to write solid user stories. These tend to focus on the type of user we are targeting and a series of flows these users may experience. During this, I strive to understand the job that the user needs doing so that we can build adequate prototypes. The prototype, in infancy, could look like this example from the Query block below.
Testing
Ultimately, the desire is to create prototypes that support a great research interview during testing. Whether it is moderated or unmoderated testing, I have found that the more robust the prototype, the better insights I will get. If there are broken links or distracting elements that draw the tester’s attention away, then that is attention taken away from the problem at hand. So testing the test is important before actually testing the test. This means I test the prototypes out to make sure there are no obvious roadblocks or rabbit holes a tester may encounter. I want to keep the tester focused on the right thing.
Once the testing is completed, it is important to bring that information back to the team. I collaborate with developers, project managers, and stakeholders to share the information. Working with project teams, I use the learnings to help guide any iterations necessary. These iterations then proceed through the Design Thinking process once again.
It becomes a cyclical process of learning, building, and testing.