Designing The Analysis Process



Analysis is the opportunity to understand what you are experiencing in your research. It encompasses a series of activities that can be done alone or in a group that allows you to think differently and empathetically about your users.


Making sense of what you are seeing and hearing from users and other influential stakeholders is the most important and valuable part of the Needfinding process. There are a lot of ways to do this, but the following are a few activities that can help you and your team translate user experiences into helpful guides to your tool development process. You can use all of these or a few of these. The important thing is spending time thinking about the user experience. Have fun and be creative coming-up with ways that can help you and your team understand users and the information you have gathered.


Spending time asking “why”, looking for patterns in the data you’ve collected, and staying true to uncovering answers to your Research Questions is a critical part of human-centered design. The analysis process gets you to the insights and learnings that are potentially transformative for a community versus just one person. Instead of moving from observation (“I saw this”) to solution (“I will make this”), dig deeper into what is going on in this situation and how this relates to other things you have learned along the way. For example, just jumping from “I saw one person use Google Drive” to “all Internet Freedom Tools should be able to interface with Google Drive” doesn’t capture all of the learning. Ask yourself “who”, “what”, “when”, “where” and “why” and that will not only get to a deeper insight, but it will also help you prioritize what needs to be a part of your tool.


Analysis can happen anytime during your Needfinding process. The more frequently you do it the more you are able to make changes and update the way you conduct research to hone in on the things that matter most. Similarly, understanding what you are learning along the way allows you to start to test hypotheses in real-time with users and influential stakeholders and helps you start to see how what you are learning can shape the tool design, implementation and follow-up with users.

Debriefing Research Visits

After every type of research visit – from Interview to a Group Convening – you and your team should spend some time talking about what you learned, witnessed, and experienced as a whole. Here are some things to discuss that can help you with your debrief session:

  • Initial Impressions.
  • Write down key take-aways – information you learned that struck you as particularly meaningful, interesting, or useful to your work.
  • Review basic facts about the participant(s).
  • Share key stories about the participant(s)’ life and priorities.
  • Discuss participant(s)’ social connections & roles in their community.
  • Document definitions or points of view around key topics and terms; for example “security”, “privacy”, “threats”, and “communication.”
  • Share anything you found strange or interesting in general.

Write the top takeaways at the beginning of your notes that way you have the ability to quickly skim the top learnings and go deeper at another time. This process also makes it easier for others that may not have been on the site visit to go back and understand what you have learned. Immediately after your visit spend at least 10-15 minutes capturing this information. You can always come back and add more, but things are freshest right after a visit so you might as well start then.

Reviewing Research Notes, Video & Recordings

In general it is a best practice to review your notes (or any other way you captured your experience with users and stakeholders) from the research visits; especially if you have a team and not everyone was able to be a part of the visits. Each time you look at them you will see something different informed by what you are learning along the way.

Answering the Research Questions

You have spent time at the beginning of your Needfinding process identifying the key questions and topics you want to learn more about (See Establishing Goals & Research Questions). This has informed your research process and recruiting of participants. Go back through your notes, visual exercises and your own thoughts and musings. Use these to start answering your Research Questions. Doing this activity will also let you know where you need more “data”. These answers can already be incorporated in your design, implementation and user feedback navigation or prioritization process.

Capturing Top Stories

A great way to kick-off a deep dive into users is to step back and think about a couple (2-3) of stories of things that you saw, read or experienced with users that you thought was unusual, insightful, and keep a running list. Those stories will help lay the groundwork for the development of personas, updates to your funder and other developers interested in what you are learning. If you are on a team, do this with your teammates as a way to “warm-up” before jumping into other tasks. This is one way to help keep users in mind throughout your development process.

Identifying Needs

One of the most asked things of users is “what do you need?” or “what do you want?” This is often a very difficult thing for users to articulate clearly. It is easy to say we need a developer to help with viruses when you get attacked on an ongoing basis or more funding or time. It can be more challenging and more time consuming, however, to reach a point where users can say I need a way to verify that what I am sending actually gets to the right person without any changes to the content. Needs are living and active and as a result can be expressed and/or felt by users in different ways. One way to think about a need is as the thing that is missing. It is a requirement – psychological, physical or cultural – that is evident in an individual and/or a group.

How do we start identifying “what’s missing?” Go back to the key stories and questions where users were expressing pain points, successes they have overcome and roles in their job or their mission and use that as a way to start to identify their needs. An important thing to remember is needs are verbs not nouns. That means that if you are talking to a news outlet that is in a situation where the electricity is constantly going out their need isn’t “to have a generator”. Their need is to have consistent access to a power source in order to complete work tasks, for example. If we just left it at “generator” we are eliminating other solutions that could be developed like a battery or solar panels or a whole host of things. Once these verb- based needs are identified you can start to brainstorm solutions for them; thus another way to generate more ideas that are grounded in what is happening to our users.

Developing & Designing Based on Personas

Personas are a great way to help you and your team make sense of the di erent types of people and in particular users that are a part of your tool ecosystem. The actual act of creating personas is an analysis process. See Developing Personas to learn more about how to design and use personas. The use of personas can be a helpful design check.

Analyzing Visual Exercises

Having participants design and create in their own words and images is a powerful way to understand who they are – motivations, priorities and needs. However; not everyone is articulate and even though you have had a conversation with them about what they have created, including follow-up questions, there is still a need to spend time and look at what they have made. Similar to the debrief process, spend time pulling out the top takeaways from their exercise and have that written down in the notes document. Once you have gotten a couple of people who have done the exercise you can start to compare and look for patterns – similarities and di erences – across how someone approached, for example, the Connectivity Process of the Tool Development Process.

Identifying & Understanding “Tools” Used by Users

This can include actual IFTs that were developed by yourself and others and “tools” that the users themselves designed and are using. In addition to listing these in a central place the next step is determining when, where, how and why a user is choosing this tool. By unlocking the scenarios of use, you will be able to gain a deeper understanding of motivations, needs and challenges of tools. Things that people have cobbled together may not seem sophisticated or helpful at rst, but they tell an important story and analyzing them allows you to determine what design cues and principles may be helpful in your own design. For example, when the SecondMuse team met with a large activist group with chapters all over the world, the administrative body explained to us that they are often subjected to people sending viruses through attachments. If they need to send each other an attachment they will use a group chat on Viber to notify everyone that an email is coming with an attachment and that it is in fact from one of their colleagues and they can open it. This process of attachment veri cation doesn’t mean design a group chat app, but points to the need for people to verify certain types of communication. This learning opens the door to many di erent solutions that you and your team can come-up with. If you had stopped with writing down Viber, you would have missed the connection to the development process. This is one of many learnings from just one explanation of someone creating their own “tool”.