The Usability Guy
The worst thing a coworker ever called me was “the usability guy”.? When you’ve got polished set of procedures for quickly and painlessly running a particular type of research, you can find yourself pigeonholed as only useful for that thing, missing out on all the opportunities for other kinds of impact.? One of the most common failure states for user research is being captured by our methods and tools, focused on the mechanics of research instead of the actual goal of helping the product.? On the researcher side, this means falling into the habit of using a single well-crafted hammer to treat every problem as a nail, using one’s best/easiest/cheapest tool to tackle problems that it might not be suited for.? It’s a bit more forgivable from the partner side, since we can’t really blame them for thinking that the researcher is only good for the method the partner has seen them use before before.
To combat this, I find it best to talk about methodologies (usability, playtest, survey, etc.) as bundles of related capabilities, rather than specific recipes.? Every game and team requires tweaks to the standard methods and our goal is to help make better decisions, not executing “perfect” studies.? That doesn’t mean we compromise the accuracy or impartiality of the testing, because that would undercut our value to the team.? Rather, it means that within the envelope of fair and rigorous testing, we customize the method to the needs of the game and the moment.? “Standard” can be just another word for “unoptimized”.
In the end, a playtest lab is just a room.? The fact that it has ten seats doesn’t mean you have to run ten participants.? A playtest might not involve actually playing the game, but just filling out a survey while watching a video.? Or you might not even want to use the lab itself, but take all the machines out and set them up in the office lobby because you need a different arrangement of stations.? Maybe all the seats are filled by QA testers and the participants are the ones taking notes.? It’s not about following the formula, it’s about assembling the pieces you have in order to best benefit the game.
领英推荐
One particularly important kind of adaptation is condensing a test to fit into the development team’s schedule.? As a rule, I don’t want to say “sorry, we don’t have time to run a test”.? Instead, framing the problem as “we’ll have to run fewer sessions so the results will just be directional, is that still ok?” or “we’d only have enough time to focus on a single feature, which one needs the most help?” works much better.? You go from being a rigid outsider to a member of the team, doing what it takes to deliver a good game on time.? Similarly, adapting your methods to a lack of equipment or facilities can mean that you get to start testing before the formal method is possible, hitting an early window for impact on the game that you’d miss if you waited until you could execute the method by the book.? An imperfect test is almost always better than no test.? Establishing the feedback cycle of research is immensely valuable in its own right, and going through the motions of a simplified study can produce insights about the team and the research process that will benefit the larger, more formal studies down the line.
It’s a truism that all research methods have strengths and weaknesses, types of problems they’re better or worse at detecting.? Even if we were to execute a method perfectly, things would still be missed simply because no test is capable of finding every type of issue.? What’s more interesting is to realize that within a method, there are an infinite variety of subtypes and tweaks on the basic formula.? There certainly are standard game research methods, and you can go a long way just by executing them as written.? But ultimately your game, your team, and the moment are unique and a researcher will deliver the most value by thoughtfully adapting to suit their needs.
Living human being trying to spread peace in this world & User Researcher Intermediate chez Eidos-Montréal
3 个月Really great article John! "But ultimately your game, your team, and the moment are unique and a researcher will deliver the most value by thoughtfully adapting to suit their needs" - 100 pourcent agree! For my part, I’m often called part of "the playtest team," as many teams primarily associate our work with playtesting. While this can feel limiting, I see it as a chance to connect and gain recognition, especially since "User Researcher" is often an unfamiliar or unclear title. In my case specifically, embracing this nickname provides a relatable entry point to start a discussion, and then try to highlight the variety of methods we use, discussing their strengths and weaknesses. It also allows me to subtly introduce the term UR into the conversation, helping to evangelize it. This offers food for thought: the use of nicknames tied to specific methods might reflect a lack of awareness or understanding of the term "User Research." :)
Some of my nicknames throughout my carreer: - data guy - numbers guy - a clerk - statistician - focus groups guy - Nielsen guy And probably a few more I can’t remember. At first I didn’t pay much attention as there was never an ill intent. However, in time in realized this was about the image I’m creating. And your image is your calling card in big companies-it tells people what you can do and gives them an idea how you can help them. My cure for it was: - work actively on your department image by holding knowledge sharing sessions and actively educate colleagues about the output worth of my work - blur the lines between insights department and product departments by not being a person who delivers reports but the one who learna about product develepment to be able to actively participate, and put insights into action I’m lucky to be able to say I’m working with a team where my approach worked and haven’t earned any new nicknames in a long while :)