Learning the Subject Matter

As a user researcher, I’m not proud to admit that there have been times I’ve nodded along and pretended to understand a participant, while actually thinking, “What the heck is this guy talking about?” Of course, it’s a rare occurrence, but when dealing with very complex subject matter, it sometimes takes several research sessions before my “ah-ha” moment happens, and I begin to fully understand what the participants are talking about.

Learning the subject matter is a special challenge for consultants and freelancers who work with a variety of clients in different industries. There’s often very little time to get up to speed on the subject matter. It’s no wonder that clients are often skeptical that someone from the outside can come in and understand their business in such a short time.

Depending on the kind of projects you work on, learning the subject matter can be one of the most difficult aspects of starting a new project. Websites and applications aimed at a general audience are easy to understand and relate to because they don’t require specialized knowledge. For example, a photo site like Snapfish is fairly self-explanatory. That doesn’t mean that you don’t need to do user research, but at least you have enough familiarity to understand and identify with the subject matter.

But what happens when you’re designing an application to track biomedical research data, an electronic medical record, an investment banking application, an energy grid display, or some other complex subject matter? How do you know enough to ask the right questions and understand the answers if you have no prior experience with the subject?

Set the clients’ expectations

At the beginning of a project, clearly set expectations about your knowledge of the subject matter and how much you need to learn to do the project effectively. Don’t be surprised if clients are skeptical that you’ll be able to absorb what’s taken employees months or years to learn.

Admit your ignorance

Clients sometimes expect you to have more knowledge than you do. When the project was sold, you may have been portrayed as, or assumed to be, an expert in the domain. But don’t be afraid to admit your ignorance. Being completely honest about your level of knowledge gives you freedom to ask questions, and it gets people to talk with you about the subject matter at an appropriate level.

Clarify who’s an expert in what

From the beginning of the project, make it clear that you’re an expert in user experience research and design, your clients are experts in the business needs, and the users are experts in their needs. All three groups must work together throughout the project, each using their expertise to best inform the design.

…don’t be afraid to admit your ignorance. Being completely honest about your level of knowledge gives you freedom to ask questions…

Clarify that you will never become a subject-matter expert

Make it clear that you do not need to become an expert in the subject matter. You need to learn enough to plan and understand the research, but you’ll rely on the clients and users to fill in the gaps in your understanding.

Ask stupid questions

Being honest about your level of knowledge allows you to ask questions as needed without worrying if they seem like “stupid” questions. Don’t be afraid that if you ask questions, people will think that you didn’t understand the material the first time around.

Don’t be afraid to be wrong

As you conduct research, you make assumptions, and some of those may be wrong. Make it clear that your findings are a work in progress, you may be wrong occasionally and that you welcome feedback. You are working with the clients and the users to understand and you will revise your findings and recommendations as needed.

Do subject research before user research

Learn as much as you can about the subject matter, the business needs, the users, and their tasks before conducting user research. You need background knowledge to plan the research and to understand what people are talking about and showing you during the sessions. It’s often best to learn about the subject matter in the following small steps to go from a high-level overview to more detailed information. Each step takes you gradually into the subject matter, building on previous knowledge, rather than drowning you in information overload.

Conduct some initial research

Before the project kickoff meeting, it’s helpful to examine online references, client documentation, training and support materials, and to talk with subject matter experts. At first this reference material may be difficult to understand, but it will make more sense and be more useful later in the project. So don’t forget to read it again after you’ve done your stakeholder or user research sessions.

Get a high-level overview at the kickoff meeting

Kickoff meetings usually give a very high-level overview of the project and the subject matter. This is the time to ask general questions about the business, the users, and the system involved in the project. With the large number of people attending and the short time frame, it’s not the time to get too detailed.

Get a demo of the system

Whether it’s a website, application or a physical product, it’s best to become familiar with the system before you conduct the user research. If it’s a website, you can go through it yourself. If it’s a more complex application, it’s better to have someone walk you through a demonstration. Gaining familiarity now will make it easier to understand what you observe later during the research sessions.

Play around with the system yourself

There’s no better way to get to know a system than by trying it out. After a guided demonstration, get access to the system and play around with it.

Conduct stakeholder interviews

Stakeholders are your best source of initial information about the business needs, users, the subject matter, and the system. These are often your clients and other subject matter experts working on the project team.

There’s no better way to get to know a system than by trying it out.

Stakeholder interviews can be conducted as a group working session, but individual interviews are usually more helpful. With a group of stakeholders, there are too many people in the room with the same level of experience and knowledge, making it easy for them to slip back into organizational jargon instead of speaking down to your level of knowledge. In individual interviews, people are more likely to be conscious of your level of understanding and adjust the discussion accordingly.

Individual interviews take longer than one group session, but you benefit from the repetition of multiple interviews. It also gives you time to reassess your understanding after each interview and make changes for the following sessions.

Set the participants’ expectations

Regardless of how much you know about the users and their tasks, conduct yourself as if you’re a beginner. Remind the participants that you’re not familiar with their domain, their tasks, their company structure, or their terminology. Ask them to talk with you as if you were a beginner and take you through their process step by step. Stop them if they get too far above your level or if they revert back to using jargon or unfamiliar concepts.

Gain understanding through the user research

You can learn a lot before the user research, but it isn’t until you begin observing and talking with users that you really understand the subject matter:

Discuss tasks before observing them

Before participants begin performing their tasks, ask them to give you an overview of what they will be doing and how the tasks fit into the larger work process. Having this context up front will help you better understand what you observe during the task.

Learn by repetition

You normally observe several participants from each user group to see patterns in their behavior and hear comments that indicate common characteristics, problems and needs. The repetition of hearing the same information and seeing the same tasks performed by multiple participants is especially helpful for understanding complex subjects. Because it takes a few sessions to develop this understanding, be sure to include enough participants from each user group to learn through repetition.

Record everything and type up your notes

Recordings allow you to review sessions a second time, when you can focus on the information and pick up things you might have missed. During a user research session, your attention is divided between listening and observing, taking notes, thinking of the next question to ask, and maintaining social norms of politely listening to the participant.

The repetition of hearing the same information and seeing the same tasks performed by multiple participants is especially helpful for understanding complex subjects.

Reassess between sessions

It’s helpful to take off a few days in the middle of your research sessions to review what you’ve learned so far and to make any necessary adjustments. Reflect on what you’ve heard, how well the research is going, and whether to make changes to the study, such as additional questions or actions to observe.

Confirm your understanding

Inevitably, additional questions come up after the research is over. You don’t know what you don’t know until you begin analyzing your notes. That’s when you find holes in your knowledge, concepts you don’t understand, and questions you wished you had asked.

Follow up as needed

Ask your clients, the stakeholders and the users follow-up questions to clarify and confirm your understanding. Most people don’t mind, and even appreciate, answering additional questions. If necessary, you can go back to the users and observe certain tasks again.

Partner with an expert

Because technology sometimes limits what’s possible, it’s important to provide realistic recommendations. You don’t always know enough about the technology to determine this on your own. That’s why it’s helpful to have a trusted technology expert review your recommendations to alert you to those that might not be feasible. A technology expert is also helpful to defend your recommendations against those who may incorrectly say that they are not possible.

Get feedback on your findings and recommendations

Remind your clients that you want their feedback on the user research findings and recommendations. Remind them again that the findings and recommendations are not set in stone. There may be errors in your understanding and you welcome their feedback in order to make corrections. This is a team effort and you want their collaboration and input on the findings and recommendations.

Now go out and learn the subject matter.

Jim Ross

Jim has spent most of the 21st Century researching and designing intuitive and satisfying user experiences. As a design research consultant, he has helped such companies as Bank of America, Bloomberg, Comcast, Ford Motor Company, NBC Universal, Oppenheimer Funds, Novartis, Rite Aid, Vanguard, and Wyeth Pharmaceuticals. As a User-Centered Designer at JPMorgan Chase, he led the design of large intranet sites, Web sites, and Web applications. Jim has a Masters of Science degree in Human-Computer Interaction from DePaul University.

5 comments on this article

  1. Pingback: Johnny Holland Mag: Learning the Subject Matter: As a user researcher, I’m not proud to admit tha… #UX #IA #IxD | UXWeb.info

  2. Hi Jim,

    Loved the article, especially because I work in one of the big, specialised area of bioscience.
    Almost all of my “clients” are actually my colleagues, and they are generally either computer science / software dev / informatics people, or they are molecular biologists. I am neither!

    The point that one should “Clarify that you will never become a subject-matter expert” is an good one. We just need to know enough to communicate effectively and to be able to make good design decisions.

    That cuts both ways, of course – I’ve found that it is important, too, to explain is plain language what it is I do, and what I am trying to achieve. Jeff Gothelf has had some very incisive things to say about that recently (http://www.alistapart.com/articles/demystifying-design/).

    To add to what you have said, my experience (and that of at least one of my colleagues, who works mainly on UI design) has been that sometimes, being in a position to ask those “stupid” questions is an advantage. Although I have a scientific background, my understanding of the field in which I work now (molecular biology) is rather superficial, but sometimes, that has meant that I do see the wood for the trees, and can pick out issues that are just basic design faults, without having them “masked” by the scientific content.

    Also, something useful that I’ve observed is that scientists often do a lot of storytelling. They frequently work or collaborate with scientists from a different domain (a biochemist and a geneticist can speak different languages!), and to deal with the [scientific] communication issues they might face, they can use stories to involve and engage one another.

    I wrote a bit about this earlier in the year: http://ebiinterfaces.wordpress.com/2011/06/19/science-stories-and-better-design/

    I think we can use this to our advantage. Just as you say, asking someone to explain things to us as though we were a beginner is very useful, and this is not much different. If I can get a scientist (or a software developer – they make up many of my colleagues) to tell me a story about what I am looking at, involving characters, goals, narrative, etc, then I can really work on that.

    That is something that I would love to have the time and resources to explore in more depth but, hey…

    Anyway, thanks again for sharing your experience.

  3. Pingback: New article: Learning the Subject Matter | Another UX Guy

  4. rose on

    please help me to find the answer why do we need to budget the subject matters in teaching?

  5. rose on

    i need it now the answers please…. I’m begging.