8. User Research

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 Hypothesis

Here are some sample hypotheses:

1. Research Question: What are the health and behavioral benefits of tracking your nutrition through a mobile app?
   Hypothesis: Increasing calorie consumption tracking will result in a decrease in the number of doctor's visits.
2. Research Question: Which travel modalities (airplane, train, boats) have the most delays?
   Hypothesis: Low-cost travel industries are more likely to have delays than premium travel.
3. Research Question: Does a remote work arrangement improve job satisfaction?
   Hypothesis: Employees who have remote working hours will report greater job satisfaction than employees who work in an office with defined hours.

See also User Research – The Importance of Hypotheses .

In addition, you need to formulate hypotheses addressing the need for your app, i.e. what are the flaws of the current way of solving the problem? What are the competitors and what flaws do they have?

8.3.2 Interview

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.

The interview guide consists of

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

Moderation: appreciative, do not let fears arise, person should feel as comfortable as possible, feedback is important for, elaborate on this again and again.

8.3.2.1 Start and end of an interview

Whenever you start an interview, consider the following (order it as you like)

• If you did not invite a special person, ensure as quick as possible, if the person is of interest for the project
• Introduce everyone with their roles in this interview and names, without a title, and without being intimidating
• Describe the goal of this interview shortly
  • elaborate, you are not testing the person, but your idea, everything the users says or discovers is very valueable
• Duration and process
• Voluntary interview, option to end the interview or decline to answer any question at any time, without any consequence.
• Data handling (who has access, anonymized)
• Signature for declaration if needed
• Collect data on the test person, if not known (briefly!)
• Pleasant atmosphere
• Phone off, no disturbance

After you asked your prepared questions and follow-ups, make sure to ask the users, if they want to add something, are interested in beta testing etc. and thank them enthusiastically.

• Is there anything else that could be important for us?
• Would you be interested in staying up to date? Ask for contact data.
• I am truly grateful for the time you have invested and the invaluable insights you have shared on our product. Your expertise and feedback have been incredibly helpful, and I am honored that you took the time to provide such thoughtful perspectives.

8.3.2.2 Good questions to ask

• 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.3 Persona

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

There are different templates for personas. Take the one, that suits you best. It should have a picture and contain pain-points and needs, and your user criteria. The persona should be useful to emphasize with the person while designing and developing the product.

8.3.4 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: Szenarien

"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."