“’Sooner or later any mechanism, if it is to accomplish any function in the human world, must come out of its shell and communicate with people. Ultimately, information systems only give value when they touch human beings,”’ Jaron Lanier says. Individual people remain largely un-programmable. They do things that the most imaginative programmers do not expect. And they want things that those programmers cannot anticipate.”
-From Dreaming in Code by Scott Rosenberg, 2007
Yes, it’s true, users do things and want things that nobody can fully anticipate, even super-smart programmers and the best UX designers out there. So, what can we do? How can we learn about the ever-illusive “user”? Why are we asking these questions when you know what we’re going to say? Wait for it…
User Experience Research!
User Research is a means to create and fuel user experience. User experience gives the research purpose while making the purposeful experience possible. Our team has had the privilege of seeing the work of other agencies and knows it can be approached in a variety of ways. We want to introduce how we approach our work in order to derive the best possible insights.
Best Practices Aren’t Always Best
The quote above from Dreaming in Code points out the unpredictability of users’ behaviors. This is the most important reason why NOT to overly rely on so-called “best practices” when it comes to user research methods. Best practices still need to be validated.
Even our own lists of best practices, best tools, and methods are rendered useless at times when completely unexpected actions come out of users. We aren’t necessarily wiping our memory after every study. There is a knowledge base we build upon, but when we believe in a user experience pattern, it is always best to test with your target users in the context of that design. After all, we are looking to lead, not follow.
Natural Testing, Reactive Facilitation
Testing should be natural—a set the objectives for what you want to learn, then forget a little, because the user is going to show you what needs to be tested.
If it is put in front of the user, then it’s tested. We may have an objective of learning if the user signs up for email, but we don’t need to ask about it. If it is on the page, then it will be tested. That is why it is crucial to build the prototype, tasks, or flows to allow for implementation of these elements along the way. The question will not be, “How would you sign up for email?” unless there is some new interaction we are testing to sign up for email. Even then, we would prefer letting them go through the main task, and see what they mention. If they don’t go into what we want, then we go back and ask, “What options do you have available from this page?” “What would you do from here?”
We Are Mining Insights, Not Recommendations
Mostly, we aren’t asking our users for opinions, and definitely not for design recommendations. The secret is translating their needs and behaviors into a purposeful and engaging experience. That is our job as UX Designers, not theirs. Users don’t do what they say—so don’t believe what they say they will do. Our observations are much more important than their verbal feedback. Verbal feedback is useful for explaining why.
Rosetta’s User Experience Research Team includes Rachel Thayer, Kyle Curley and Danielle Best, all of whom contributed to this post.