Three Virtues of User Research & Strategy
There are far too many “definitive” attributes of anything. The business section of any online book retailer is rife with tomes on the x dimensions of successful strategy or the y habits of successful leaders. When I sat down to write this, I intentionally did not spell out every possible element of a successful UX research plan or strategy. Why? Because every user is, first and foremost, a human. Humans are dynamic and unique creatures. As the uniqueness of humans goes, so goes the uniqueness of your users and, ultimately, your UX research and strategy.
Rather than pose a stepwise process for conducting better research or building a better strategy for folks to map out in a framework or flowchart, I’d like to highlight three virtues I think anyone responsible for leading user research and strategy should seek to embody:
- Humility — Our users have the perspectives we’re looking for, our job is to help draw them out
- Advocacy — Our users don’t sit in feature prioritization sessions, but we do
- Courage — Our users will guide us when we don’t get the solution right; we must be willing to take a chance and learn
While there are more things we should keep top of mind as we engage in research activities, these three have served me well whenever I engage on a new project, product, or client. I’ve found they add a sense of wonder, purpose, and drive to the work.
Humility
“You are not the user.” We’ve all heard this axiom from Nielsen Norman Group. Yet, I think many would agree that this is the hardest concept to uphold after spending 10’s, if not 100’s, of hours in discovery interviews, evaluative tests, and other opportunities to engage users. It’s easy to adopt a “if you’ve seen one, you’ve seen them all’’ mentality, which is limiting. People are always evolving, meaning there is always a new nuance, need, or behavior that we should try to understand.
In a previous job, I spent the better part of three years engaging with financial advisors to figure out how we could build products to better help them serve their clients. I, along with a great team of researchers and designers, spent nearly 300 hours in user research with these financial professionals. Of course we found patterns and commonalities in how different advisors approached the task of navigating their clients to successful financial futures, but each one brought their own flavor to the work. Whether it was rooted in the reason why they chose to get into financial advice, the types of clients they chose to prioritize in their practice, or the frustrations in their day-to-day tasks they wanted to eliminate, there was always something new to learn.
The trap with assuming you already know your users and their needs is that you’ll quickly begin thinking you know the answer before you have asked about the problem. We all have at least one product or feature we worked on that got a little too far down the road before we realized it was a solution in search of a problem. This phenomenon manifests itself even in how we employ human-centered design techniques. I’ve seen workshops where teams are being tasked with building persona profiles or affinity clusters of user needs without having done the important ethnographic, participatory, or evaluative research up front to generate the insights needed. Absent taking the time to go out into the world and inquire, these are only assumptions.
A friend and excellent researcher once counseled me to always be curious. Not only are we not the user, we also do not have all the answers. Our strength as user researchers and strategists lies in our questions. When we derive human-centered solutions to the problems presented, we must always remember they are not a product of our own thinking in isolation, but of the many voices, needs, and challenges of the users we engaged.
Advocacy
The implications of user research is one of several inputs that will inform the future direction of a product. Tradeoffs and prioritization are inevitable, so it falls to us as researchers to advocate for the voice of the user with confidence and an air of credibility. Feature prioritization is a delicate dance of influence and persuasion in which our conviction and bonafides will play a critical role.
There comes a point in the product development cycle where the rubber inevitably meets the road: the needs of users will be stacked up against the strategic needs of the business and its stakeholders as well as the technical/infrastructural needs that engineering will represent. Prioritization of what to work on next and to what end is a back and forth process of justification, negotiation, and compromise. As a user researcher and strategist, you need to have an insights-informed stance on what your most critical priorities are for development. Business leaders, product leaders, and engineering leaders will all have a seat at the table in product planning discussions. User researchers and strategists are the voice of the user at the table. It is incumbent on us to be their voice and advocate for their needs. Being users’ advocates is an enormous responsibility. If you can’t effectively make the case to prioritize their needs, then the utility and desirability of the product erodes, which has knock-on effects to its ongoing viability.
Unfortunately, advocating for users’ needs will sometimes be directly challenged by internal politics and “ways of doing things.” In a prior job, our discovery research and evaluative testing had identified three key aspects of the product that users indicated were significant barriers to their adoption into mainstream use. While we had de-scoped these capabilities in the interest of bringing a minimum viable product into market sooner, my team made it very clear that these needed to be high on the priority list if we wanted to attract and retain users. In the weeks following launch of the MVP, our prioritization efforts fell victim to the HIPPO (Highest Paid Person’s Opinion) or, as I call it, “The Captain’s Choice.” These capabilities were pushed far into the backlog and our adoption/active usage struggled.
If we continually ignore user needs and desires, the product will languish. Nobody wants to use a product that has cumbersome, inefficient processes and unintuitive navigation. Yet, if we’re being fair, feature prioritization can’t be all about user needs all the time. If we completely neglect strategic business priorities, cost considerations, and revenue targets, we won’t have the financial viability to continue investing in the product and it will go away. If we completely neglect technical/infrastructural needs, the product will struggle with buggy code, unreliable technology, and potential security concerns. What user would want to use that? Feature prioritization is a negotiation between three key voices tasked with representing their constituents. Your constituents are the users.
Courage
Let’s face it: fear of failure is real. Despite catchphrases like “fail fast and cheap,” there is a deep reticence to take a risk and do something that could be wrong. In my experience, part of this fear is rooted in risk aversion while the other stems from not being able to position a failed idea as a gateway to something better. As UX professionals, I believe that we should endeavor to get things wrong so that we more clearly see how to get things right.
Prototyping is a great way to take the risk out of experimenting with new ideas and concepts. In the book Creative Confidence, Tom and David Kelley of IDEO and the “d.school” at Stanford celebrate the idea of “Boyle’s Law,” named after IDEO partner Dennis Boyle. The concept is quite simple: never go to a meeting without a prototype. Prototypes allow for your users to engage with a more tangible representation of a solution concept. By interacting with a representation or facsimile of a fully engineered solution, users can better put themselves in the context of how the tool may or may not fit their mental model, expectations, and processes.
Prototypes operate on a spectrum of fidelity; from rough and ready to near pixel-perfect vaporware representations of the final product. The lower the fidelity, the easier it is to test core, critical assumptions about the problems users are having and how they expect them to be solved. Put another way, it’s infinitely less expensive to throw out a fundamentally flawed idea at this stage. With lower risk and lower investment, we can reserve the right to play with more exploratory ideas of how to address users’ needs.
It’s important to highlight that you should avoid the urge to make prototypes higher fidelity too early in the process as two key risks will arise. First, the team will be significantly more invested in the idea and it will be harder to keep those cognitive biases in check if it doesn’t pan out. Second, you won’t get the right level of feedback from your users. Low fidelity prototypes give you the grace to ask more fundamental questions about expectations of functionality, behavior, and flow. Higher fidelity prototypes give the impression that you already have much of that figured out, which may cause your feedback to skew more heavily towards tactical items such as color, typography, and more nuanced page layout. Moreover, high-fidelity prototypes introduce attributes and variables that create compounding effects in the mental models of our users, making the evaluation much more complex.
Now that we have prototypes deputized as our method of taking risk out of failure, how do we tell a better story when our concepts don’t exactly stick the landing? First, how we frame the prototype testing to our internal stakeholders will play a big role in properly managing expectations. I’ve seen many early-stage test plans that state they are validating the effectiveness of concepts and hypotheses, when instead they should state they are assessing, evaluating, or testing the effectiveness of concepts and hypotheses. Test plans that seek to validate a hypothesis too early in the product development cycle, suggest to stakeholders that the team has a strong opinion that they’ve got it right and, like it or not, that will anchor those stakeholders to the notion that you have a winning idea. Frame your test plans so that all parties know that you could come back having learned the user’s needs weren’t effectively addressed, but you will know more about how to address them.
In the event the results come back and the concept wasn’t a success, focus less on the fact that it didn’t work and more on all the reasons why it didn’t. When users tell you why something didn’t work for them, they are also telling you what will make a future idea more successful. In my last job, we were tasked with figuring out how to represent a capability that used an AI engine to optimize several key parameters to achieve a targeted outcome for a retirement plan. Our first prototype illustrated the optimization of each individual parameter in a stepwise pattern. It failed miserably. We learned from that test that each of the parameters could not be taken in isolation, rather, they were viewed as constantly interacting with each other to achieve the targeted result. This insight was the headline in our stakeholder readout and sat at the core of our brainstorming for two subsequent iterations over the course of a month. By boldly getting it all wrong, we were able to extract the clues on how to get it right.
Be a virtuous UX professional
As user researchers and strategists, we have the unique opportunity to uncover deeply human challenges in digital product and service experiences, be the voice of those humans when product decisions are on the line, and take risks to explore new and creative ways to address these problems. It’s a responsibility we shouldn’t take lightly. By having the humility to listen, the responsibility to advocate for users’ needs, and the courage to productively get it wrong through rapid, low-risk approaches, we can build better things for the people around us.
