Lately I’ve been asked to enumerate my UX design process. My answers have involved use cases for perfect-world processes involving teams, collaboration, and iteration. While I still believe the best results happen as part of a team with a diverse set of skills, I felt the need to boil the UX process down to generalities to suit any given situation.
From my experience, the best results are achieved by 1) defining the problem/opportunity; 2) researching similar solutions, users, and methods; 3) designing variations; 4) testing with prototypes; 5) implementing solutions; then 6) analyzing results. With this process we can achieve the ultimate end for any product or feature: to do a job — whatever it might be — the most efficiently and effectively.
Problem or opportunity definition will color the rest of the process. It’s essential we examine the task a user hopes to accomplish in a given situation in order to start to find the best solution. Diverse teams with developer involvement can help prevent technical issues early. In order to be most effective sometimes it helps to plot problems on an effort/effect graph. Ones with lower effort and higher effect can be prioritized. The more narrow we can define the scope, the more targeted solutions we can provide.
Following problem definition, research into similar or competitive solutions is a must. It’s essential to learn if and how this problem is currently being addressed. If it’s a problem for me, it’s likely it’s been a problem for others too. This is also the stage where we can dive into user needs and expectations. This step can be blown out into defining personas and use cases depending on the situation and complexity of the problem.
Armed with insights from our research we can next start visual explorations that aim to solve the original problem. Complex problems might require information architecting. Others will start with low fidelity whiteboard or paper sketches, as we begin to create layouts. It’s important to consider how edge cases might affect the overall experience and determine how much effort should be dedicated to solving for each. At this early stage, speed is key. Focus on simplicity. Critical examination of each iteration should start to hone concepts and require higher and higher fidelity mocks. Any technical questions should be referred to dev as soon as possible. From here we may or may not hand off to a UI designer.
Once we’ve got stakeholder sign-off and we believe we’ve satisfied requirements we build testable prototypes. User testing—specifically with users who understand or ideally have the problem we’re attempting to solve— will allow us to find out quickly to what extent our designs meet the brief. Based on test results we may go back to previous steps to analyze how we might improve, otherwise we continue to implementation.
Because we’ve had developer involvement from the start, there shouldn’t be any surprises at handoff. In fact, if the process was done correctly, for larger projects the dev team has already started on frameworks to support the new feature or product. Kick-off meetings should cover key concepts and highlight any interactions that need further explanation. Visual documentation should accompany the walk-through for later reference.
Testing can continue after implementation and results should be analyzed. It’s important to keep in mind that correlation doesn’t necessarily mean causation and sometimes it might not be immediately clear why something actually works. For this reason, A/B testing can help determine successful designs more quickly.
Repetition of this process will not only improve any aspect of a product that needs attention, it will also foster communication and trust within a team as we involve all key stakeholders from an early stage. Any aspect of the process can be expanded to include deep dives as needed however, from my experience, rapid iteration often leads to better results. The sooner we have actual feedback and usage data, the sooner we know how to move forward with next steps.
© Michael Pasternak, 2021
