usability

Update: I’ve edited a few parts to make it a little clearer. Same message, just easier to understand. Iteration for the win!

This could have also been titled: “Why you are doing your organization a disservice if you’re hiring researchers to only conduct usability testing, or hiring designers to do research.”

Welcome to this week’s soapbox post! 

If you’re familiar with me or my work or you’ve been keeping up with this blog, you know that I am currently in the market for a new job. I fully realize in a post-COVID world that being a researcher (while it should be one of the most important roles today for a lot of companies during turbulent times) is actually a very tough position to be in when looking for a job as it’s always one of the first cut in product development. 

I think this happens for several reason, two of which I am going to address today. 

One: A lot of job descriptions I’ve read lately are looking for UX people who are capable of conducting research and doing usability testing. While these are indeed admirable traits to have as a UXer, and I’m one of those UXers that embodies them, I would not recommend relying on your designers to do all of the research work that should be done. Why? Well, if for no other reason these are two different skillsets. Additionally, if you have an agile environment with a continuous release cycle, your designers are already too busy keeping up with that. Not to mention the fact a proper research team should be a full quarter or two ahead of them! It is difficult to encompass both of these capabilities in the same role. Research should be a full quarter or more ahead, you ask? Yes, and this brings me to my second reason. 

Two: There is a lack of understanding of what research is and how it can be useful. Usability testing (and yes it’s usability testing NOT user testing – we are testing the usability of a site not the user’s ability to use it, those are two different things and this means a lot when you get into inclusive design) is not the end all be all of user research. In fact, it is a tiny sliver and if the appropriate research has been done ahead of time in your organization, you will not need it as often and you won’t have to rely on it as much.

So let’s break that last point down. Usability testing is generally what I see organizations who are new to research using to dip their toes into the discipline. They have read and seen why it is important and think that it will make a difference for their users. This is all correct. The problem is many organizations who are new to this think that’s all there is to research and they feel they have to test every single thing before it is released. In reality, research should be more about problem finding than trying at the very end to work on testing solutions to problems that were likely not fully understood to begin with. 

If you have a research team that is versed in problem finding (utilizing generative/exploratory/discovery methods) and uses those skills to help your product people fill their gaps and blind spots, it is likely that a lot of the issues that your products or services are currently challenged with will be solved as a nice side effect when you focus on those uncovered during this phase. Why? Because, solutionizing right out of the box is how a lot of products and services find themselves in trouble. Going problem finding opens your organization up to a whole host of new possibilities and opportunities that would be otherwise missed and cause issues down the road because you didn’t know they existed.

By conducting exploratory and discovery sessions first, you’re connecting with the people in your space who are trying to solve their problems with your product or service. When you understand what those are, it makes it easy to see that they are the problems your work should be focused on. If your product or service does not solve problems for your users, it doesn’t matter how usable it is or how many features it has, it will never end up being what they are looking for. 

Additionally, the treasure trove of data your researchers will come back with during this phase will likely reveal a lot more opportunities for ideation and innovation than any single product manager will have the capacity to do. (This also helps relieve some of the pressure product managers have due to all of the other responsibilities they are saddled with in this day and age.) The added bonus is that when you use data to drive your designs from the beginning, it results in designs that have fewer hurdles to cross when it comes to usability testing because they started with a firm foundation of data to support them. 

In the end, this results in faster design, development, and testing time which equals faster time to market. This, however, ONLY works if you have a research team that is able to work well ahead of your design and development teams while at the same time also working through the design and development phases to continue advocating for the users throughout the entire product life cycle. This is why I do not recommend designers be the ones who also have to shoulder that responsibility. Yes, EVERYONE on the team should be a part of the research process, but they also have their own roles to play and the researcher is there to help make it easier, faster, and more efficient for them to do so. 

So the next time you’re writing a job description, I beg of you to keep all of this in mind. And, when you’re looking to cut – consider the amount of money a researcher can save you and make you if you truly utilize them in the right ways.