While designing a new feature a few weeks ago, a debate arose on one of my teams about the text for a certain button. Designers, writers, and product managers all weighed in and we narrowed it down to two options. Still, the debate raged on until someone suggested we send it to our user research (UR) team.
After testing both options with a few users, UR delivered the verdict – neither button was clearly understood by users, which was likely why neither could gain a consensus on our team. So we returned to the drawing board with a much clearer idea of what our users were looking for.
Crafting a user experience without user research is basically educated guesswork. Without directly researching the users of their own products, UX developers, designers, and writers can only make decisions based on industry standards and best practices, which often makes for a user experience that isn’t directly focused on your users. Indeed, in organizations that put a strong emphasis on their users’ experience, user research may be the most important role in the company.
The Understated Value of UR
Whenever possible, user research should be the foundation of major UX decisions you make, because it allows you to make those decisions with confidence. Whether through polls, surveys, or user interviews, user research helps stakeholders understand their users and ensure that the products and features they’re building are what users want.
“We’re reducing risk, which is ultimately what user research does,” says Ashley Sewall, Senior User Researcher at Cvent. “We make sure designers, product managers, and developers have enough information to make effective decisions that are going to decrease their risk.”
That risk includes everything from a confusing workflow to a feature nobody actually wants or needs. Without user research, product teams are operating blindly and are left to make assumptions about their users that may or not be accurate – teams who spend 40+ hours a week working on a product can’t ever fully remove that internal bias when reviewing new features. This can lead to teams fixing UX issues as they arise, instead of preventing them in the first place.
User research allows stakeholders to validate and justify their decisions with real user data. A product manager may be resistant to use a certain term for a feature, but if a UX writer can provide concrete examples of users who prefer that term to an alternative, both the writer and PM can feel more comfortable with their decision. What’s more, the UX writer can now reference that research the next time a similar term or feature comes up.
User Research Shouldn’t Be a Bogeyman
For the most part, the benefits of UR are easy to understand, but for those outside of user research, UR can often seem like a bogeyman – a department that will cost extra money and slow development timelines and provides mysterious, undefined value. For someone trying to implement UR in their organization, these misconceptions may raise frustrating barriers.
“This is a typical roadblock that I hear for conducting research and invalidating the importance of research,” Sewall says. “But research can be really lean.”
Sewall emphasizes that these roadblocks can be avoided by being strategic:
Integrate with designers early in the development cycle.
It’s much easier to change a design earlier in the design process than it is once design and development have begun in earnest. This means that the earlier user research can get involved in a project, the less resistance it will meet from stakeholders concerned about adding time to their development cycle.
Be smart with your time, and prioritize projects that produce the most bang for your buck.
Even organizations with robust UR resources cannot hope to research and test absolutely everything that makes it into their products. When testing five people will suffice, only test five people. Instead of testing entire features, identify potential trouble areas and only test those. Narrowing scope and sample sizes can tighten up your research while reducing cost and time.
Make sure to communicate your value.
If you’re doing great UR work, don’t be afraid to let people know about it. Good results from UR perpetuate and emphasize the need for UR, especially if you can establish that your research doesn’t hinder other teams’ work.
You don’t need to be a user researcher to do user research. Once you’ve identified a need for UR in your organization, don’t be afraid to jump in and do it yourself. UR can be as scrappy and lean as you need it to be. Sites like Fiverr and Craigslist are a great resource for quick, cheap labor – many people will fill out a short Google survey for $5. Even just posting a question about a certain feature/workflow/button on LinkedIn qualifies as research because it gives you more user data than you had before. You may need to make compromises on methodology, but that doesn’t negate the value of your research. Even guerrilla testing is still testing.
“Knowing and understanding your user is obviously a shared responsibility,” Sewall says. All stakeholders should feel an obligation around performing or just supporting UR. Communicating the value and necessity of user research can certainly help get an entire team on board, especially if it reduces the risk of creating UX issues that will need to be revisited and fixed later on. As a UR advocate, getting everybody on board with UR is vital to your success.
User Research Is the Foundation of a Great User Experience
Researching and testing with users is an easy step to skip. “Your product has to get designed and it has to get built – it does not have to get researched,” Sewall warns. However, it’s impossible to build a product or feature with great UR if you don’t actually know your users’ needs and goals. A designer can craft much better solutions for users once they know them, know what they’re doing, and know what they need to accomplish their tasks.
By researching users and testing your designs with them, you create a dialogue that fosters positive user experiences and saves your organization time and money down the road.
Go to Source
Author: Jonathan Deesing
Powered by WPeMatico