8. User Research

Estimated time to read: 31 minutes

Even if you belong to the group of users, who will use the app, even if you share the same problem, your app is addressing and trying to solve. You are not the user. Period. And if you know one user, you know one user, and you are able to develop an app addressing the needs of this single user. However, you will not develop an app for one user only.

The goal of user research is to

• understand the problem to be solved
• emphasize and understand the users
• know the context of the application

To do so, there exist different research methods, see A Guide to Using User-Experience Research Methods

In this module you will follow the following process with the goal to define a good minimum viable product (see MVP):

graph LR
  A[Start] --> B[stakeholders] --> C[problem and context] --> D[classes of users] -->E[hypothesis] --> F[interview questions];
  D --> G[persona];
  F --> G;
  C --> H[scenarios];
  F --> H;
  G --> H;

This will be the base to define the requirements, as described in the next chapter.

See also Stefan Zander on User Research. The article Understanding User Needs: A Guide and Some Tips to Conducting Effective UX Research gives a good overview of some ideas addressed in this chapter.

8.1 Stakeholders

Scrum.org defines stakeholders as "Anyone who is impacted by the outcome of the product and is interested in its success is considered a stakeholder.

Examples of a Scrum Team’s stakeholders may include:

• Customers - users and buyers of the product
• Internal stakeholders - company management and other organizations such as Human Resources/Talent Management, compliance, finance, etc.
• Partners - suppliers, vendors and other business partners
• Influencers - external influencers such as trade organizations, media or industry analysts

Engaging with stakeholders is central to the success of any kind of product development. Only they can provide the feedback necessary to ensure that the product satisfies their needs and expectations."

Make sure, you do not miss a stakeholder.

8.2 User Research Methods

You either have an idea for an app or you are hired to develop or improve an app. Whatever it is, write down your first understanding of the problem and as much as you know of the context.

Whatever the stakeholders say, they want or need. Don't take it at it seems.

You need to know your users and their surrounding system, to be able to develop a valuable product.

User research is not something, you do once at the beginning of a new product. It is iterative, as the development of the product itself. Hence, depending on the phase of your current release, you will use different methods

8.2.1 Context Research

To understand the problem and the context it is good to observe, how people solve the problem now. This process is known as shadowing. You need to understand the problem and the context, e.g.

• veterinary wants to document her examination of a dog
• she will wear gloves
• the dog might walk on a tablet
• it might be noisy
• she might examine the dog at its home and be offline
• she has an assistant entering data into a desktop pc
• she has a praxis management system that offers more functions, than she knows
• ...?
• Forestry workers want to manage the tree population digitally.
• their hands might be larger than yours
• it might rain
• they might be offline
• ...?
• a calendar app should improve your productivity
• you want to use the same calendar on different devices
• you want to import external entries from another system
• you want to define regular preparation of labs
• you want to share a party event
• blind people should be able to use the app
• the calendar should be used by different cultures
  • colors are symbolic and different
  • letter sizes differ
  • right to left
  • ....
• ...
• your intelligent fridge
• ???

Whatever the user tells you it is only a selected subset of the information needed to understand the problem. The differences increase if you do not know the field, the domain, e.g. hospital, finances, ... Shadowing is a method of the wider field of field studies.

"A field study is a type of context research that takes place in the user's natural environment (sometimes referred to as in situ, Latin for "in place") as opposed to a lab or an orchestrated setting."¹

• Observing users in real scenarios will provide you with specific data that directly applies to your audience.
• The context in which people do their tasks can reveal things you wouldn’t know to ask about

Some of the following questions might be answered by your observations

• What problem should the app solve?
• How is the problem solved at the moment?
• manually
• different tools, but with dissatisfaction
• ...?
• Who has the problem?
• How often will the app be used?
• Who will use the app how?
• different users?
• surrounding?
• gloves?
• noisy?
• offline?
• ...?

8.3 Users

To know your users is a process and follows some standards. It is not just brainstorming and coming up with some artificial users.

According to your observations think of possible users of your product and how they might be different. What are possible criteria? Do not assume too early, that a criterion is irrelevant to distinguish your users. You might decide this later. At this stage it is better to gather as much information as possible.

E.g., for a tablet app, that should support the documentation of an examination of a dog, the following criteria might be relevant for the veterinarians

• time of examination for each dog: [15 min, 30 min, 45 min]
• detailed report for the insurance: [yes, no]
• has assistance: [0, 1, 2]
• praxis management system: [closed, cloud, readable database]
• preferred way of documentation: [text, visual, as detailed as possible]
• needs
• pain-points
• age: [<30, <50, <70]
• technical affine: [very, little, ...]
• explorative
• motivated
• education
• ...

You see, you might start with the criteria you have in mind, cause you think of features. And that's ok. The criteria at the end of the list are also important, as you might need to give detailed instructions or help on demand or ....

But there might be other users like assistance, maybe the pet owners, who should document symptoms, ...

Create a table with all observed users and the users you can think of and fill in the criteria for them.

You could map this table to points in an n-dimensional vector space, where n is the number of criteria. Now you try to define classes of users with similarities, i.e. users with a small distance are in one class. Look at the users of one class and label them, e.g.

• expert veterinaries or veterinaries of a clinic who will examine valuable dogs like assistant dogs or drug dogs
• veterinaries who work on their own in a small practice
• ...

Try to identify representative users for each class of users.

You will not fulfill all requirements and ideas mentioned by any user, you need to validate and prioritize them. Otherwise you might end up with something like

from Dr. Keith Andrews HCI, Lecture Notes 2017, IICM, Graz University of Technology.

Hence, try to pick non-average users, maybe even extreme users. Schedule interviews with those users and prepare these interviews with the following steps.

8.3.1 Semi-Structured Interviews

We will perform semi-structured interviews. Semi-structured interviews have common questions and a good flow of questions and are flexibel to go into more depth as the interview evolves or if something comes up, you did not have in mind.

In semi-structured interviews, hypotheses are used to make specific predictions about what the research outcomes might be. These predictions guide the interview process and help focus the data collection on answering relevant questions.

Hypotheses are typically formulated based on the following sources

• Existing literature: Insights from previous studies or theoretical frameworks that suggest possible outcomes.
• Theoretical considerations: Ideas based on concepts or models that guide your research.
• Observations: Initial findings or patterns noticed in prior research or informal user testing.
• Previous research results: Data and outcomes from earlier studies that provide a basis for your predictions.

When formulating your hypothesis, it’s essential to identify the key variables involved in the research. These include

• Independent variables: The factors you manipulate or categorize to observe their effects (e.g., the number of steps in a process, or the presence of a certain feature).
• Dependent variables: The outcomes or responses that change as a result of the independent variables (e.g., user satisfaction, task completion rate).
• Control variables: Factors that remain constant throughout the research to avoid influencing the results (e.g., the device used for testing, or the environment in which the app is tested).

A clear hypothesis will predict how the independent variable influences the dependent variable. For example, "Increasing the number of training modules will improve the user’s ability to navigate the app more efficiently" is a clear prediction about the relationship between training (independent variable) and navigation ability (dependent variable).

The hypothesis should be specific and testable. This means you need to craft a hypothesis that can be supported or disproven based on your data. For example, “Users will avoid complex features that require more than three steps” is a testable hypothesis. It clearly predicts a relationship between the complexity of features (independent variable) and their usage (dependent variable).

Hypotheses play a critical role in shaping your research by guiding the right questions and ensuring the focus remains on answering relevant user experience concerns. Here’s why they are important:

• Guiding the Right Questions: Hypotheses help you pose meaningful questions to understand user behavior, app usage, and design effectiveness. For instance, you might want to learn whether users avoid a feature because it is too complex or if it is due to a lack of clarity in the user interface. A hypothesis such as "Users avoid features requiring more than four steps" will help you focus your research on verifying whether this assumption holds true in the context of your app.
• Understanding Context: Hypotheses also help you better understand the situational context in which an application is used. For example, you might hypothesize, "Users will prefer voice control over manual interaction when using the app in noisy environments." Testing this hypothesis would give you insights into how external factors (such as noise) impact the usability of your app.
• Validating or Falsifying Observations: If you’ve made some initial observations—like noticing that users tend to skip certain features—hypotheses help you formally test these observations. For example, you might hypothesize, “Users avoid this feature because they find it difficult to use.” You can then test this by observing their actions or asking them directly during interviews.
• Testing Theories: Hypotheses allow you to test theories derived from your observations. For instance, if users consistently seem to struggle with a certain feature, you may hypothesize, "The complexity of this feature prevents users from completing their tasks successfully." You can then test this hypothesis through user interviews or usability testing.

See also User Research – The Importance of Hypotheses .

graph LR
  A[users, problem and context] --> B[hypothesis] --> C[interview questions];

Example from Prof. Dr. Nazemi

• Research Question: What impact does the user interface of a web application have on the efficiency of documenting patient medical histories?
• Hypothesis: A user-friendly web application for documenting patient medical histories improves the efficiency of healthcare professionals' work.
• Questions:
  • Can you describe your experiences with the current web application used for documenting patient medical histories? Which aspects do you find particularly helpful or hindering during use?
  • How important is the user-friendliness of the web application for your daily work, and how does it affect your workflow?
  • What positive or negative experiences have you had using the web application in terms of the efficiency of your documentation?
  • Can you provide examples of how the web application has impacted your productivity and the quality of your documentation?
  • What features or improvements would you like to see in the web application to make documenting patient medical histories more efficient and easier for you?

In general, you should formulate hypotheses and resulting questions that clearly identify the need for your app. Specifically, what are the shortcomings of the current solutions to the problem? What exactly is the problem you're aiming to solve? Who are your competitors, and what are the weaknesses or limitations of their offerings?

The interview guide consists of

• introduction, warm up
• questions
• anything to add?
• wrap-up and thanks

Moderation should be appreciative and reassuring, ensuring that the person feels as comfortable as possible. Address any concerns proactively to prevent fears from arising. Emphasize that their feedback is highly valuable to you and encourage them to share their thoughts throughout the process. Reiterate this point regularly to create a supportive environment.

8.3.1.1 Starting and Ending an Interview: Best Practices

• Starting the Interview
  • Clarify Participants' Relevance: If you haven’t already invited a specific person, quickly assess if their involvement is relevant to the project.
  • Introduce the Team: Introduce everyone present, stating their roles and names (without titles) in a friendly, non-intimidating manner.
  • State the Goal: Briefly explain the purpose of the interview. Emphasize that you are not testing the participant, but rather testing your idea or product. Everything the user says or discovers is valuable.
  • Explain the Duration and Process: Let the participant know how long the interview will take and outline the process.
  • Voluntary Participation: Make it clear that participation is voluntary, and they can stop the interview or skip any questions at any time without consequences.
  • Data Handling: Explain how their data will be handled (who will have access, anonymization procedures).
  • Consent: If necessary, ask for a signature for consent or a declaration.
  • Collect Demographic Information: If the participant’s background isn’t known, briefly collect relevant data (e.g., profession, experience).
  • Set the Atmosphere: Ensure the environment is comfortable and free from distractions (e.g., ask for phones to be turned off).
• Ending the Interview
  • Invite Additional Input: After asking all prepared questions and follow-ups, invite the participant to share anything else that might be important.
  • Express Gratitude: Thank the participant enthusiastically.

By following this structure, you create a clear, respectful, and engaging environment that encourages meaningful feedback while maintaining a positive and professional tone throughout the interview.

8.3.1.2 Good questions to ask

Organize your questions based on the hypotheses you’ve formulated, integrating the following general questions where appropriate. Aim to create a natural flow that encourages the user to share valuable insights and prompts them to open up and engage in conversation.

• Walk me through your day.
• What do you spend most of your time on? (task priority)
• Describe the problem of 80% of the cases
  • don't get lost in special cases
• What things waste your time?
• What are you angry about?
• What makes a good work day? A bad one?
• If you had a wish?
• What would change, if the wish became true? Who would notice it how?
• Use scaling (on a scale from 0..10 ...) or ordering (top 3 features, put into an order ...) questions.
• Ask for commitment/investment -- if you just ask, do you like to have, you get a yes.

Follow the funnel technique and start broad and get more specific later on. The interview is about research and to learn something unexpected open questions are the key to success.

Document and summarize your findings of your user research.

8.3.2 Persona

Take everything you learned so far and describe 2 to 5 personas for your product.

A persona is based on data (user research) and the team's understanding of the target audience. While commonly used in software development, personas are also valuable in various customer-focused projects. For example, refer to the template provided by the hda Persona.

There are different templates for personas. Take the one, that suits you best. It should have

• name
• picture
• age
• description of physical and/or Psychological traits
• education, training, experience, skills, competencies
• hobbies, interests, preferences, dislikes, habits
• goals
• goals, pain-points and needs
  • What problems are users trying to solve, and what are their expectations of the product?
• context
  • Description of the usage context, i.e., the environment in which users interact with the product or service.
  • Examination of external factors that may influence user behavior and decision-making (e.g., technical, social, or physical surroundings).

The persona should be useful to emphasize with the person while designing and developing the product.

8.3.3 Scenario

Now, you may be able to put your persona into a context and describe, how your app might help the user with a specific problem. Here are two different types of scenarios. Choose the one, which suits you best.

The first example is from Scenario Mapping: Design Ideation Using Personas

Debbie is going on a business trip. She needs to book a hotel room that’s affordable and has good reviews. Debbie browses the site to find a hotel for her upcoming trip. She looks closely at the various hotels to find one that meets her needs. She considers price and user ratings heavily as she shops. Debbie selects a hotel and books a room.

And the second example is from The Sophist -- unfortunately, they have removed previously available free material, so I can only provide a link to the general webpage.

"Lina returns home late in the evening from work. On her way, she was shopping and has both hands full of shopping bags. Since it is already dark, the smart home system detects the movements and turns on the outdoor lighting. As Lina approaches the house, the smart home system recognizes her as an authorized person and unlocks the door. Lina only needs to push the door open and can enter the house."