A Beg­inner’s Guide to Finding User Needs

Jan Dittrich


Creative Commons License
A Beginner’s Guide to Finding User Needs by Jan Dittrich licensed under a Creative Commons Attribution 4.0 International License. Some images may have other licenses (like CC-BY-SA).



Supplemental information, versions for ebook-readers and co-documentation templates can be found at http://urbook.fordes.de

Suggestions and Feedback

This book is free/libre, if you help to improve it, it helps all other fellow readers.

To point out mistakes you can:


Products should not only be usable but also useful. This means they satisfy a need of the people using them. But how do you know what is useful for users of future products? It helps to get to know users’ motivations, activities, and problems by gathering data and finding patterns. This text teaches methods for doing this.

I found it hard to start with doing research on user needs because some approaches demanded a lot of theoretical knowledge, while others assumed a large budget for research. I try to keep the barriers to doing research low by prioritizing methods that…

I provide examples to make it easy to see how methods are used. More useful than an abstract definition of methods like “asking open questions” or “clustering themes” is to see how these are put into action when doing research.

This text describes methods and tricks of the trade. They worked for me and I saw them work for others, too. However, they are not a list of rules that guarantee success if followed. Indeed, doing research by always following a prescribed way, no matter what, will lead to useless results since you could not react to whatever new things you find out. See this book as a travel guide 1, written by a person who has already traveled a bit. As in a travel guide, it can be helpful to follow the suggestions. But if the path I suggest can’t be walked, just go around the obstacle. If people give you strange looks, maybe your current situation is one I have yet to experience and where my advice is not helpful. Feel free to adapt to what makes sense in your situation.

Talking about adapting to your needs: This book is open source, which means it is both free-as-in-freedom and free-as-in-free-beer. This means you can not only read it for free, but also change and adapt it (Details are in the license) I hope this helps to spread the knowledge and to improve this book together. Let me know of errors you find in it and tell me and others how the book is useful to you.

User need research helps you to create more useful products

Without research, assumptions about the user’s activities with current and to-be-created products are often shallow and do not involve the user’s context. They focus on some features being used, but not much more.

Let’s say I want to design an app that eases collecting and organizing knowledge snippets and their references to books and websites. The app should be targeted at PhD students. This is surely a great thing to work on—but without research, I would just have some disjointed ideas in my head: It should be more visual than other, similar software and have an efficient add-new-reference function, based on scanning the books barcode, because typing is not much fun… My assumptions about the context of use are very vague: The PhD students would use the application because they need to manage references.

Instead, when you researched users’ needs, you can easily think of what is important to users in rich and detailed ways, considering intertwined activities, motivations and problems of users. This will be based on data. Furthermore, it will be structured by common patterns of the users’ behavior. Analyzing these patterns makes it easier to see where your research has gaps or potential. It also helps to communicate what you learned to others: You can talk about the patterns and give concrete examples.

In my research on collecting and organizing references with some students and professors I found several patterns which can guide my ideas for future design. I might consider that disciplines have very different ways of working. Thus, it could make sense to focus to natural scientists, whose literature is mostly digital, or on liberal arts, who are more paper based. Deciding this would give the project focus. It might need more research, though. Nevertheless, even the mathematicians or physicists do not work only digitally: Paper still plays a large role in their knowledge work. Users from every discipline used paper and computer at the same time. They scribbled things down in front of the screen and alternated between printouts and digital representations. Should my product try to get rid of paper by simulating the paper-based parts digitally? Or assume strength in the differences and just bridge the gap between screen and physical world? And we have not even touched finding and using review works, writing a publication, collaborating with other researchers… all this leading to more ideas that can be discarded, build upon or fed back in further research.

User research will help you to get a data-based, rich and conveyable image of the users motivations, activities and problems. This does help to tackle the right problems and to get new ideas of what could help the users. Without user research, you may also have assumptions about the user, but they can easily be wrong and will often be simplistic.

User need research is an iterative process, not a linear one

The process that I describe in this book may seem to be divided into clear steps, each step its own chapter: First you prepare your research, then you gather data, you analyze it, and, at the end, you communicate the results.

But in contrast to what the linear structure of this book suggests, it is very useful to switch between steps and also go back to previous ones:

User need research is an iterative process. Instead of doing all steps once, one after another, you can go back and forth. This allows using insights from later steps (like analysis) to shape earlier steps (like data gathering).

User need research is most useful before the product is being built

User needs should be researched in early project stages. It is less useful when a lot of time and money has been spent already on building a particular product.

Here are some scenarios in which user need research makes sense:

There is a broad topic or problem space, but very little is known yet. Not being focused on a particular product gives you a lot of freedom. Such projects are not very common, though. A possible task would be to “find out about people using libraries” or even doing research on “finding and working with information in media”

There is an idea for a product or a service. You want to find out user motivations, activities and problems that are important to consider when building a product or service. This is the scenario in which I use user need research most often. An example task is “The library wants to create an app for creating bibliographies. They want to find out what they need to consider for making it a useful product”

A product is to be improved or changed. If a substantial overhaul is planned, it makes sense to observe how the product is used to find out where user needs are unmet. A task could be: “The library already provides an app for creating bibliographies since several years. But students complain about it being useless and hard to use. Now, you should find out about the users to help the library to see how version 2.0 should be different.”

In all these examples, the outcome is not set yet: Your findings could make a difference and shape the outcome. But if the decisions are already made and your results won’t make a difference, don’t do the research: It will be a frustrating experience if even the most interesting results won’t change the project’s determined course.

Our inquiry concerns the user, not our (future) product

You may be very motivated to start designing your future product now and research based on the product features you have in mind, asking for preferences and evaluate your product ideas with the users. But if you focus on the product now, your research findings will be tied that specific product—which may or may not be useful for your users. If you instead focus on the user, your findings will be independent of a particular product implementation.

This idea can to be hard to grasp. One reason is that people assume that we ask questions like:

However, I don’t do this: It would not tell me much about the how and why of their actions—only that they want something.

Sometimes, user need research is also confused with usability testing. In usability testing, you test a product to improve it. Usability testing is not about finding user needs that exists independent of that product.

Paradoxically, we need to let go of our focus on products to be able to understand the users and to develop products that users need.

Should you do it?

Before you get started with a reserach project there is a first and very important choice to make: Should you actually work do the research?

There might be good reasons not to, actually. The products of the tech industry to their fair share of harm be it undermining democratic processes, using limited ressources to build more and more devices that need to be replaced all too soon and drive poor people into badly paid gig work while amassing profits for their shareholders.

But even if you do not work for a big tech company you should be aware that the results of your reseach can have real consequences for real people. Here, it is important to be aware who will be affected when people act upon your research. Some people might not match your or the clients idea of ‘users’ and thus are often excluded and not heard. Or the research would extract information from them, but the outcome of the research will be worsen their situation.

These would all be good reasons to not work on a research project.

Prepare your research

Create a user-focused how-and-why question based on the initial idea for the project

It can help a lot to have a guiding question when you start your research. This question should relate to how and why your (potential) users do what they do. You might already have an idea for a future service, product or feature. You can use such ideas as a starting point for creating a useful, user-focused research question. Here is how you do this:

  1. Take your inital ideas for a future market, product or features
  2. Ask yourself why the product idea would be good for an activity people do.
  3. Take the activity from 2. and Ask, how and why people do this. The outcome can be used as research question.

Here is an example:

  1. The initial idea is “build a learning platform for university students” 2 The meaningful activity connected to it can be “using digital media to learn better for university”
  • Asking how and why I come to “How and why do students use computers to learn better for university?”

I then refined the question a bit, since “to learn better” is often understood as remembering facts or passing exams. Also, “use computers” sounded like I am not interested e.g. in smartphones or use of social networks. In the end, I used “How and why do students use digital media related to their studies”.

The research question is a help for you to ask more focused questions and to communicate your aims. It does not need to be the one true question. Thus, it can also be refined later after you gained a better understanding of the matter.

Find participants

In user research you want to find out what our users do and how and why they do it. If you know this, you can design our products accordingly.

To be able to do research on the “how” and “why” of users’ work, you need to find people who would like to answer your questions and would show you what they do. These people are our (research) participants.

Potential participants do the activity that is in your research question

Research participants should be able to talk about what they do and demonstrate it. Because of this, it makes sense to focus on activities when you recruit.

Demographics are not very useful: “30-40-year-old male, making more than $50k/year and being interested in technology” does not relate much to motivations, activities and problems of users. Instead of using demographics, base your recruiting on the activity that is part of your research question:

I don’t exclude the roles (“Student”, “Owner of a small business”), but I focus on the activities first. In the question “How and why do small business owners keep track of their bills”, the essential part is keeping track of bills. This is also what people can tell you about and what they can demonstrate. If I talk to an owner of a small business and they do not take care of the bills themselves, I would ask why they do so and who is doing it instead—and then ask whoever is doing the “keeping track of bills”-activity if they want to participate.

Let potential participants know about your research and why they should take part

There are two ways to get participants:

  1. The easy way is paying a recruiting agency. They will get your participants according to criteria you give them.
  2. The harder way is doing the recruiting yourself, and this is what I will be explaining.

Recruiting yourself, obviously, might be needed since you do not have the budget to pay an agency. Sometimes it can also be easier for you to get specific participants than for the agency.

Two conditions need to be satisfied for people to take part in your research:

  1. They know about the possibility of participating in the study
  2. they are motivated to actually participate

It is motivating for potential participants if the research improves their life: A shopkeeper will likely be interested if you work on making it easier to keep track of bills, neighbors will be motivated to help if you try to make living in the neighborhood better.

Incentives, like money or vouchers, are a simple, but effective motivation for participants. If you have the funds and, particularly, if your project will earn you (or your employer) money, you should pay for your participants’ time. If your funds are small and people like to support you and your cause, you could also offer something that people like, but would usually not “just” buy, e.g. really good chocolate or a voucher for a nice local restaurant. Such things are far more valued than the money they cost.

When you know what you can offer to potential participants, you can write down what participants can expect if they participate. This includes:

You can use this information to create paper notes or posts to social media—This is how it could look like as a slightly formal note for a notice board at university:

Are you using the university’s library?

The university library would like to improve the LibApp to support you better in using our library and digital services. Therefore, we would like to gather some insights into the way you work in the library and with our services. If you would like to support us, someone from our team ask you some questions and look over your shoulder while you work. This would take approximately 1h and take place in the library or some other place where you use our services from. All participants get a $10 voucher for the university’s cafeteria. If you would like to participate (or have further questions) please write an email to jan.dittrich@example.com

In some cases, finding participants is easy, because participants are motivated and you can easily reach out to them, as in this example:

If you have the task to find out how the library’s services could be improved, you can reach out to potential participants by using the library’s notice board. You can also ask the “how-to-use-the-library” trainers to mention the project. Students might even be motivated enough to just join out of interest and because they want to contribute to improving their own life—but it is only fair if the library pays them for their time (and it might also help to represent students who struggle with money and would otherwise work in the time).

In above example, it was easy to reach out to participants because you were already close to them, spatially as well as socially. But sometimes, field access is more difficult than just putting up some notes. Often, this is because you actually don’t know who or where possible participants can be found, and so you can’t ask them. This means you need to get to them in a step-by-step process. The following example outlines this:

You want to find out how people use freely available data on air pollution which is published by cities. But you don’t know anyone who does work with such data. You give it a try and post about your research project on Facebook. You are lucky, and a friend of yours happens to know that a local “hackspace” is hosting a bi-weekly “data hackers meeting”. You click on the link your friend send you and read the linked page. You find the meeting organizer’s email address on the sub-page with the “data hackers meeting” details. You write an email and ask if you could join the meeting and introduce your project. In parallel, you have also searched the web, and by trying “[next largest city] open data” you found out that, some weeks ago, the infrastructure department of the city has given an award to the best open data project using data the about the city. You could reach out to the staff member who awarded the price. They might be able to refer you to some people who are interested in the topic, since they needed to get in contact with them when advertising the competition for the award.

In the scenario above, I described a step-by-step process of reaching out: In each step, you try to be referred to a next person who is more knowledgeable and familiar with the people you want to do research with. You do this, until you are referred to possible participants.

At each step, you can learn about how to approach the next: If your friend refers you to a meeting of data hackers, that friend can probably also tell you if you should behave in a particular way if you are going there. For the hacker meeting, it might make sense to NOT be wearing a suit. In other places, the smart clothes might be essential.

Some people who might help you are in a core position to regulate access to potential participants. The ethnographic jargon for them is “Gatekeepers”. They can decide to help you and let you through the metaphorical “gate” to your research field and your participants—or they can hinder your access, if they have reasons to do so. In the example above, a gatekeeper could be the person who runs the “data hackers”-meetup or the person being responsible for the city’s “open data”-initiative.

If you have found people who like to be your research participants, you can ask them if they know others who might like to participate. It works like the step-by-step recruiting process, but instead of moving towards your participants, you now can go from one to another by being referred.

In any case, it is useful to consider different ways to get to your participants. If one way fails (e.g. friends of friends), you may be successful in another (e.g. writing a mail to a “gatekeeper”). In case several approaches work, you get more potential participants. But even more important is that you now have a more diverse set of people, which leads to richer results.

Make compromises, if needed

Especially if you are short on money and/or time, you may need to compromise and do research with participants that do not match your intended users exactly. However, if their motivations, activities and problems are similar, you are still likely to learn from these participants. But if they are similar only in demographics or profession rather than in their activities, your cannot expect meaningful results.

If you design an app for people to create bibliographies and you can only get some bachelor’s and master’s students, but no professors, your results will still reveal a lot about the processes of creating bibliographies. The student’s motivation is probably writing final term papers and the professors would like to write journal papers. This is a possible difference — as long as you aware of it, you are probably fine. But if you want to design a skateboard and the only participants you can get are elderly people who enjoy hiking, you are in trouble (if you find elderly people who enjoy skating, go for it).

A small number of participants is fine

There are no clear-cut rules of how many participants are enough. However, most of my projects have between 3 and 8 participants. If I really need to be sure I would do research with 10, but that is about the limit I can manage on my own.

You may think that conducting user research with more participants is generally better; you just could shorten each session, ask fewer questions and skip observing the participants. But you need time with each participant if you want to find out about the “how” and “why” of the participants’ work. Several sessions in hurry will lead to less useful results than research with one participant done right.

Nevertheless, only doing research on very few users will restrict the variance of data — like noticing that there may be several ways to do something. As well, you might not see which patterns are consistent among several people and which vary—which would certainly be impossible if you only had one or two participants. However, despite the constraints of such small samples they can still lead the helpful insights.

When estimating how many participants you need, consider how much time or money you can spend on doing the research. Each additional participant gives you additional data and a broader view on your possible users. However, each research session needs time do and adds to the amount of data to be analyzed.

An efficient way of involving the “right” number of participants is doing your research iteratively: start with two or three participants and analyze the data (how this is done is described in the section on Analyzing Data)

Take a look at the (preliminary) findings: If the results seem clear and consistent, you may do research with few additional participants to refine and check and to explore details — or, if time is up, leave it the way it is.

If preliminary findings are unclear or contradictory, you may need to involve more participants.

Reasons for the such unsatisfactory results could be:

In all these cases you can involve more participants — but before you do, try to check if you…

If you come from research based on measurements and statistics, it can be unusual to have few participants and to refine your research iteratively. In user need research we focus on collecting rich data and making sense of it by asking new questions and refining interpretations. To be able to do this we spend our resources on working with data from a few participants in depth.

Prepare the research session

The “Research session” is your time with the participant in which you listen to them and observe their activities. If you are prepared, it helps you to focus on the tasks at hand.

Think of possible topics and questions for your research

Before the research session, I try to get an overview of what I want to explore. I usually structure this along three topics: The Motivations, Activities and Problems of the participants.

These topics are relevant for design, and they can be easily remembered even in the midst of research: Three points are few and you can use the mnemonic M-A-P: Motivations, Activities, Problems.

Motivations — what does the participant want to achieve? What is important for them? Motivations can give you context to what the participant’s do.

Activities — what does the participant do? How do they do it? What are solutions, processes, “hacks” do they use? Activities are the core part of research: This is what can be observed and where things happen.

Problems — what is in the way of the participant getting to their goals? Problems can make you and the participant aware of motivations and activities that are so familiar, that you don’t think of them—until something gets in the way.

List the topics you want to explore and structure them in a way that is meaningful to you. This list of topics can then be used to create a cheat sheet for the research session.

Write a cheat sheet to use in the research session

A cheat sheet is a little memory aid that you can take with you when you collect data.

What goes into such a sheet? The biggest part will be topics you want to explore and the questions that you want to ask for this.

User Code:_______ , Date: ________

  • Tell the reason for research: Improving communication with clients for freelancing designers.
  • Tell how the research session will be (asking, listening, observing; 30-60min)
  • Ask to read consent form and sign if OK


  • Is there a current project or task?
  • [explore task]

Initial task/handover:

  • How do they get in contact with a client

  • How is information being exchanged?

  • Getting to know each other? Trust?

  • Process diagram: Getting a project started …

When you write the questions on the cheat sheet, start with the general topics and progress towards more specific ones. This is the order that makes sense in the course of a research session. Nevertheless, that order is only a helpful guess. You will usually deviate a bit (or a lot) from your cheat sheet.

Often, I include some kind of checklist on the top, especially if there are legal matters involved, such as signing a consent form. Thus, I can tick off what we already dealt with and immediately see if I forgot something.

You may wonder about the “User Code” in the example above. When I do research, every participant gets an identification code that can be used instead of their name (like “User2”). Latest when you publish the research, you do want to retract all names and other identifying information. Using such code, you can identify participants without their names. This is useful to keep the participant’s privacy, particularly if you share or discuss preliminary results. If you need to retain the names you can keep a separate list, so you can convert the codes back. An alternative to codes is to ask participants how they want to appear in the (published) research, so they can choose if they want their legal name, another name or a code be used to represent them.

The cheat sheet is a tool to support you during the interview and help you along when your mind goes blank for a moment. It is not for ensuring that you ask all questions in the same way and in the same order. Instead of controlling the situation, user need research emphasizes the exploring the situation. If the participant does or tells something which is new to you, use it to learn and feel free to come up with new questions which are not on the cheat sheet.

Take along tools that help you to record data easily

With a participant talks about new and interesting things you want to be able to remember what was said. Thus, we record the interview — and we will need some equipment for doing that:

Equipment for user research: paper, pen, audio recorder.

You should get to know your equipment before you start the actual data collection. So be sure to know how make a photo and start and stop the audio-recording. Check the audio quality by putting the phone/recorder roughly a meter away from you and saying some sentences in your normal voice. Listen to the recording to test if you can understand what you said.

When your equipment is ready and checked, you can start to collect your data.

Data Gathering

In this chapter, I will show how to gather data on the activities, motivations and problems of your participants. The data is gathered by listening to descriptions and explanations of our participants and by observing them working. The resulting data will be text, photos and diagrams.

Contrary to a common misconception of user need research, your inquiry will not be (directly) about future ideas and design—you are not going to ask “do you think that a [gadget] would help you?”. It is hard to guess if an imagined thing would be great to have in the future. Instead of working with product ideas, you will find out about the how and why of our participant’s activities. This will allow to evaluate your ideas (“do my ideas match what participants consider essential for them?”) and to get inspiration for new ideas (“how can I support this activity?”)

See your participants as competent in what they do: they are experts in their fields and in their daily work. This is contrary to the idea that people “don’t get it” and need to be helped by designers and programmers. Assume that the participants have a reason of doing their work the way they do it and if you wonder about participant’s activities, try to find out what their reasons for these activities are.

Modes of data gathering

Listening and asking questions

A common way to gather data is asking questions and listening to the participant’s answers. Asking questions may seem familiar from questionnaires. However, the use of questions and answers in user needfinding is different. Questionnaires often aimed for short, definitive answers which need to be selected from of a set of possibilities (“on a 4-point-scale: how much do you agree with…”). In user needfinding, you aim for longer answers which are not from a determined set of possible answers. Thus, you are more likely to get rich, story-like descriptions, telling about the user’s motivations, activities and their context. To encourage the participant to give such story-like answers, you often need to ask for descriptions of activities and the reasons for doing them.

“Can you describe me how you decided to use this layout?”


“You said that you need to look that color model up. Why?”

Asking questions and getting answers from a participant is a very versatile tool. It can be done without many resources. Furthermore, you are not tied to a specific place and you can talk about past events as well as future plans.

But because of this, it can happen that you hardly focus on actual experiences and instead talk about abstract events. Observations are thus a good supplement to asking questions and listening, since observations are concerned with actual actions you can see happening at the very moment.


What Participants describe is not always the ideal way to convey the information. Just like a picture can be worth a thousand words, it makes often sense to ask participants to show what they mean and to demonstrate how they work. It can also be easier compared to describing to.

When you observe, you will even notice things your participants would never consider mentioning: It may have gotten second nature for them which tools they use, how they apply these tools to their work and which problems they meet, so they won’t mention it. But you can observe it. You also can gain information about the context, like means of communicating with co-workers or cues in the environment that point out problems—for example quick fixes on devices using tape and cardboard, or added instructions on devices and machines.

It is not needed to have observation as a separate step in the research process. It makes great sense to interweave observation with asking questions and listening. For examples, you can ask for a demonstration instead of a description.

Participant: “So I got this image and now I would try to get a suitable crop for that brochure” Researcher: “Can you show me how you do it?”

Think of yourself as an apprentice of the participant. The participant is the expert who can teach you some of their skills. This means that understanding the user by observing is not a passive process. Like an apprentice, you can and should ask questions.

Ask about reasons: “You drew that object and changed it size, then you deleted it again… what was the reason behind this?” Ask about things you notice in the environment: “Can you tell me what these markings are for?”

Teaching an apprentice is not a theoretical or artificially set up process: The tasks you observe should be tasks the participant is actually doing (and not something set up for you):

Participant: “What should I do now?” You: “What would you do if I would not be here?”

Of course, they should be relevant to your interests as well:

[continuing the conversation above] Participant: “I would either crop this bunch of images or I’d try to find a suitable font for the headlines in this document You: “If the tasks are equally relevant to you, I’d be more interested in watching you choosing the fonts”

Avoid positioning yourself as the expert in the participant’s domain by suggesting procedures and by telling the participant how and why something should be done. Your participants will stop being open about showing you how they work and they usually have a reason for doing what they do.

Observing the user’s work.

Co-Document in diagrams and lists

In co-documentation, the participant and you record the data together by drawing and writing. This can be as simple as asking the participant: “Draw a simple floorplan of your office. Mark what is important to your work and write why”.

Here are some examples of co-documentation results:

Timeline diagram. If the graph goes up, the mood gets better, if it goes down, the participant feels bad, bored or annoyed.
Social space map: The participant is in the center. They draw people (or whatever else they think matters) around them and write the nature of the connection on the arrows.
List with workflow steps.

Having the documentation in front of you and the participant eases improving it directly while it is being created. You, the researcher, can refer to it to ask for elaboration (“Is this the photocopying machine, that you said gets stuck so often?”). Their answer should be added to the documentation. The participant can use the shared documentation to extend already documented things (“One other thing I add is that I can get paper for the xerox here [writes comment on the paper]”).

The fact that researcher and participant need to understand the documentation is a check against unclear terms, references and also just sloppy handwriting. This makes the results often very accessible and useful.

“The line here seems to indicate that you were very happy at the beginning of the project…” Participant: “Yes, I’m looking forward to doing it and there are so many ideas” You: “Can you write this in the diagram, so I can understand it later?” Participant: [Writes as comment in the diagram] Looking forward, Many Ideas: Good

Who does the recording—drawing and/or writing—depends on what is more practical and gives more interesting data. When researching workflows, I write the documentation as a researcher, since participants should be able to demonstrate their tasks directly which is hard when you need to switch between demonstrating and writing all the time. When the participants document a project on a timeline, they draw it directly and I only ask questions.

For some participants, documenting their work by drawing and writing can be a bit unusual. It can help to show a simple example of what the result of a co-documentation can look like. It can also reduce anxiety in drawing related tasks—some people assume they need to produce an artwork. Showing that a rough sketch is fine helps them to get started.

It can be easier for the participant if you provide a template instead of a blank page: This gives a basic structure. Provide fields for name, date, title and space for the participant’s diagram. I also sometimes print a small example in a corner of the template. Templates work very well for chart-like types of diagrams, since the participant can draw on top of elements that are already there, like the diagrams’ axis.

Example template for mood-timeline-diagrams.

Co-Documentation works well in combination with interviewing and observation: You can co-document workflows combined with observing them and you can also go from an interview to co-documenting a specific aspect (“That is interesting! I would like to remember it clearly later on, so I would like to write the steps down with you”) or use a documentation to refer back to in an interview (“You wrote… How does relate to…”) and add further details to it.

Co-documenting via lists, diagrams and drawings may seem unusual in the beginning. But they produce very useful and graspable data by having the researcher and the participant work together. The participant’s active part in documenting and the possibility to see directly what is recorded can empower participants: They are not just passive sources but actively create data.

Start the research session

Explain the research project and methods

When you have found a participant, a place, a time and have your equipment ready, you can start with the research session.

My advice is simple: Be friendly. If you come to their place (which is preferable, since you can observe the actual context) be a nice guest; if they come to your place or you meet in some “neutral space” (which includes online conversations), be a nice host.

Greet the participant and thank for their time:

Hello Lisa, great to meet you. I’m pleased that you could free some time for showing and telling me how you work.

You may sprinkle in a bit of small talk:

Did you have a good start into the day?

Participants should at least roughly know what the research is about. You don’t need to tell about all your questions and topics, but the general topic should be described.

This research helps us to improve the workflow in the design process to design solutions for people who do graphic design.

Make clear that you are here to learn—and not an evaluator of the quality of the participant’s work.

…Therefore, we’d like to get to know how you work. You are an expert in that field, and we’d like to learn from you. This is not some kind of test—when I ask questions, there are no wrong answers.

Although you may have described the time frame and the method already when recruiting the participant, tell again what you are going to do:

We will have a conversation about your work and I’ll be asking some questions. In addition, I’m interested in watching you when you do your work. The whole process will take about an hour.

The participant must know how you record data and who will see it. So tell the Participant:

I’d like to take notes, and, in addition, record audio—if that is OK with you. The audio recording helps me to focus on your work as I don’t need to concentrate as much on writing notes, if I have the recording as backup. Me and a colleague will listen to the audio; we will anonymize and transcribe the data before we share it with the product design team.

If you feel uncomfortable with being recorded at any time, we can pause the recording.

You can cancel the interview at any time if you feel it is needed.

It rarely happened to me that someone did not agree to being recorded. If that happens to you, you can ask if they have any specific worries—possibly you can inform them about that specific aspect, and they might agree when they have additional information.

[Example from an in-house research project] “Audio recording… I’m not sure about this…” “That’s fine with me. Though, may I ask what worries are?” “Hmm…yeah, I don’t like, you know, human resources to get that data”

“I understand your concern. It is fine if you don’t agree but I can assure you that Human Resources is a separate section. We don’t share personal data and what we record today is not accessible to them. Also, all data that leaves my computer or the one of my colleague is being anonymized and we remove all data that points to you as person, including the names, workplace and so on.”

If they don’t agree, just stick with writing notes.

Consider summarizing the information about the research and the use of the participant’s data in a consent form that the user signs. In this case keep the signed form, but hand the participant a copy of the form. Thus, the agreement is clear for both sides. See in the Appendix for an example of such a form.

It goes without saying that it is essential that you follow the agreement. This might be obvious in many cases, but there can be situations in which e.g. the participant is hesistant to answer or looks uncomfortable, possibly because of a question or a request of yours. Prevent such situations. Do not push them if they seem uncomfortable, even if you like to hear their answer. Offer them a way out of such situations, if you unintentionally caused them. You can, for example suggest an alternative task, or say that it is fine not to answer and go to the next question. The wellbeing of the participant is your primary concern.

Start simple

Start with some easy-to-answer questions—like: “Let’s start with some simple questions about your job”. You can ask “What is your job title” and follow up with “How do you describe your job to people who do not know what it is about?”. As well, it might be interesting how experienced the person is: “How long have you been working in your current occupation?” These examples are tied to work related studies—for doing research with university students I tie the questions to their particular context and ask, for example, how long they have been studying so far.

These questions will help you to get to know some context of the participant’s work. But there is another advantage: Such questions are easy to answer. This gets the participants used to answering questions and opening up towards you. After a brief section with these easy-to-answer questions, you can transition to questions that encourage more elaborate answers.

Assure and encourage

Affirm that you listen

You will ask questions aiming for descriptions and longer answers. So you will be listening to the participant most of the time. You probably have some ways to intuitively show that you listen—like nodding with the head or saying “yes” or “mm-mhh”. This is an important way to ensure the participant that their information is listened to and valued.

However, when giving this kind of feedback you should be careful. You could easily skew the answers by indicating that some information is better than other. If you throw in a “yes, great” combined with nodding (as if you prefer what the participant did in comparison to something else) or if you just make a rather unmotivated “mm” and frown (as if what is told does not match your hopes), the participant will get selective about their answers and focus on what you seem to like. Try to keep the reassuring sounds or gestures neutral.

A negative example of feedback would be: “It was great to hear that you say you have some trouble exchanging files by mail!” (Since you may have already thought of a feature that might be helpful in that case)

The participant will try to be a nice person try to make you happy by going on about the problems with files in mails even if sending files per mail is possibly not that bad in the participant’s view. Instead of reassuring the participant using judgments and emotions, focus on the fact that you got information you that helps you:

“That was interesting to hear –”

You could even wrap the information up— “So, you said that…” —and/or refer to an area you like further information about. It will be clear, that you care for the information and listened well—without casting some judgment on what was told.

Make a friendly impression by using body language.

Probably, you would not make a bad impression anyway, but let’s go through it nevertheless: Don’t give an angry or stern impression by frowning and crossing arms and legs. Don’t look careless by leaning back and looking to the ceiling. During the interview, show reactions to what the participant says or does and look him/her in the eyes (at least for members of western culture). When taking notes, maintaining eye contact is not possible all the time—but keep eye contact when you can.

Not-so-good posture.
Much better posture.

Be open to how the participant works and thinks

Ask open questions

You may have noticed that the suggested questions from the previous section are not aiming for specific, short answers, unlike typical survey-like questions like these:

If you would diagram who speaks for how long when we ask for such questions, it would look like this:

Short, closed questions.

These questions demand very specific answers from a determined set: Yes or no, marks from A-F, a list of nouns. They would be useful if you would want to do statistics, for analysis that allows us to give results like “56.3% agreed strongly on Question X”. However, we want to find out about the why and how of the participant’s work here 2.

Imagine, unlike the research session outlined above (short answers, short questions) a day-to-day situation, in which you get to know about somebody else’s experiences: A conversation with a friend. In such an exchange you will tell each other about your experiences, what you felt, why you did this and that etc. In a diagram it would look like this:

Giving longer answers, equal share.

In contrast to a conversation, our main goal is to collect data; we don’t want to tell about our Job as a user researcher, but hear answers from the participant. Thus, asking questions and getting answers in a user needs research session look like this:

The participant gives long answers, the researcher asks short, open questions.

The questions we want to ask should encourage answers which describe experiences and give some insight into the “why” and “how” of the user’s activities and motivations. Such questions are called “open questions” since they don’t have a determined (“closed”) set of answers.

Open questions would be: “Describe how you started your work today” or “Why did you copy that page?”

Using such open questions encourage telling longer, story-like answers. These answers will even contain information you did not expect to get.

A participant is describing me the printing process: “…then I look up which color specification the print shop needs…”

That is a new step in the workflow I did not expect (Naively, I thought that you just send the document to the print shop, like you would when you print it on your desktop printer—have a file, print it).

Thus, I discovered a step in the workflow and a potential field of work (taking care of color spaces and profiles), of which I did not know that it even exists!

The information you get will not be abstract as in answers like “good” or “I dislike it”, but tied to a situation. This is preferable, because a future product will be used in real situations and not in an abstract space of thought.

“I like it when the feedback [to the design] comes quickly. No annoying waiting… it always makes me nervous. Do they [the client] like it or do I need to throw out work?”

—this tells us more about the situation than a client’s feedback being just described as “I feel good”.

If you look back to the questions already mentioned, they will share some characteristics.

Here are some possible questions

  • Can you describe the worst experience in your day so far?
  • Can you tell me how you create a layout?
  • Can you tell me what makes a client “difficult”
  • Can you describe how do you get new ideas?

All these questions start with “…can you describe” or “…can you tell me”, which encourages a longer answer (since “describing” or “telling” demands more than one word). In addition, all sentences contain a Why-, What- or How-. These question words, again, suggest an elaborate answer.

Thus, a template for such questions would look like “Please tell me [how/why/what] + [researcher’s interest]”

Contrast this with questions like

You: “Is this a good design?”

Participant: “yes!”

“Is…” -questions will be answered with “yes” or “no”—but we don’t get to know why the participant approves or disapproves. In addition, “Is…”-Questions are a subtle form or influence 3 : In case of doubt, it is likely that are participant just agrees to the suggestion you give by asking “Is…”

Sometimes, “Is”-Questions will come in a disguised form—as an addition, which is made to an open question:

You: “Can you tell me how you solve this problem? …Do you do it by just calling the client and resolving the issue?

Participant: “Yes, I do”

The first part was fine, but the “Do you…”-addition turned it into a closed question.

Avoiding closed questions is actually harder than one thinks. We intuitively try to make answering easier with such additions like “Do you…”.

When you create your questions, check if they demand some predetermined outcomes—if they do, they are closed questions. In this case reformulate the questions in a way that allows and “open”, non-restricted, story-like answers.

Do not suggest “right” or “wrong” answers or processes

One way to minimize our influence on the participant would be making all research sessions alike—just like you would do when using a standardized questionnaire. But by doing this, you would lose the very strengths of the methods described here: Being able to find out about new and unexpected things, reacting to them and gaining understanding of the “how” and “why” by reacting on the situation.

Each participant and their context is different. You can accommodate this by adjusting the research session to the context and the activities of the participant. This would not be possible when asking the same questions each time.

You neither can’t nor should take yourself out of the research session—you will always have some sort of effect on the participant when you do the research.

What you should avoid, though, is influencing the participant by “suggesting” favorable answers or actions. Some sorts of this type of influence are obvious, others are not.

“This is good, isn’t it?!”

Is a very obvious influence, since it blatantly states what you think the answer should be: A “yes”.

There are less obvious influences as well:

“Would you like a better version of this?”

In this example, a positive word (“better”) and a suggestion go together. Who would not like an improvement?! A “yes” is guaranteed—as well as a meaningless finding which would be “people want improvements”.

Aside from your questions, you could influence the user with your feedback since it might suggest that there are “good” and “bad” answers. For example, it may be tempting to correct users and show the “right way” of doing something:

If you know, that there is a “change color”-function in the application and the user says: “Well; I am annoyed by that application—I’d like to change the colors but that is impossible!” It may be tempting to say: “No, you can change it!”

Remember, that you want to find out what your participant does and why. To correct the participant is not very useful. If the participant would clearly benefit from knowing some technical detail, just give the crucial information after the session. But for now, use the possibility to further explore the topic without correcting the user.

You can just ask “what’s the reason for you doing it this way?”, or, if talking about the function itself is really important to you, you can ask “How did you expect to do the color change if there would be such a function?”

You may also be surprised or even annoyed by steps or actions in a workflow of the user which seem outright superfluous.

“When I write a text I write a draft and then send it to my colleague via mail as an attached .doc file. My colleague comments on it and returns the mail to me”

You may think that this is rather inefficient and be tempted to say “Why don’t you paste the text in the mail and comment directly? Or write it live on Etherpad? This would be far quicker!”

Remember that nobody does inefficient things by purpose. Assume that the user has a reason. Try to find out what this reason may be.

Again, you could ask: “what’s the reason for you to do it this way”—and remember to ask follow-up questions to further explore the issue. In the example of the attached file it may be the case that the rich formatting functions of a word processor are needed or that such documents are used for just everything in this office, so that switching to a “better” solution would impose mental costs of switching to and operating in an unusual context.

Your influence could be non-verbal as well: you may shrug or frown if you do not like an utterance or an action. Even if you don’t say “this is wrong”, frowning or shaking your head may have the same results.

So: don’t be afraid to react towards the participant—reacting towards the participant is essential in our research. But don’t suggest “good” or “bad” answers or “good” or “bad” ways of doing things by using words, gestures or facial expressions.

Silence feels strange but is okay

Sometimes, the participant will take time to think before answering. Intuitively, you may want to fill the silence to help the participant along.

“Can you describe me what happened after you were finished with creating the print-ready-file? [1 sec] Was it all well?” “Yeah, sort of well, I think”

It is tempting to fill the silence with suggestions for the answer. But it can turn an open question (“can you describe…?”) into a closed question (“can you describe… was it…?”/“yes”) or prevent the participant coming up with their answer on their own.

Try to tolerate the silence. Usually, the participant will answer within a few seconds. If you notice silence which you want to fill, count to 3 or 5 before probing further. When the set time is up, you can ask about the question rather than giving suggestions, like

What makes the question hard to answer?


Can you tell me what you are thinking about?

By asking these questions, you can help the participant to continue with elaborating on the question you asked, even if they need some thinking to answer it.

Take a closer look


You got some valuable information, but there seems to be even more interesting things you may get to know about that topic. In this case you can “probe” for further information.

We already know one way to do this: Silence. The participant may just jump in and fill the silence with further information.

Participant: “So I had it finished and send it away to the client and then almost nothing…” [Pause, Researcher nods] Participant: “This is difficult, then. I mean, I got a brief mail that they got the design, but […]”

If leaving a pause does not make sense, you can achieve a similar outcome by repeating the most recent statement or words the participant has said.

Participant: “So I had it finished and send it away to the client and then almost nothing…” Researcher: “almost nothing?”

This way, you can help participants to carry on without actually adding any information yourself.

Researcher: “almost nothing?” Participant: “Yes, there was a brief mail that they got the design but I was unsure if that person actually gave it to the people who can decide something. That waiting just sucks.”

If you would like to know more about something particular, you can also ask directly:

Researcher: Can you tell me what you do in such a ›waiting‹ situation?

Asking directly can be particularly useful if the participant gave a rather vague answer:

Participant: Well, I try to get some more information and try to find out where it got stuck Researcher: Could you describe me how you would do that?

When you gather your data by observing or drawing diagrams with the participant, direct questions are very useful to explore the work:

Researcher: “I saw there was a warning in this pop-up-window. You wanted to avoid these warnings before—why would you now print the document in spite of it?”

Or, in the case of drawing:

This graph seems to indicate you were in quite a good mood here. Could you explain me a bit why you seem to be less happy here [Points]?

By using these probing methods, you can get additional information and show the participant that you are carefully listening and observing.

Check your understanding

You can refer back to answers to check your grasp of what the participant talked about. In this case, even closed (yes/no) questions are OK.

“I saw you choose the color from that palette down there—is this the same palette you choose the background color from?” “No, it is not—the palette I am using here is…”

There are several advantages of checking:

For checking, you always need to refer to something that you want to check. You often need to describe it to the participant:

[Researcher] “So: If I want to print something first, I need to ask for their color profile, when I have this, I load it in InDesign, choose the profile in the pdf dialog and then export it?” [Participant] “Yes. I usually to a test afterwards by opening the pdf in addition”

For this, you and the participant need to remember much at the same time. If possible, you can aid your memory by pointing to a device or part of a drawing or just demonstrating something. Don’t only rely on talking.

Can you tell me more about the function behind this button?


Here [Points to diagram] your motivation seemed to change quite quickly—can you tell me more about this?

Researcher points to a part of the diagram.

By checking your interpretations of the participants descriptions and activities, you can avoid misunderstandings and gain additional insights.

Ask for examples

Seeing an actual example avoids misunderstandings and gives rich opportunities for further insights: If possible, ask for an example, when participants mention activities or tools they use.

Participant: …so I would use the thing here. Researcher: The thing? Participant: Yes, it is a little icon on my desktop that does help me, when things go wrong! Researcher: Can you show me how you use it?

This avoids misunderstandings. The “thing” could be a script that fixes a setting. Or something else. We don’t know, and it is easier for researcher and participant to look at it together.

Steer the course of research

Switch topics

Over the course of your research you will cover different topics. Some may be set beforehand because you think they ought to be covered; other, new topics will reveal itself during the session.

There are several reasons to actively switch topics:

To switch topics, you can voice your interest in the next topic:

Could you tell me more about agreeing on a payment with the client?

If possible, you can end the block by rephrasing what you learned before moving to the next topic.

“Let me briefly summarize: […]. Next, could you tell me more about agreeing on a payment with the client?”

Referring to the previous topic can also help to give a sense of closure for the previous topic.

Thanks for telling me about specifying the task together with the client. What is also interesting for me: How do you agree on payment for your design work with the client?

This can be particularly useful if a participant is carried away by a topic that is not relevant for you.

So, knowing about lead typesetting is important for design work… There is another topic that might seem very different, but it is important to me: Could you tell me more about agreeing on a payment with the client?

To make the topic changes less abrupt, and to show that you listened carefully, you can refer to a topic which was mentioned but not explored yet:

In the diagram, you drew a blob for “printery”—can you tell be a bit more about how do you get the design printed?


You mentioned that the application needs to have the correct file format when you collaborate with someone. Could you tell me a bit more about your collaboration process?

By altering the topic, you can cover the issues you need to know about and, if needed, bring your research back on course. But do it considerate—each topic needs time to unfold.

Switch methods

Every method has will highlight different aspects of the participant’s motivations, activities and problems. So it makes sense to transition between methods in your research.

By using different methods on the same topic, you can gain new perspectives on it.

Here a possible switch from interview to observation: “You told me your general process of setting up a document for your designs. Could you show me how you do this for your current project?”

In this case, you already have a description of the activity. By observing the process, you can gain a less general, more specific and contextual view on it.

The methods you use on the same topic can be intertwined: During the demonstration of the activity, the participant may add to their description.

The participant explains while demonstrating: “So, I write a brief sticky note with what I think is important. I actually do this fairly often. I think I did not mention it before!”

Often, methods are switched together with the topic. You may have heard about motivations of the participant and now would like to explore an activity:

You said that collecting inspiration on the web is fun for you. Could you show me how you do that? Just do what you would do if I would not be here—and if possible, tell me what you are thinking while doing it.

Or you might want to talk in depth about the project structure that a participant just sketched in a diagram:

In this diagram you wrote that you have some conflicts with the client. Could you tell me a bit more about this?

Again, the methods can be intertwined:

You said that the client is often unclear in what he wants and says things like “it should pop more”. I write that here in the diagram, so I can remember it.

Using different methods and switching between them may seem like additional work. However, it can ease your work and, at the same time, improve its outcomes—just like choosing the right tools in manual crafts.

Recording data


Making notes on a clipboard.

While you observe or listen to the participant you will take brief notes. This is rather similar like taking notes in school or university: You go for the gist of what was said but you don’t write down the exact words (Except in the case you find a particular expression itself important). One utterance or observation concerning one topic goes in one line, bullet-point style.

When you look down at your notes and think about what to write, listening and observing don’t work well. Try to keep it as unobtrusive as possible.

When I take notes in research, I often write about 1 A4 page each 15min., sometimes more, sometimes less. You need to bring some paper, since your notes of a typical session won’t fit a single page or on the margins of your cheat sheet.

Example for a sheet with research notes, written ca. over 20min.

You will supplement, transcribe and analyze your notes after the data gathering. Thus, you need to be able to make sense of them later. Between collecting the data and reviewing your notes, the context is easily forgotten: If you observe that someone starts working on an empty page and you just write “empty page” it may make totally sense at the moment you write it since you are watching what is happening and knowing what happened before and after. But without this implicit knowledge of context the line “empty page” does not make much sense.

Rather than “creates empty page” write “creates empty pages to organize drafts”

Instead of “changes objects” write “Changes object size to match grid”


Unlike making notes on paper, making an audio recording is a rather passive process except for pressing the record button.

I recommend using audio recordings—it is a useful supplement to your notes. It will record the audio during the research session so that you can listen to what was said hereafter. Note that it is not a perfect capture of all that happened: It records only sound, so if the participant points to the screen and refers to “this”, the recording is not much of help.


Making photos is rather easy and can capture lots of information. For example, you can photograph the participant’s desk to aid your memory. Later, you can go back and see what was on it: Paper, pens, computer; were there tidy looking stacks and containers for all the utensils? Or was it seemingly messy?

You can photograph the users screen if your research involves computers and gadgets. A software-based screenshot might in theory be superior—but if the user does not know you to make a screenshot, a camera is a handy way to capture the screen.

You should be able to make photos with your camera quickly and reliably. Use a device you know and which has a good auto-mode. The only setting that I use beyond that is the exposure compensation in case an important part of the image totally dark or disappears in light. Exposure compensation allows adjusting for that.

Photographing the working user.
Photographing a screen instead of using screenshots.


The Observations you make are, by nature, visual and concerned with processes. Make sketches or even little storyboards to capture what you see.

It is very useful that you can choose what to draw: highlight what is important, leave out what is irrelevant and make annotations to ease understanding the sketches later.

I mostly use my sketches the same way I use notes: Notes and sketches are made on a common sheet of paper; one sketched observation goes in one line, if possible

Sketches on the note sheet.


A big advantage of diagrams is that the data gathering and documentation happen at the same time. So, there is not much to add. Happy diagramming!

Review your data

After gathering data, we need to take care that we can use the rich data in our later analysis.

When collecting the data with the participant you will be very busy listening and thinking of following questions, so may not be able to keep up with writing notes and drawing sketches. To make the most of your data, you should supplement our notes, sketches and diagrams and add some information about the context of the data gathering to close gaps and to help us to keep all the data organized.

There are two ways to supplement your data: From memory and from additional recordings, like an audio recording.

Supplementing your data should be done as soon as possible after the research session. I recommend to scheduling the data gathering in a way that you have some time directly after the session to supplement your data.

Supplement data from memory

I add data that I did not write down yet. In this case I add them, like


She looks at her sketches before she starts working

or I supplement some existing point with additional information:

Sketching paper kept ready. [ADDITION]: In transit: in the backpack; at the workplace: right on the desk

You can give brief notes more meaning by adding context from your memory:

She saves old ideas [ADDITION]: For later inspiration in other projects

memory fades quickly

When revising your sketches, redraw the lines if the sketch is ambiguous otherwise and add annotations if you think that they might ease interpreting the sketch later on.

Think of your future self: Some notes may make perfect sense to you now but since memory fades, they will seem cryptic later. So supplement and clarify your sketches and notes so you can comprehend them after your memories of the experience have faded.

I have line “Big changes” in my Notes. I remember that I made this note when the participant told me that her colleagues make bigger changes between to two versions of their designs than she does. I added this information to the notes, since it provided a way to understand what the “big changes” actually refer to.

Similarly, if my writing is rather messy, I rewrite some words to ensure that I can later decipher what I wrote.

I write and draw my supplements in another color than the color of the original notes. When I wrote my notes during the interview with a blue pen, I use black for the supplements or vice versa, since I like to be able to keep track of what I did in which step of the process.

annotated notes In this scanned part of a note sheet you see how the supplements are used:

1) These parts have been partly rewritten in black as it was too messy before. 2) At the right you see a newly drawn annotated sketch that provides a visual representation (how the document is organized by inserting empty pages). 3.) More information has been provided. It was “keeping for inspiration”, now its “keeping old stuff for inspiration”

Using different colors is useful for another type of supplement: Ideas or remarks in connection to your notes. When I go through the notes, I often have some ideas for a design or a question which I would like to further explore in a future interview. I write them down in a third color or I prefix the note with “IDEA:” or “QUESTION” in order to prevent myself of mixing ideas with empirical data.

Transcribe your notes

Since they are often written quickly, your notes will usually be rather incoherent: Single words, small sketches, and longer sentences will all be scattered on the paper. Tidy your data and transcribe the notes in a digital document.

Before transcription: Notes on paper.
After transcription: Notes in a digital document.

In your digital transcript, put one statement (or whatever you consider to make sense on its own) in each line. Avoid tying together two separate statements on one line. This needs to be balanced with another need: Makeing sure that the data you put into one line is meaningful on its own and is not just a single word or a description free of any context and thus hard to set in relation to other data.

To make this reasoning more clear, here are some examples:

Not meaningful on its own (means mostly: too short):

  • duplicate objects
  • making space

If there is any way to add the actual context (out of the memory or using other notes) these notes should be supplemented with that context which hopefully helps us to get to know why are objects are duplicated and for which purpose is the space is made.

Too many statements in one line (means as well: too long):

  • Duplicating pages to save old ideas is common. Later she goes back to the duplicates and looks at them when she needs inspiration.
  • She tries to have enough space for the margins to write comments in; to do so, she shrinks the main text area. She says, she could as well try to make space at the bottom of the page, and use footnotes for the comments.

Reasonable (each line can stand on its own and does not to cover multiple issues at once)

  • Duplicating objects to save old ideas for later inspiration
  • Make space for additional comments by shrinking main text area.
  • Alternative places for additional comments: Either right margin or bottom.

The notes from the research session and later added supplements from my memory get the same formatting in my documents since they are all data I gathered by listening or observing the participant. But I take care that later added design ideas and research questions are still easily distinguishable from the actual data that I gathered in the research session.

Possibly supplement from audio recordings

If you made a recording of your research session, use it to supplement and check data.

When the audio contains information which is not in the document or if it supplements information that is already there, I pause the playback and write the additional information in the document. The process is very similar to supplementing your notes from memory.

Audio recording: “…hmm I send it to my boss. She will check it. Now I go to that other document, and see…”

The notes say: “Send document via mail”

So I add the information about the cause of sending the mail: “Send document via mail to the boss for checking.”

If you need to save time, go through your notes and see where they lack information and jump to the parts of the audio that might complement these sections.

Pseudonymize your notes

When transcribing your notes, it is also a good point to pseudonymize them.

Pseudonymization means that you replace identifying information like names, places or job titles with placeholders. So the second user you talked to, “Jane Doe”, might become P2 (a user code) or ‘Anna’ (a pseudonym). This also depends on the participants’ wishes – some might want to choose a pseudonym or actually be appear with the name they usually use. If there is nothing else specified, I use codes.

Aside of names, there might be other data that could identify the participant, for example names of places, institutions or job titles. If they can identify the participant, replace them with more general placeholders: “Hannover” might become “A city in the north of Germany” 4.

You can’t make pseudonymization absolutely safe. If your research involves people who need particular protection against identification, you also might want to use a more elaborate way of pseudonymization and data protection – explaining that is beyond the aims of the book and research with vulnurable people is not a good setting to get started with user need research in the first place, anyway.

Organize and archive your data

It should be easy to find out later which data was from which participant and how notes, sketches, diagrams and possible audio recordings fit together.

Take care that all sheets of paper and files have…:

If you take these steps you can still match project and participants later so you don’t lose time or data because of some tangle.

As a result of these steps, you now have a transcript of your notes, diagrams, sketches and photos with possible cross-referencing annotations, participant codes, and descriptive filenames.


The data you gathered can’t be used for supporting design decisions yet: It consists of many unstructured small pieces. Now you need to structure and analyze the data—similar as writing a summary and interpretation of a long and complex book. Analysis is not a passive process: Making sense of data requires taking different perspectives and trying them out to see how the data can be interpreted.

Doing the “right” Analysis

The data analysis is done by inferring recurring themes from data points. Thus, the process is empirical (as it is based on gathered data). But even if the same data is used, different people will create different analysis. This is because the result of the analysis depends on the reasonable, but still individual and debatable, interpretation of the data. You could say that “looking at last year’s design to quickly reuse elements” belongs to a theme concerned with “I want to save time” or to a theme related to the topic of “reviewing designs for inspiration” (given that it could serve both from the user’s perspective).

There is no clear-cut “right” or “wrong”, when you interpret your data. Most important is that your analysis is plausible and based on the data you collected. I compare the process of analysis to building a house from a pile of Lego bricks. These bricks are like the not-yet-analyzed data you start with. When you build a house out of these bricks, there is no single “right” building. But neither is it a process which is arbitrary.

Possible arrangement of bricks—but not a house.
One way to build a house.

There are many, many ways to stack up the bricks somehow—but only a few of these possible ways will result in something that can be plausibly called a house.

How your final Lego house will look is not determined from the beginning. You will change designs, move walls and sometimes try to use the same piece in different parts of the building to try out and improve. The same things will happen when you analyze data: There are many possible ways to structure the data, but only some of them will create something that is meaningful to you and others. This creation of a meaningful structure is not determined at the beginning, but a process, just like building your Lego house, in which you try, fail, find improvements and—step by step—come closer to a structure you are satisfied with.

How to make sense of diagrams and lists

I will explain how to analyze diagrams and lists. This can be:

In our analysis, we will compare and summarize the collected data and bring it into an easy-to-grasp form.

Prepare the diagrams for analysis

To prepare the analysis, you write annotations on the diagrams. For this, you can photocopy the diagrams and write on the copies. If you like to keep it digital, you can use any application which can add text over images (e.g. the free Inkscape).

Annotated mood-graph by P1

In this diagram I noted some ideas for an interpretation:

  • I remembered, that most participants seemed to be quite happy at the beginning of their projects. This participant seemed to have a tough start. I assumed organization and waiting was not a positive experience, so I highlighted it
  • Starting with the designing itself was a positive experience.
  • After the start, the curve declines a bit. Maybe this is because populating the design with texts and images may be a bit boring.
  • Praise seemed to raise the mood.
  • …in parallel the participant did line breaks and letter spacing, I assume these are finishing touches and itself maybe a bit boring.
  • Sending the finished design to the client seemed to be a positive thing. Maybe this is a kind of closure point—“I finished the design!”
  • …however, waiting for the final acceptance is again negative, though usually only in the beginning (the participant projected this—the dotted line is assumed, since at the point of the research session, the design was just send a day ago or so.)

I wrote such annotations for all mood-graph-diagrams from the different participants in the research project.

Annotated workflow diagram: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/deed.en) Credit: Yarl (Workflow) Papuass (documenting), Jan Dittrich (recording, adaption as SVG) Based on: Wikimedia Commons WikidataCon_2017_Workshop_Workflows_03.jpg

This is a diagram of a user’s workflow when editing on the free database project Wikidata. Wikidata collects statements about things. These things are called “Items”. The item for the Mona Lisa could have the statements “instanceOf: Painting”, “Creator:Leonardo da Vinci”. “Painting” and “Leonardo da Vinci” would be items themselves, so all is linked!

The workflows for the Wikidata example were created by participants in a workshop at a conference.

I wrote my interpretation and ideas in blue at the workflow steps:

  • Enabling the gadget (a little helper tool) seems to be a prerequisite, so I wrote “setup”
  • In 2), a series of points concerned with list creation seems to start: “create a list”
  • I added a link to the used tool, so I can see how it works (“see: https//pet…”)
  • The participant wrote they add P31. This is a computer readable identifier for the data property “instanceOf”
  • For each entry on the list, they seem to open a Wikidata item (“Opens one…”)
  • Wikipedia is a source for data and opened in parallel (“Uses Wikip…”)
  • Point 5) seems to be less a workflow step but more a list of problems.
  • I was irritated by P1234. It is an actual data property on Wikidata, but it did not make much sense, so I assumed 1234 is a placeholder for any number.

Commonalities and contrasts

Once you thought of possible interpretations, you can compare them using diagrams from other users. Do they show the same pattern or do they differ? If yes, why? When doing this you can overthrow or update your initial interpretations and develop Note common patterns as well as interesting findings, e.g. if most diagrams share a common pattern, but one does not.

I compared the mood-diagram from the previous section with this diagram:

Annotated Diagram, P2
  • It looks much different from the first diagram above—there are far more ups and downs
  • However, we have also a positive start of the design process
  • New is, that the hard to solve problem cause bad mood, and that solving them makes the participant happy.
  • The client also praises (which lifts the mood)
  • The clients wished cause problems and thus a worse mood, in the diagram above it was mainly that the client caused “waiting”
  • Distressful phase at the end
  • Like in the diagram above, there is a positive “it is done” phase

I compared my analysis of the first and second diagram with the diagram drawn by the third participant:

Annotated diagram, P3.
  • Here, also, a positive start of the process (though the action is not designing, but forming a team)
  • Waiting/idle time is associated with a declining mood, like with Participant 1
  • There was a phase of rapid restructuring, positive new starts and declines of mood when the process did not work
  • A (more dedicated?) new team formed. They had time to make it to the planning meetings. This experience was positive. Annotated diagram, P4.

The fourth participant’s diagram:

  • Start is good again (This seems to be a pattern), it can be due to anticipation (P3,P2) and because of actually starting (P1, P4, also P3)
  • There are less great review/re-planning phases, which are also in P2 and P4;
  • Finishing is good, which is also a pattern in P1, P2, P3
  • What is new, is that the mood fell because a design seemed boring, the bad phases were usually framed as something from the outside (tough client wishes as in P2 or waiting: P1, P3) or as having a hard problem (P2).

Last but not least: the 5th participant

Annotated diagram, P5.
  • Again, like in the diagram before, starting is good. I would hypothesize that the anticipation feels great and that the actual start even lifts the mood a bit on top (?)
  • Like in P2, client wishes/negative feedback drag the mood down. Here we have negative feedback.
  • Maybe starting/trying a new approach is a bit like the positive feeling at the projects start (also P4 shows a similar pattern, P2 framed it more as solving problems. I don’t know if that is the same)
  • The pattern of “new approach good/client feedback bad” repeats (at time of the research, the project was still ongoing, so there can’t be an “end is positive” pattern here.)

We have looked at an example for analyzing the diagrams that show a “mood graph”. Other diagrams represent data differently. To see how to analyze workflow documentation, here another example. While the type of the diagram is different, it follows the same pattern of annotations and comparisons to find commonalities and contrasts.


First diagram:

  • …from the annotating, I already got the impression that there are two main steps: working on a to-do-list and working on an item, adding data.
Annotated diagram 2: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/deed.en) Credit: Susannaanas (documentation), Jan Dittrich (photo and adaption as svg) Based on: Wikimedia Commons WikidataCon_2017_Workshop_Workflows_04.jpg

Second Diagram:

  • Here we seem to have an additional step of creation before data is added to the new item.
  • The participant checked if there is a corresponding Wikidata-entry the entry on the to-do list, since the list was created from Wikipedia items (in order to check if corresponding Wikidata items exists.)
Annotated diagram 3: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/deed.en ) Credit: Papuass (Workflow) Yarl (documenting), Jan Dittrich (recording, adaption as SVG) Based on: Wikimedia Commons WikidataCon_2017_Workshop_Workflows_06.jpg

Third diagram:

  • Here is a “create list”-step. It did not happen in 2) but there is also there in 1)!
  • There is a tool setup-step in the beginning.
  • The step for the item concerns only its creation and addition of name and description, not adding of content.
Annotated diagram 4: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/deed.en) Credit: Liridon (Workflow), Hakanist (documenting), Jan Dittrich (recording, adaption as SVG) Based on: Wikimedia Commons WikidataCon_2017_Workshop_Workflows_08.jpg

Forth diagram:

  • A build-in function (“Recent Changes”) of Wikipedia is used as a list
  • In contrast to the other workflows, there is a manual select step (Finding a change concerning a person);
  • Like in the third diagram, there is editing of name/labels and description—but on an existing item, not a new one.
  • Like in the first and second diagram, the Wikipedia article serves as data source.


You can summarize the findings in a diagram itself. It will look similar to the ones the participants drew. In this diagram, you include findings you could support since they showed in several diagrams. I sometimes also include data which I could not necessarily corroborate, but find interesting.

Analyzing the mood-diagrams I got these conclusions:

  • In all but one (P1) diagram the onset of a project seems to be a good experience.
  • In three (P2, P4, P5) of the five diagrams there is a significant decline after the projects first, motivated phase. The reasons are: Seemingly unsolvable problems, project not going according to the plan and unhappy clients. A commonality is that the named reasons for the bad mood are seemingly out of the control of the participants (Except for P4, where the reason was seen in the “boring” design).
  • For all participants the project ends good (excluding P5, where the project has not ended yet). Three (P2, P3,P4) seem to be very happy at the end: Finishing seems to be a good experience.

This can also be shown in a summarizing diagram which I drew:

Summary of the analysis as a diagram

I created this diagram to summarize the workflows for editing Wikidata:

Summary diagram Wikidata edit workflow
  • In the first (“Adding instanceOf…”) and in the third (“Adding Wikidata items…”) workflow was a setup step. I included this—also because I knew from other research that tool use is widespread.
  • All four editors worked from a list. I tried to specify what that list could be. Different kinds of lists served different purposes: A list of existing items can serve for supplementing these; a list of Wikipedia articles without corresponding Wikidata-items enables the creation of needed items.
  • All editors did some work on items. However, there are different possible actions: creating items (3), some editing existing ones (1,4) and some created and then edited (2).

Making sense of notes

Your notes are data in written form, maybe with some occasional sketches. I will demonstrate a method to analyze your notes in depth. In contrast to the methods for analyzing diagrams, this is more complex. However, it is a very powerful method, which allows going beyond the pure data to create meaningful interpretations of your data, which can serve as guidance in later design work.

Organize notes hierarchically

The basis for our analysis are the utterances or observations, usually represented by a line in your transcript, like:

“I find it boring to move around all the text boxes again!”.

You will organize these hierarchically and group them if they may share a similar theme. Each group get a title, stating the theme of the underlying pieces of data. This is useful when designing, since you can refer to the title instead of reading through all the underlying data each time.

Sometimes, you will have several themes, which relate to a common theme themselves. In this case, it makes sense to make a group of groups with a title stating the overarching theme of this group of groups.

Here is a part of an analysis.

  • Overarching theme: Using existing work for inspiration
    • Sub-theme: Review previous projects
      • Data: “Have a look at an old project to see how I solved this problem…”
      • Data: Participant searches for…
    • Sub-theme: Use other’s work for inspiration
      • Data: “I look on google images how other calendars look like”
      • Data: Browses through the book to see examples of existing designs

Such a hierarchical analysis could be done in two ways:

  1. Top-Down: You first name the groups and write the titles and then sort pieces of data into the groups hereafter
  2. Bottom-Up: You first group pieces of data which seem to share a similar theme and then give the group a comprehensive title which states the topic shared by the underlying pieces of data.

We are going to use the “bottom-up”-way of analysis.

In the analysis we may start with grouping similar data together—like these two lines:


Then we give that data a headline and name the topic:

  • Theme: Use other’s work for inspiration

When we come across a piece of data which shares the topic, we can add it to the group, too:

  • Theme: use other’s work for inspiration
    • Data: Searches on amazon to see how covers of books about the same topic look like

This is a rather simplified overview of the process: In contrast to this example, you will as well spend time searching through data, rewriting theme titles and may need to step back or just sleep over it to find a good new way to make sense of your data.

Create meaningful groups

I already talked about grouping notes by shared themes. But what is a meaningful theme?

One method to group notes and to derive a theme would be going through the notes and see which utterances and observations mention the same thing or make the same assessment. Thus, all notes mentioning “color” would belong to one theme and get the title “Color”; all notes mentioning “good” belong to one theme and get the title “good things”.

Let’s say, we gathered this data (among others) in research on Do-It-Yourself-Work (DIY)

  • The shelf looks not as neat as a bought one, but it is mine
  • When it is broken and I need to get to work I can fix my bike quickly
  • The cabinet’s door was loose. It annoyed me, so I repaired it.
  • I look at the assembled bike and think: nobody else has the same

If we put the notes which mention the same things in the same group, we get these two groups:

Theme: Bikes

  • When my bike is broken and I need to get to work I can fix my bike quickly

Theme: Furniture

  • The shelf looks not as clean as a bought one, but it is mine

Organizing the notes by this “same things mentioned”-method would help us find notes concerned with a specific thing or assessment: If we want see everything that concerned furniture, we can go through the notes in the “furniture” group; If we would like to know what people liked, we could look it up in a group titled “good”.

However, organizing by the “same things mentioned”-method has its shortcomings: A theme named “furniture” communicates only that the underlying notes have something to do with furniture. You still need to go through the underlying notes to find out what people did with their furniture and what motivates them or which problems they face.

The names of themes created by organizing by the “same things mentioned”-method are just labels for the content and have no meaning on its own.

Imagine, we would not create the themes by looking for same things being mentioned, but by the insights we drew from the notes in the group by focusing on the meaning of activities, problems and goals for the participants.

If we take the notes about DIY again this could look like this:

Theme (based on an insight about the participants): Participants need to “make things work”

  • When my bike is broken and I need to get to work with it the next day I can fix my bike quickly

Theme (based on an insight about the participants): Good: DIY gives sense of individuality


If we organize notes by themes based on the insights about the participants and summarize that insight in the group’s title, the theme’s title is a useful piece of information on its own: It is not just for accessing the notes, it is an empirically based principle we can follow, when we design.

If you design, let’s say, for a DIY online community, a theme based on an insight, like “DIY gives as sense of ownership” may inspire the implementation of a function, which allows people to share their designs and customizations. The insight that sometimes DIY is just about fixing things may lead to the provision of a wiki for collecting best practices for doing common repairs and maintenance.

If you have a new idea you can ask: “Does this idea follow what is stated in the group titles? Does it violate them?”. You may ask yourself “Which design could I create based on this theme?”.

Since the themes are based on our data, they will express the actual needs of your users and not some (potentially stereotypical) assumptions.

Grouping your notes based on insights about your participants provides great benefits. But it can be hard and may be not possible for all your data. Thus, creating groups using the same-things-mentioned methods is still a useful method and these groups may still evolve. Usually, I have some “same-things-mentioned”-groups in the beginning and far fewer at the end—but my analysis will be a mixture of both styles.

To understand how to organize notes by themes based on insights, can be hard to grasp for beginners. To ease the learning, I provide another example:

Let’s say we gathered this data (among others) when researching beginners in web programming:

  • To try out stuff in HTML is fun
  • I analyze JavaScript code to understand patterns
  • It is great to quickly test something using a JavaScript framework
  • To know these ›attributes‹ of HTML-›tags‹ makes writing code easier.

If we put the pieces of data which mention the same things in the same group, we get these two groups:

Theme (based on same-things-being-mentioned): Utterances with HTML

  • To try out stuff in HTML is fun
  • To know these ‘attributes’ of HTML-‘tags’ makes writing code easier.

Theme (based on same-things-being-mentioned): Utterances with JavaScript

  • I analyze JavaScript code to understand patterns
  • It is great to quickly test something using a JavaScript framework

Organizing the notes by the insights we may draw from the notes, the structure look like this:

Theme (based on an insight about the participants): Trying out is good

  • To try out stuff in HTML is fun
  • It is great to quickly test something using a JavaScript framework

Theme (based on an insight about the participants): Learning makes own coding better

  • I analyze JavaScript code to understand patterns

Prepare your notes for Analysis

When you create groups of data, it is good to know if the theme of the group is relevant across several participants or only concerns one participant. To check for this, you should supply each note (=line in the transcript) with a participant code. You already used this code in the section on archiving your data to show to which participant the recorded data belongs. A participant code works like a pseudonym: The user is not identifiable by his/her real name, but by a stand-in for the name. I use neutral number codes: The first person I did a research session with is P1, the second is P2 etc.

If you have this on your transcript:

  • It is hard to know what exactly the client wants, because I don’t talk directly to the client
  • The document is divided in sections, separated by blank pages.
  • The current ideas/prototypes are in the first section. All discarded or “paused” ones are in later sections (the “archive”) […]

It will look like this after adding the participant codes (the data is from the second research session):

  • It is hard to know what exactly the client wants, because I don’t talk directly to the client— P2
  • The document is divided in sections, separated by blank pages. — P2
  • The current ideas/prototypes are in the first section. All discarded or ›paused‹ ones are in later sections (the “archive”)—P2 […]

You just add the participant code at the end or beginning of each line. It is not the most exiting work, but it can be done quickly—Copy the current code (like “P1”) in the computer’s clipboard (STRG+C), place the cursor with the arrow keys and the end/ home keys and paste the code (STRG+V).

Annotating data in a word processor.

Annotate your notes

After you added your participant codes, you can start to review and to annotate your notes in order to find possible interpretations, themes and meaning behind the observations and utterances.

This will help you to get familiar with the data and to derive meaningful themes and insights later.

Annotations can be full sentences, as well as short list of words. Usually, they concern a line in the transcript but you can comment on whole sections or just at words, too.

  • It is hard to know what exactly the client wants, because I don’t talk directly to the client— P2 ANNOTATION: indirectness, division of tasks, friction, “I need to know the client”.
  • The document is divided in sections, separated by blank pages. — P2 ANNOTATION: Keeping/imposing order

I suggest annotating each line, but this is not a must.

The annotations should be distinguishable from data you got directly from observation or the participant’s answers—just like other things you did add yourself (e.g. design ideas).

You can print out your transcript with a wide margin and write your comments in the margin. With pen and paper, you can write down your thoughts quickly, encircle interesting parts and connect them with lines. It will look messy, which is no problem, since your annotations are primarily to get familiar with the data and not for creating publication-ready thoughtful comments.

If you prefer working on a computer, you can annotate your data using a word processor with a comment function. Open your transcript, mark the part you want to annotate with your interpretation, then click the “comment” button. If you don’t use the comment function, but plain text, use something like “COMMENT:” or “ANNOTATION:” to mark your comments;

Annotating your data is a creative process. If in doubt, whether an annotation is relevant or not: opt for writing it. Later on, it might become useful. If you are unsure about something or an idea seems to be far-fetched, just go for it. Since you keep data and comments distinguishable from each other, you can always throw stuff out again. The goal is not to come up with great annotations, but to wrap your head around the data and to find possible ways to interpreting it.

Decide whether you want to do a digital or analog analysis

After annotating your data, you should take the decision in which media you want to conduct your analysis:

The analysis methods described here can be used in both media. Nevertheless, each medium has different strengths.

Analyzing data analog by using sticky notes. Theme are written on yellow sticky notes, themes of themes are written on orange sticky notes.
Analyzing data digitally by using a word processor. Themes have gray headlines, themes of themes have black headlines.

The resources you need for analyzing on your computer are:

The resources you need for with pen and paper are:

But why should you want to use an analog analysis, if it needs all these resources? Partly, the decision can be based on preferences: Some people like that they can move around the notes by hand and can get an overview of their data by just stepping back and glancing over it.

If you work with peers on your analysis, you have some advantages when using the analog pen-and-paper approach: you can easily discuss your ideas with others and will get new ideas how to structure the data. You can as well invite your boss to take a look and be part of the team, at least for some time. This type of on-site, collaborative, analysis is best done analog. Using digital tools it is not as easy and direct—despite all the great digital innovations we have nowadays.

Making sense of data together, using lots of sticky notes. (Image by flickr user Kalsau, licensed under CC-BY 2.0, https://creativecommons.org/licenses/by/2.0/; Changes: Image was cropped)

How to: Analysis on the computer

For analysis on your computer, I suggest the following steps for preparing your analysis:

  1. Create a new document
  2. Paste your transcript into that document
  3. Add a page break before the transcript to separate not-yet-grouped data from your (upcoming) structure of lines grouped by themes.

Creating groups by moving lines Similar data is organized in lists. You can just use the word processors bullet point list feature. To rearrange data, you can use copy and paste, drag and drop and the tools the word processor provides (toolbar to move points in lists etc.)

State themes in titles of groups: Each group gets a headline. Create a hierarchy by using different paragraph styles—bigger headlines for overarching themes-of-themes, smaller headlines for themes, that encompass the data directly. If you use paragraph styles to format your headlines, you can use the navigation tool of the word processor to go through your structure. You can as well just use the list-hierarchy feature (pressing the tab-key creates a subordinate list point). I prefer headlines, though.

How to: Analysis with pen and paper

For working with pen and paper, I recommend the following steps to get ready for analysis:

  1. Create table in a word processor with 2 columns and many rows. Each table cell will be a note.
    1. In the table settings, switch off “Allow row to break across pages”, so that one note/table cell will not be split between pages.
    2. In the table settings, choose a decent padding around each cell, like 0.5 cm
    3. Choose a font size of about 12 pt, large enough to read it
  2. Copy/paste all your data (line by line) from the transcript into the cells.
  3. Print it.
  4. Cut out each table cell (=piece of data).
  5. Optional: Cover the wall with the paper from paper rolls. (Thus, you can remove the analysis, roll up the paper and archive it and you can remove it from the wall temporarily)

Creating groups by moving sticky notes: During analysis, you will stick your printed notes on the widths of paper using removable tape, crepe tape or spray glue—something sticky but non-permanent, so you can move the notes around in order to gradually improve the structure.

State themes in titles of groups: Write your group titles on sticky notes. Color-coding by hierarchy can be helpful: If you print your data points on white paper, you can use yellow sticky notes for group titles and pink ones for titles of a group of groups.

Develop a first Structure

After you annotated your notes, you can start to structure them. Structuring the notes means grouping similar data together, suggesting themes behind the data, naming these themes and deciding which data falls under which theme.

You don’t use all your data yet. You can start with what you find useful, when skimming through or you can use the data of two participants for now. The goal is to set up some preliminary structure, like a sketch of the analysis.

Setting up a basic structure.

Move in proximity

The easiest way to start a structure, is moving similar data in proximity. If you do you analysis on paper, cluster the notes you assume to follow a common theme in one place, and notes for other themes in other places. If you analyze using a word processor, move similar notes in adjacent lines. Create different groups, each containing similar notes, by using several line-breaks above and below such a group or by creating a list for each assumed theme.

  • Asking herself: what would impress the person (a safety advisor) “probably not that the blueprint is beautiful”
  • Good: Something that is not only useful, but aesthetically as well

These themes have in common that they are about aesthetics and requirements. I did not have a good idea about a possible group title or even an insight I can draw from them, so I just moved them closer to each other.

Name Commonalities

You may have some data you assume to encompass a common theme, but you are unsure about the nature of the theme. In this case, just give that group of data a preliminary title. A group name, even if it does not state an insight, will make dealing with the data easier, since it gives your data some structure.

As you gather other data that falls under that (yet vague) category, you may be able to improve the theme and its title.

  • Inspiration
    • I try to get new ideas by looking at google images
    • I get new ideas while showering
    • […]
  • Media
    • I like to use photos
    • The website is a great way to reach out

These are mere titles, naming a commonality of the underlying data but telling nothing useful for design (yet)

State insights

You may have read through your annotations and have noticed something that may make a good insight right away. Great. Just write it down and assign the data to it. Even if you have only one or two pieces of data that fit the insight, don’t worry, just see if you find more data that matches and strengthens the insight. If not, you can still revise the title or just get rid of the group and see where else the data might fit.

The first insights I wrote were these:

  • Review previous projects
  • Test designs in the media you deliver in

The whole structure of my analysis later looked like that (the main list points are titles of groups-of-groups, the indented sub-lists are group titles):

  • Inspiration
    • Review previous projects
    • Other (Web, Bookstore)
  • Media
    • Do tests in the media you target
    • Suitability of media
    • “being closer”: 2 page-spreads instead of single pages etc.
  • Idea Attachment
  • Motivation at the beginning; then the problems start.
  • Finishing is good
  • (Page) Format is hard to change later
  • TrialAndError
  • Mutual dependencies of design elements like type area, content, font size etc. (?)

Note that some themes are meaningful insights (“Finishing is good”, “(Page) Format is hard to change later”), while some are mere group titles based on commonalities of the data they encompass (“Inspiration”, “Trial and Error”).

Now, you will have some preliminary, data-based themes, each created based on a few data points. Next, try if these themes are useful for organizing more than just a few data points.

Fill the Structure

Now need to try if the structure you created is feasible. Go through your data and sort it into the themes—be it actual insights or just stated commonalities—you came up with, or just move the data into proximity to similar data.

The difference to the previous step is that we now focus on involving all the data into the process of generating themes. In contrast, in the previous steps we focused more on generating an initial structure.

If the previous step was building a (data-based) scaffold, now we try to build the actual walls.

Build upon your preliminary structure to see if the idea actually works.

Aim for 3 to 10 pieces of data per theme. While it is temporarily OK to have very small groups, at the end each theme should be derived from several data points and not on a single utterance. In contrast, if a theme encompasses more than 10 utterances or observations, consider if it makes sense to split the group in “sub-themes”.

Usually, I would go chronologically through all my notes starting with the first participant and ending with the most recent one—though any other scheme will suffice as well. Just be sure that you know with which data you dealt with already and with which you did not.

When filling the data in the structure, you may notice that you need to create additional themes. Some titles of the themes may need to be renamed as well. Just go ahead and make these changes, if you feel they are needed.

  • Title: Test in the media you target
    • I folded prototypes for paper sizes that seem to be suitable
    • This is close the print shops results without spending too much
    • Tedious: Not having an own printer
    • […]
  • Title: “being closer”: Page Spreads instead of single pages
    • Creates page spreads (In books you have always 2 opposite pages, thus single pages are not useful for design)

Actually, the example above is not great in terms of analysis: The “Test in the Media you target” data is almost all from one person (P3) and the “being closer”-Group has only a single data point. In later iterations I’ll change this group. But for now, it suffices.

While I was sorting the data, I created a new group to accommodate data related to changes in designs:

  • [Title:]Changing and determining
    • Determining: What do we have? What do we need? What do we want to avoid?
    • Sketching, e.g. for “How can I divide the page for 7 days of the week?”
    • “This is trial and error”

Some data could not be accommodated yet. I created a misc group, where I could offload the data for now and try to find a better place later:

  • [Title:]misc
    • God: Shortcuts
    • I need to ask the print shop what this design would cost
    • Bad: Doing the same steps over and over again.
    • […many other points…]

Inside the misc group some possibilities for future insights emerged—for example the first (god: Shortcuts) and the third point (“bad: doing the…”) could be part of a newly formed insights named “I want to avoid repetitive tasks”

Now, your groups will be informed by several data points each. But there will be many themes, which are created by the “same things mentioned”-Method; they don’t state insights. In addition, there might be overlapping themes and groups encompassing many data points, while other groups may be only informed by few data points from just one participant. It is time to revise the structure.

Revise the Structure

After you went through your data and sorted it into themes, review your work. You now may have a clearer view of what constitutes the themes after you sorted the data.

If you recently dealt with just a particular part of the analysis (like dealing with two particular groups), your view might be too narrow: Glance over the whole range of clustered data, and rediscover themes, which might be a better fit for some data.

Have a look at structures that need improvement: Groups, which have a title which does not express an actual insight yet, and data, for which you did not find a good place. This data might now be helpful to create new themes or can add to some themes.

Take a critical look at the themes in relation to the data they encompass: Is there a fit or did you fall prey to wishful thinking? Possibly, there is actually only a weak match between the stated theme and the data. In this case, revise your structure.

Some parts need to be revised and newly created.

Find better names

Groups based on commonalities or vague similarity will hopefully evolve into insights about the participants. To achieve this, try to revise group titles: make them more concise, clear and meaningful. If a group of data is just named with a title based on mere commonalities of the data in that group, try to state an actual insight for that group. This will almost certainly require moving some data between groups in order to accommodate the data to the improved structure.

For one group, I used the title “Arranging”, since arranging and aligning objects, lines and text to a predefined grid or to each other was a task that occurred frequently. But the title “Arranging” just names a commonality. To make clear that the group is about a user activity and to state the theme as an insight, I renamed “Arranging” to “Arranging objects is an important activity”

One group was named “repetitive and manually”. This could be easily stated as an insight: “repetitive and ›do-it-manually‹ tasks are tedious”. By just adding the users view (“are tedious”) the title became an insight which is a useful principle for design.

I had the following structure:

  • Inspiration
    • Review previous projects
    • Others (Web, Bookshop)

“Inspiration” is a title based on the “same-things-mentioned”-principle, so I had a look at the underlying data. They all were about inspiration—but they had another commonality: All inspiration techniques used other, existing designs, often ones that were created by the same person or even for the same project (It would have been possible that people take a walk or have frequent brainstormings or take drugs to get new ideas etc.). The insight I came up with was: “I use existing designs for inspiration”

(Re) Move data to other groups

When improving your structure, it might be necessary to remove pieces of data from groups, either moving the data to a temporary “misc” group or to another, more suitable group.

While we want to make use of the data we have, it is most important to create sound and helpful themes based on the data— instead of just putting everything under a label.

It is possible, that you can state an insight more clearly by rewriting the group’s title, but as a result, the clearer title may no longer encompass all data in the group. In this case, go for clarity of the groups title, even if it means, that the theme does not encompass all the data currently subsumed in the group.

Take out the data which does not fit the improved title and see if it might fit better to another group. If not, place it in a “not yet grouped” or “misc”-Group. Revise that “misc” group, when you made changes to your structure and see, if you can use the data from that group to enhance other groups.

I reviewed the following group:

  • Feedback
    • Good: getting feedback
    • Bad: uncertainty before feedback from client

The title was not a meaningful insight and I felt that the analysis might benefit if I use the data in other themes.

I already had a cluster related to motivations and emotions– where I moved “bad: uncertainty before feedback from client”. The “good: getting feedback” was moved to a cluster named “Exchange with others”.
While I think I gained something out of it, these changes did not result in a new much better structure. It was part of trials and errors in the process.

Going through the data of a group named “general requirements”. I noted, that a big part of the data was concerned with balancing functional or practical requirements (price, readability etc.) with requirements concerning style (using colors, being innovative)   Thus, I renamed the group to “trying to combine aesthetics and functionality”. As the new title was more specific some data needed to be taken out, put into other groups or to the temporary “misc” group.

The previous examples were concerned with whole themes and thus focused on the macro level. Sometimes you just move data itself, without any trigger like renaming, just because you found a better fit.

For example “using the maximum possible height on a sheet of paper” was grouped into “media”. Later, I moved it to “budget”, because budget is something the user is directly concerned with, whereas media is even more abstract. The group “budget” was then later renamed “having little money and resources”, expressing that a part of the participants work was finding out how they could make the most out of a small budget (“using the maximum possible height on a sheet of paper” is a practice that results from that concern.)

Create Sub-groups

Some groups may grow rather big, especially if their themes are not insights, but are based on mere commonalities of underlying data (like “dealing with color”). This is an excellent opportunity to develop themes by creating sub-groups. The process of developing sub-groups is like in “Develop a first structure” (just inside the group): Move similar data in proximity and try to create clear-cut insights if possible. In this process, you might find a more suitable way to state the theme of the main group, too.

I had a group with more than ten points regarding “Colleagues and Friends”. This title was rather general and thus not very useful for design. I created two sub-groups which were more meaningful.


  • Colleagues, Friends etc.
    • A friend told her that concrete is visualized dashed
    • Puts sketches on the wall: Others will see it and talk with me.
    • Which design do we take? Talks with fellow designer
    • […]

After splitting and rearrangement:

  • Exchange Knowledge
    • A friend told her that concrete is visualized dashed
    • […]
  • Making decisions with others
    • Which design do we take? Talks with fellow designer
    • feedback-rounds with other designers

One main point in my first structure was “Highly motivated at the beginning; then the problems start.”. After restructuring, this became a sub point of motivation related groups.

  • [group-of-groups] Motivations
    • [Sub-group]: Highly motivated at the beginning; then the problems start.
    • [Sub-group]: Finishing is good
    • [Sub-group]: Waiting for feedback is bad
    • [Sub-group]: being afraid of the client’s rejection of the design

Sometimes you first sort the data under the overarching title or principle and then move it to an already existing sub-group later:

The utterance: “It’s bad that you can do imprecise things here, compared to programming (talking about Illustrator)” was first sorted into “Media” and subsequently put into “using the right media”

Wrap it up

It’s done! (though you could still change some things or two…)

The steps described above build on each other. But like in other creative tasks, there will be a lot of going back and forth between steps of creating groups, assigning data to them and revising these groups.

These iterations may also happen just in parts of the structure you create. For example, after you revised your overall structure, you find, that a grouping should undergo a major change and you put all its data out. Then, you are back to developing a structure for a part of your analysis. Or, you notice, that some notes which you moved in proximity, can be summarized by a clear principle, and you jump straight to the revision of that part of the analysis, leaving the “fill in the data” step out.

This process can take up some time. The analysis may never come to an actual halt, but it will slow down at some point. Continuing to move data may still do minor improvements, but there are no big changes anymore. Review the data a last time. The analysis is finished and it is time to communicate your results.

Final structure:

  • Arranging Objects as important part of the work
  • using existing work for inspiration
    • review previous projects
    • use other’s work
    • use previous ideas from same project
  • Media
    • Test design in the target media
    • Find suitable media
  • Being attached to ones own ideas
  • Working visually
  • Social
    • Exchange Knowledge
    • Collaborative decision-making
  • Motivation
    • Highly motivated at the beginning; then the problems start
    • Finishing is good
    • Waiting for feedback is bad
    • being afraid of the client’s rejection of the design
  • repetitive and manual work (negative)
  • changes and requirements
    • Some changes like page format are hard to change later
    • combine function and aesthetics
    • changes cause other changes
    • considering the budget
    • trial and error as method
    • use the actual content for testing (not fake content)
    • fixate things to have a starting point
  • Misc
    • designer vs. technology
    • making calculations
    • choosing fonts

These are all the groups I created in my analysis. The results could be more concise, having fewer groups concentrating on fewer themes. However, this would probably lead to more abstract insights which would presumably harder to use in design.

The groups of groups are partly not insights themselves. I tried to find some, but was not able in a part of the cases: “changes and requirements” is not an insight (but it’s subordinated groups are: “combining functions and aesthetics” etc.). In contrast, “using existing works for inspiration” is a group of groups which states a meaningful insight.

You see that I could not use all data, so I made some less significant groups in the “misc” section.

Communicate Results

If you work with others, the results of your research need to be communicated, so they can act upon your research results.

Aside from getting the results of your research across, communicating your results has some positive side effects: collecting, organizing and summarizing your findings will make it easier for yourself to remember your findings and you may be even able to improve your analysis further.

This chapter is different from the others. In the chapters before, the focus was on the research itself. But what works well is highly dependent on what your audience is familiar with—and this is something that I can’t know. So I could give advice on how to create a persona, but if your colleges base their work mainly on another framework, like Jobs-To-Be-Done the persona would not help.

Because of this, the chapter gives some general advice, shows standard representations (like diagrams and scenarios) and the formats is mentions are conventional (like slide decks and reports).

Consider the audiences needs

Who will receive the research results and what interests do they have? There may be different stakeholders with different needs, e.g.

Some of their needs align, some may differ. Before you start, you should ask yourself who will receive the results and what specific interests they have. Also inquire if there is any preferred format. Some may prefer text-based reports, others may be used to slidedecks.

First things first

Structure documentation in a way that puts the essential information first. A simple rule of thumb is this: If a reader stops early at some point, they should already know the most crucial information. Otherwise, it can happen that after reading half of it, the most crucial information has not delivered. Also, it is motivating to deal with documents that put important matters first. One can read e.g. the summary in the beginning and then decide that this is the needed information and continue—or discard the document and don’t waste time.

Don’t make it hard to understand

You create the documentation for people who are not user researchers and who often have not taken part in the research. They won’t understand any jargon of your profession and maybe also not the vocabulary the users use. Thus, avoid language that is hard to grasp or uses words unknown to your readers. Instead, “translate” for them: Describe the research in terms they know and help them to make sense of the participants’ language and actions.

As a rule of thumb, rather assume too little knowledge than too much. A person knowing something will just overhear or overlook an explanation while a person who lacks some background information is lost without it.

Sections of a research documentation

There are some typical sections of a research documentation:

Executive Summary
Summarize the research and its results in a few paragraphs.

Summarize the research question you aim to answer with your research

Research Methods

Describe how you gathered and analyzed the data. The research in this guide uses “interviewing and observation” for gathering the data and “thematic analysis” or “qualitative clustering” as analysis methods (The terms for the analysis are not 100% scientifically correct though since analysis followed no “official” method)


Describe how you got your participants and why you did so. Show that you did not just got somebody, but people who were relevant to the research needs.


The themes and consolidated diagrams belong here. They are the core of your documentation. While most other content follows a pattern, the results will be different each time. So be extra careful that the results can be understood by the audience and use illustrations, photos and quotes to get your message across.


Sometimes you may give some advice for possible further research or or designs.


If your audience is interested in digging deep your documentation you can provide additional information here, e.g. an in-depth breakdown of your themes or additional photos and sketches. If you provide material that is less abstract, take extra care to check if the privacy of the participants is maintained.

In a longer, written report you may have all of these sections. However, often you will only provide a subset according to the needs of the audience e.g. only the executive summary and the recommendations in an email.

Components of deliverables and reports

Let me give a brief overview of typical building blocks for communicating your research. They are all useful on their own and you can combine them to use their strengths together.


Text is as very versatile way to convey information. On the downside, text may seem not as quickly accessible as a diagram or a sketch. To lower the barriers, make sure that people know why they are reading your text. Give essential information at the beginning (What is this text about? Why was the work done?) and make sure that it is easy to get a quick overview: Structure your text using headings, lists and italics to guide the reader.

A page spread from a report.

There are lots of books which explain how to write concise and easy-to-get text. The most efficient guide I know was given by George Orwell in “Politics and the English Language”—I quote:

  6. Break any of these rules sooner than say anything barbarous.


In addition, read the text aloud—in particular, if you already noticed that you have had difficulties finding the right word or to express a complicated concept. If you need to re-read sentences to make sense of them or to stress the right words, you should go for a rewrite.


Quotes convey the participant’s motivations and feelings. This is important to help others to have empathy with the users.

Rather abstract: Users like the alignment function

Combined with Quote: Users like the alignment function. Sandy: “It is like doing work by magic—click! And it’s there!”

Remember to protect the participant’s identity if they did not give you the permission to share their quotes or names. If they did not give you the permission, only share a plausible, but faked “quote” and don’t use real names but pseudonyms (made-up names) ones as well. Don’t deceive your audience either: mention that the names and quotes are not real but are only corresponding to their actual counterparts.


Activities don’t happen in isolation from each other: They depend on previous activities and (possible changing) motivations. One way to communicate a sequence of interrelated activities is a scenario. Simply put, a scenario is a short story written as text or given as a sequence of images (like a comic)

A good framework for writing scenarios is asking yourself these questions:

Answer them in your scenario:

Annika studies media culture and needs to finish her homework on “Cultural subconceptualist theory in the works of Koons” in order to hand the homework in on time. She goes to the library to see if the book on “Capitalism in the works of Rushdie” by Andreas Geoffrey contains arguments supporting her view on the structuralist paradigm.

She enters the library and walks up to one of the computers standing in the corners of the library’s halls. She wants to look up the name of the author, but she notes that she forgot the copy of the book that referenced the work. She still knows that “Rusdie” or “Rushdie” was in the title of the book she needs. After several trials she finds the right spelling of the name and, after scanning through a list, she finds the book she wants to read. The detail page of the search application gives the address of the library building she is in already and a code: “X0-3R52”… [scenario may continue]

You could as well create a scenario as a series of sketches, like a comic strip:

1 the search interface of the library’s computer 2 remembering the code. Is this character a zero or the letter ›O‹? 3 I can’t find the right shelf! 4 I’d better ask somebody… …now I know where I need to go!


A diagram showing the sources and flow of files used by university students.
A diagram showing the workflow in creating a software.

Diagrams are useful to show high-level concepts, relations and dependencies – for example showing which activities need to be done to create a page of a magazine or the ways a group of students shares files when working together on a joint project.

You may use the summary diagrams you created in the analysis or create new diagrams for this step.

Photos and Illustrations

Which one is easier to understand and less ambiguous:


The participant’s desk is rather tidy. In front of the keyboard is a book and on the book a calculator. Left hand are additional utilities, like…

Or that:

I suppose the image wins.

While the above example just shows a setting, we could as well combine the strengths of text and images in an annotated photo.

Or you could show your general findings about how people organize their desktops by sketching a prototypical arrangement of items.

Illustrations and photos in particular have another function aside of getting information across: They make the research and its findings more graspable, intuitive and “real” for your audience. Just like scenarios and quotes they enable to imagine how your research participants acted which in turn helps to develop empathy for them. Consider again our example from above in which an image and a text were compared. The photo does not only give some abstract information. It shows that you have been with actual participant or—in this case—did research on actual tools they use.

When using photos, remember to protect the privacy of your participants. Only show photos of their workplaces or of themselves if they agreed to it.

Typical documents for reporting results (“Deliverables”)

You can combine text, images diagrams and scenarios in several ways to communicate your message. Let’s look at some possibilities.

Quick findings

Quick findings are short, annotated lists of your most important findings. They include only a brief description of methods, participants and environment. The focus is on the most important results. Quick findings can also be delivered before the analysis is fully finished. In this case, highlight that you are still refining the research.

Quick findings are very useful if your audience:

Written Reports

Written reports are roughly four to a several dozen pages long. Nevertheless, only deliver what the audience needs and wants to know—be concise. It is easy to get sidetracked and to write length and complex sentences.

Written reports consist mainly of text, but you should use images, quotes and diagrams too when they make sense.

Page spread from a report on wiki use for teaching at university.


Slides can deliver the same content as written reports or quick findings. They convey the information in a more visual way—so they have fewer text and more images, diagrams, and storyboards.

If you give the presentation yourself try to deliver as few as possible of the information by text on the slides. You can do the talking and the slides supplement the information you give. On the other side, it may makes sense to use more text on the slides if you just share the slides with others and don’t present them yourself.

A row of slides from a presentation on wiki use for teaching at university.


A poster is a great way to show the results in a way that is easy to grasp and will be consumed too by people who do not take specific interest in user research. They can be put up in a hallway for everyone who walks by.

Focus on a few important findings and show them using graphical elements and text. You also can create a big version of diagrams you created or summarized.

A poster showing three core findings from research with editors of the free online dictionary Wiktionary – By Wikimedia Deutschland, Licensed under CC-BY-SA 4.0, https://creativecommons.org/licenses/by-sa/4.0/


Learn (even) more


Design focused

These books are written for designers and user researchers. The methods and examples are immediately useful for design work.

Academic focus

These are books written for academic researchers. Why should you bother with academic books if there are some specifically for designers? Books aimed for an academic audience also cover topics that are easily brushed over. This might be ethics, data analysis and different paradigms for it and the question if there are a “true findings”. All this can be very useful if you find yourself researching sensitive topics, need to come up with custom methods or if you need to explain and defend a particular approach.


Forms and Templates

Co-Documentation Templates

If you read this on a computer, you can download the templates via right-click → “save image as”

Co-Documentation Template for graphing and annotating a participant’s mood over time
Co-Documentation Template for diagramming the context of a participant’s work
Co-Documentation Template for documenting a workflow

Consent and Release Form

(based on a form from http://www.usability.gov, downloadable here, released as public domain)

Consent & Recording Release Form - Adult

I agree to participate in the study conducted and recorded by the [Agency/Organization].

I understand and consent to the use and release of the recording by [Agency/Organization]. I understand that the information and recording is for research purposes only and that my name and image will not be used for any other purpose. I relinquish any rights to the recording and understand the recording may be copied and used by [Agency/Organization] without further permission.

I understand that participation in this study is voluntary and I agree to immediately raise any concerns or areas of discomfort during the session with the study administrator.

Please sign below to indicate that you have read and you understand the information on this form.

Date: _________________

Please print your name: ___________________________________

Please sign your name: ___________________________________

Thank you!

We appreciate your participation.

  1. This idea, that a book on methods should be treated like a travel guide, is inspired by Reassembling the Social by Bruno Latour, a book on so-called Actor-Network-Theory, describing a perspective that is frequently taken in sociology of science↩︎

  2. Research concerned with finding out about “how” and “why” using methods like interviews and observations is also called “qualitative” research. In contrast, “quantitative research” usually tests hypothesis (like “an orange ›buy‹ button generates more sales that a blue one”) and employs controlled experiments and statistics. In this book, we learn about qualitative methods↩︎

  3. Also called a “leading question”↩︎

  4. If you want to know more about pseudonymization read “Anonymising interview data: challenges and compromise in practice” by Saunders,Kitzinger, and Kitzinger, https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4582834/ ↩︎

  5. Orwell’s Rules for writers.↩︎