.png)
In our last post, we covered techniques for simple, consistent, open-ended listening sessions with users and potential users, rather than always doing a discrete Discovery phase for each product initiative. But conducting the interviews doesn’t guarantee product teams and designers will make human-centered choices. Making sure all this rich information about users gets used by product teams is just as important.
Numerous times, we’ve seen teams take time to do painstaking, bottom-up synthesis and create a comprehensive findings and recommendations presentation for a commissioned study only to find out that the window for influencing what will be designed and delivered has already closed.
Instead, we suggest focusing on creating and maintaining just two foundational documents, with an optional third for products or services with distinct phases or domains of usage.
Introducing: The User Insights Library
.png)
These three documents, along with the raw transcripts of customer listening sessions, make up The User Insights Library. This repository is fed by the Continuous Listening and User Needs Validation processes (we’ll cover validation in our next post) and used to generate fresh ideas and evaluate existing ones.
- The User Archetype Catalog
- The User Needs Inventory
- The User Journey or Ecosystem (Optional)
Beyond these three documents, the research team’s findings, recommendations, and user wish lists should be integrated into artifacts that other teams are already creating and managing, like user stories, product feature backlogs, product requirements definitions, or specifications. Rather than spending time crafting one-off stand-alone documentation, integrate the findings into places where someone is likely to encounter and use them!
Further, the research team, steeped in up-to-date and detailed knowledge from continuous listening practices, can maximize its impact by representing the voices of users and collaborating directly in intentional conversations with design, product, and development team members.
The User Insights Library is our attempt to increase how often, and how deeply, we think about and incorporate real user input by making insights easier (and quicker) to access.
Let’s take a look at how each piece works.
1. The User Archetype Catalog: Emphasizing a variety of perspectives
User archetypes ground product and service teams in important context about who their users are and how those users approach things.
This helps teams avoid the trap of thinking they have a single, generic user (who represents no actual user), or getting overly focused on characteristics that are less likely to be indicative of their needs (such as demographics or Net Promoter Scores). Instead, archetypes can help product teams appreciate and respond to the needs and characteristics of real users.
We think a good User Archetype Catalog will include between 3 and 10 archetypes. Though the format is flexible, each catalog entry should include:
- A brief description of who they are as a person, written to clearly differentiate this archetype from others.
- Critical context about when, where, and how they approach doing something related to your business goals or objectives (again, highlighting differences to avoid any type of “one-size-fits-all” mentality). Consider including information about their attitude, broader goals, core beliefs, and whether they seek a certain type of experience or just to get a task checked off their list.
- Specific barriers they face, things that make it hard or impossible to do the things they want to do in the way they want to do them. These are great jumping off points for new ideas and solutions.
The User Archetype Catalog we created for our project on how folks make healthcare decisions had eight unique archetypes, including a few surprising ones like:
Feeling Better Can Wait: I know I have some things my doctor or loved ones think I could do to feel better, but I can't really prioritize that at the moment. Taking more time or spending more money on tests or procedures just doesn't feel possible.
Fearing What the Future Holds: I have to do everything I can to stay as healthy as I can; I’ve known someone whose health deteriorated quickly and it scares me. The healthcare system seems like it wants me to accept "good enough" and stop trying.
Finding the Root Cause: I don't want to just treat my symptoms; I want to find out what's making me sick so we can address it at the source. Some providers seem like they just want to prescribe something and get you out of the office quickly. I'm looking for something or someone to help me investigate and unravel what is really going on.
Download the full archetype catalog to see all eight archetypes from Fathom Consulting’s ongoing healthcare study.
To remain useful, a User Archetype Catalog must be easy to update. As new interviews are conducted each month, they should result in a few tweaks, additions, or examples that make the catalog stronger over time and keep it tuned to the present moment. If the format isn’t conducive to updates, that’s just one more barrier to overcome.
In our healthcare project, we created a database where we tagged new insights and interview snippets with the relevant archetypes as we gathered them. That way we could easily pull together topic- or archetype-specific findings.
2. The User Needs Inventory
Continuous listening and the resulting user archetypes form a fantastic qualitative foundation for creating an inventory of discrete user needs. Extracting these needs from your notes on what each archetype is doing and what gets in their way is the perfect place to start.
Once identified, user needs can serve the product team in ways archetypes cannot, because they highlight specific things users want to do or feel that your product could (or already does) support. They can easily be used to jumpstart brainstorming and to evaluate ideas that arise internally.
Tips for Writing Strong User Needs
- Start with Functional Needs: Describe what the users want to do (or avoid), without prescribing a specific feature, function, or design. For example, “Receive a nightly reminder to log their exercise” is too specific. However, a user need that says “Receive adequate support to consistently log activities” is high-level enough to direct the team without boxing it into one solution or design pattern.
- Layer in Emotional Needs: Sometimes it’s not about what a user can do, it’s about what they want to feel. Do users need your product to help them feel secure? Connected? Independent? Starting from a list of universal human needs and feelings could be helpful if you’re unfamiliar with spotting emotional needs, but make sure capture only the emotional needs represented by the people you spoke to in your research.
- Where needed, add in the Why or So What: If a need is more of a sub-need of something else, consider whether it needs to be captured on its own. If it does, add the user’s ultimate goal or need (the “why”) to the statement, as in the third exaple below.
- Tie them to your User Archetypes: While user needs are more bite-sized, concrete, and product focused, they can still support building empathy and reinforcing the variety of user mindsets by tying them to specific archetypes that expressed that need. We did this by adding archetype titlees at the start of each need statement. Since more than one archetype often applies, you may want to manage this in a database or by tagging each need with its archetypes.
Here are a few examples from our project:
- As a person who is Fearing What the Future Holds, I need to feel like I am not alone and that there is reason to be hopeful.
- As a person who believes Feeling Better Can Wait, I need to remember that taking care of myself is important too.
- As a person who is Facing a New Reality, I need a clear and concise way to communicate my health journey to new providers [why?] so that I can feel understood and get high-quality care.
3. The User Journey or Ecosystem (Optional)
There are times when pinning your insights into a time-bound frame or a specific context can be informative, or even critical to their utility. For instance, if people’s mindsets or needs change significantly based on when or where they are interacting with your product or service, you may want to have an overarching map that pulls things together by phase or by context. Build this additional layer only if it helps you understand or share user needs with your team(s).
In our healthcare study, we felt that for the most part our archetypes’ mindsets were consistent, but their activities and challenges sometimes changed depending on where they were in relation to a healthcare-related experience—recovering from an injury or preparing to meet a new provider, for example. We could create a journey map with distinct phases or moments and tag each moment-specific need to the relevant phase. This would help product teams pull together a relevant subset of needs without losing the context of the user’s overall mindset and beliefs.
We could have instead thought about the healthcare ecosystem and captured how a user’s needs or challenges were distinct depending on whom or what they were interacting with—a provider, their insurer, or social media, for example.
There is no right or wrong way to zoom in or differentiate user needs, and it is always worth asking whether the deeper investment in mapping a user journey or ecosystem is necessary now or can remain an option for future exploration.
A sustainable, trusted resource
By maintaining these documents in your User Insights Library, you create a sustainable resource that research and product teams can return to for grounded user perspectives and input they can trust is relevant to their work.
We will cover more on user needs in our next piece—including a look at validating them through scaled qualitative research using an AI-powered tool to “interview” real humans. Then we'll get into using those same needs to brainstorm and “reality-check” new ideas. Stay tuned!
