User research is what sets user experience apart from most design processes. While it’s essential to make sure a system or product is designed to look great, if it’s not functional, those looks don’t matter. From background research to user interviews, and mental models to context scenarios, our team conducts extensive research to understand users in order to create a solution that solves their problems in the best way possible.

First, we need to know who will be using the product, and why. One of the best ways to understand this is to create personas (fictional users that are based on real data). Personas go beyond target demographics and market segments—they’re aggregations of living, breathing users that you’ve met, interviewed, and listened to. Creating personas is about understanding a user’s behaviors, motivations, and goals. It’s not a job title, it’s a representation of a person—one who loves to process data because he gets a thrill from finding conclusions, or another who hates filing paperwork because she feels like it takes time away from working with her team. We’re trying to understand how a persona would use a system, why they would use it, and how they feel about using it.

Personas are aggregations of living, breathing users that you’ve met, interviewed, and listened to.

To collect information for creating personas, there are few methods to learn about your users:

  • In-Person interviews: These are ideal, as they allow you to not only hear responses to your questions, but see the emotion in a user’s face as they talk about the work they do. You’ll learn quickly what they love and what they disdain.
  • Phone Interviews: If you’re unable to meet face to face, conduct phone interviews, but be sure to follow-up with questions about “how they feel about that”, and why.
  • Subject Matter Experts: At times we’re not able to speak to users directly, for one reason or another. In this case, we might have to settle for talking to subject matter experts, or SMEs. They’ve been in the industry long enough to accurately speak to user behavior, goals, and more. As you utilize this information, however, keep in mind that it is once removed from the source. If possible, verify with at least one user or another SME before making design decisions.
  • Environmental Visits: In addition to interviewing users, it is often useful to conduct an environmental visit, if you’re unable to do an on-site interview. This can answer questions such as “Is the environment dark? Dirty? Loud?” By understanding the user’s environment you have a better understanding of their needs and potential issues.

See the emotion in a user’s face as they talk about the work they do.

Once personas are created to accurately represent the various types of users that would interact with a system, we’re able to create mental models for each one. These are narratives or charts that help us understand how this user sees the world, including how objects, people, and systems relate to each other. It’s often easiest to chronologically work through a day or series of tasks, and think about all of the people, objects, and decision points involved with a process. For example, our data fan above might have a mental model that includes a decision point of which metrics to use for a certain study. This leads our design team to think about how a new system might help this user think through his decision, and provide help with deciding on a metric.

After mental models are mapped, our team creates context scenarios, or narratives that tell a story of our persona walking through using the new system. Up until now, all research has focused on how the user does things today. When we transition to context scenarios, we get to start thinking about how they will do things in the future, using the new system. All narratives should still be high level, but might include phrases such as “Carolyn inputs her testing goals into the system, and it suggests various metrics that should be collected to meet those goals.” This implies that the system has certain functionality, without diving into details. We’re not designing yet, we’re determining the requirements of the system to meet user needs.

Depending on the scope of the context scenario, and the granularity of the tasks in the narrative, the team can begin to generate high and low level requirements. It’s at this point that the design team can begin to transition these needs into frameworks, wireframes, and eventually high-fidelity designs.

When conducting early research, be inquisitive, be interested, and most of all, be empathetic to your user’s problems. Armed with data and research, you will uncover your user’s needs and problems, sometimes even before they can articulate themselves what those might be.

When conducting early research, be inquisitive, be interested, be empathetic.

Getting started on a project, or feeling like you’ve missed the mark on your users? We’re here to help. Message us to see how we can work together.