Often when we talk about the design process, we outline it according to phases, and those phases generally are articulated around research, design and testing/development.
In this article, I’d like to focus on the first two and how moving between the problem and solution or research and the start of designing the solution doesn’t necessarily happen in one graceful leap. There are shades between them, and when I recently gave a guest lecture at the New School to graduate students, it gave me the chance to reflect on those dimensions. Specifically how research contains three nebulous phases within itself — gather, analyze and assess — before you define and decide on what to design. Here’s how I go about doing it:
Gather Information
Whenever I begin a project, I do a discovery phase. That’s because before I start mucking around with the product, I want to understand the product as it exists today — how it works, who uses it and how people maintain and run it. It’s my responsibility to have as holistic an understanding of all the nuances that create the ecosystem the product lives in before I can strategically recommend changes to it.
That means I need to gather information, and as a UX consultant, my aim is to gather as much information as possible without bias or prejudice. When I gather information, I don’t assess it. I maintain a researcher’s perspective in that I must let the information build the picture for me as opposed to imposing my impressions upon it.
However what does “information” mean? How do you gather it? Where do you look for it? I generally look to collect data — quantitative and qualitative — from three resources: the business, the users and the competition.
Business Data
This is information that your client or business stakeholders have about the product. This includes hard analytical data or qualitative impressionistic anecdotes about customers. This type of information can tell me lots of things when I analyze it like the history of the business and how their internal processes work, who the key stakeholders and decision makers are, who the key internal stakeholders are who help maintain product and/or interact with users, whether pain points and opportunities exist on the business side, whether the product/stakeholder team is actually aligned on the project scope, value proposition or business goals of the upcoming design phase.
In addition, in collecting the information, you introduce yourself to these stakeholders. You show that hearing their viewpoints about user needs and business problems is important. In talking to them, you give them the ability to collaborate and contribute to this phase, and this helps build confidence and credibility for that important moment when you shift into the design phase.
User Data
Often, I start with business resources because they unlock unexpected user data. Your stakeholders generally are in a position to have information about your user beyond anecdotes, but they aren’t always aware of them until you take time to search. This builds collaboration between you and your business stakeholders, and it helps set the table for empathizing with their users. Beyond this, user data can include any qualitative or quantitative data about users you get directly from them.
This information can come from audits of social media accounts or customer feedback through more official sources. I once asked my client’s reception desk to track any user phone calls about how to find information on their website for a week. You can do user interviews through official focus groups or guerrilla user testing. The most important aspect of this data is it MUST come from the users themselves. You cannot get this information secondhand through someone else’s perspective because you want to get solid grounding to empathize with the people who are actually meant to use the product.
Competitor Resources
Benchmarking your product against the competition is important. From this information, you can compare how well the stakeholder’s understanding of the product is to the actual marketplace. What pain points can they exploit better? What opportunities have been forgotten by everyone? When looking at the competition, there are multiple lenses to consider as well. Who are the direct competitors? Who are the indirect competitors? What products completely outside the value proposition might lead to value innovation? To learn how to do a methodical competitive audit, I recommend checking out Jaime Levy’s User Experience Strategy book. (Full disclosure: I helped edit it.)
Analyze and Assess the Information
Once you have all the information you can get, it’s time to judge it. Remember, in gathering the data, it’s important to maintain your impartiality. But data on its own merits is meaningless. It’s up to people to endow it with meaning.
Now is the time to pull out all your data visualization tools — journey maps, empathy maps, flows, personas, other infographics, etc. By comparing and contrasting the information you have against each other, you are then able to identify gaps about unaddressed user pain points or opportunities for innovation. You’re able to tell the story behind the data, and this then helps you make decisions about what to do next.
And the most fundamental way to do that is to assess it through different filters that your box of design tools allow as well as what perspective the individual members of your team bring to the table. For example, depending on the project, I’ll often color-code qualitative data to show how my assessment of project priorities is based on multiple stakeholder and user comments rather than just from one person. Or, I’ll build out a business flow and the user flow to show how they intersect and how they affect one another.
It’s vitally important to share the picture with everyone on your team — designers, engineers, strategists and stakeholders. It’s how you get team alignment by using your research to align your team and gain consensus among these that these are the opportunities and/or pain points that everyone agrees are the focus of the current scope of work. This helps avoid feature creep and disagreements in the future. Or you use this moment to redefine the initial scope of work because everyone is on the same page to make that important decision.
Conclusions
Once the information is on the table, then you can start brainstorming solutions with the team or present possible recommendations based on the research. From here, you can move into the next general phase of the design process which is the design of the potential solutions, and then from there, you should prototype and test or potentially do more research.
But that initial research phase does a lot of work to set you up for success. It’s not only about building up your own understanding of how to guide your client and team through the process to the right user-centered solution, but it’s also about building the confidence and ability of your team to make the right decisions to help you do that collaboratively.
