Organizing your data and setting up the right structure for your Research Repository

Effective research repositories are designed with the end-user in mind. In this case, your colleagues and stakeholders. In this guide we will cover the following topics:

  1. Important concepts you need to know when implementing your UX Repository:
  • Tags
  • Properties
  • Labels
  • Projects
  • Research Summaries
  • Stories
  1. Mapping your stakeholders
  2. Using tags and properties to analyze your data.

Let’s get started! 💪

  1. Important concepts you need to know when implementing you UX Repository

Below you can find a brief description of some of the concepts you will need to know in order to build your Research Repository with EnjoyHQ.

👉 You can also access a spreadsheet with the content below here. You can use it as a template.

Purpose

Examples

Projects

A project is a workspace where you can add all the raw data related to your research question and analyze and write down your findings and insights.

Personas

New features/products

Hypothesis

Usability testing

Project Labels

Labels are used to organize your projects so they are easy to filter and find by colleagues. You can use multiple labels for projects, some teams combine labels that describe the type of study, the product or product area it relates to. You can use as many labels as you need.

Label 1: Usability

Label 2: Onboarding

Label 3: IOs App

Documents

We use the term "Documents" to describe data in EnjoyHQ. It could be a note, a video or an interview transcript. They are all documents in the context of EnjoyHQ. Normally this is your raw data.

Interview transcript

Survey responses

Support tickets

Research Notes

Video files

Highlights

Highlights are snippets of text that contain evidence that is relevant to your research question. Normally they are customers quotes describing their behavior or problems.

Customers quotes

Short Statements

Tags

Tags are mostly used for analysis. We recommend using tags for high-level classification

Feature request

UX Issue

Pre-Sales

Signup

Usability Problem

Onboarding

Bug

Upgrade

Integrations

Trial End / Non-Upgrade

General Feedback

Retention

Cancellation

Properties

You can think of properties as super tags. You can use properties to add more context to your highlights. They are very flexible in that you can create one property and associate multiple values to it. That way you can create patterns for classification.

Property: Sales Objection

Values:

No budget

No buy-in

Customer missed value

Internal Barrier

Needed more support

The critical feature is missing

Property: Product Area

Values:

Uploads

Exports

API

Check-out

Billing

Stories

You can think of Stories as mini-blog posts that help you capture your learnings and share insights with your team and the entire organization. You can think about Stories as more digestible research reports. For Atomic research fans, a Story is your unit of insight. It is the finding and any data point that can help back it up.

Story 1: Users that successfully add seven friends to the platform stay active and have more sessions than users that do not invite friends.

Story 2: User experience high levels of anxiety when booking a nanny outside their neighborhood.

Story 3: Colorblind users were unable to find the export feature on the dashboard.

Stories Labels

Labels are used to organize your Stories so they are easy to filter and find by colleagues. You can use multiple labels for Stories, some teams combine labels that describe the type of insight, the product or product area it relates to. You can use as many labels as you need.

In the same way, you use labels to organize your projects, you want to use labels to organize your insights. It is ok if they overlap, the idea is to make it as easy as possible for the rest of the organization to find information.

Label 1: Onboarding Experiment

Label 2: User Motivation

Label 3: Product Area

Project Summaries

Project summaries are the equivalent of your research reports. You can write a summary within a research project or you can also group a series of Stories and share them as the final outcome of your research.

Both the project summary and the stories have the same purpose, to help you share insights easily. The benefit of creating Stories is that you make your findings more digestible and you can link them to each other as you generate more insights. However, there will be time when writing a long summary document will be the best approach and that when Project Summaries can help.

You can always attach Stories to summaries anyway so they don't have to work separately. All read-only users have access to both Summaries and Stories.

Summary: Revised Personas for the Enterprise Segment.

  1. Mapping your stakeholders

Each user will be consuming and accessing research data and feedback differently and your structure should help each user to make the most of the repository. 

We suggest mapping the different users in your organization and the level of access they will be granted. Think about this mapping as a first draft. Permissions and access will change over time and EnjoyHQ provides a lot of flexibility when it comes to changing user permissions for users.

You can also access a spreadsheet with the content below here You can use it as a template.

👉 The table below is just an example. You may give access to different people based on your internal structure, data governance, and organizational culture.

Team Members

Access to Raw Research Data Data

Access to Customer Feedback

Can modify Taxonomy

Access to Reports/Stories/Insights

These are all the people that may use or benefit from having access to your Research Repository

This is data gather by the researcher via interviews, usability testing, diaries, and any other proactive research activity.

This is the raw data coming from integrations or uploaded to the platform (Surveys, forwarded emails). This data has been gathered directly from customers with no analysis or interpretation.

User can create, rename, change or delete tags, properties, sentiment, labels or customer information

These are research outcomes, for example, Research Summaries, Stories, Presentations

Researcher

Yes

Yes

Yes

Yes

Designers

Yes

Yes

Yes

Yes

Engineers

Yes

Yes

No

Yes

Product Managers

Yes

Yes

No

Yes

Marketing

No

Yes

No

Yes

Executive/Leadership

No

No

No

Yes

Support

No

No

No

Yes

You can learn more about user permissions here

  1. Using tags and properties to analyze your data.

EnjoyHQ allows you to classify your feedback and research data in few different ways. From high-level ideas right down to the golden nuggets of information, you need to make better decisions.

👇👀 Watch the video below to get a quick summary of what you can do with tags and properties.

Using Tags to organize your data

The most useful and popular way to organize your data is using tags. Your tags may come from different places. For example, if you connected integrations to your account, EnjoyHQ will import all the tags available in those integrations, that way you can take advantage of the classification that has been already done by some of your team members. You can also create tags manually or assign them automatically with rules.

Tags can be also assigned to parts of the documents, by highlighting and classifying them:

Tags assigned to highlights will be also added to their parent documents. This ensures consistency of classification on both levels.

In some cases, you may find that your tagging convention is not as useful as you thought. You may find inconsistency in the way tags are named, especially coming from your customer support system and other tools. 

That's a common issue that can be solved by using EnjoyHQ's tag manager. The tag manager can help you rename, merge and delete unwanted tags so you can build consistent reports. Learn more about the tag manager.  

Using properties to enhance your classification

You can think of properties as super tags. You can use properties to add more context to your highlights. They are very flexible in that you can create one property and associate multiple values to it. That way you can create patterns for classification.

For example:

Property: Product Area

Value: API

Value: Onboarding

Value: Account settings

Because of the flat structure of tags, it's hard to encode hierarchies and more complicated taxonomies. This is where properties come into play as an addition to tags.

Example taxonomy

Tags represent the high-level classification of documents and highlights - in other words, tags describe the nature of the piece of feedback. Properties are then used for more in-depth classification which adds more meaning to high-level tags.

For example, a document is tagged with the tag feature request then you can add the following properties to provide more context:

Properties:

  • Priority: high
  • Product area: search
  • Status: In development

Properties can be assigned to full documents or highlight snippets:

To help you build a useful taxonomy we created A Practical Guide to Building Taxonomies with plenty of examples and guidance. You can read it here

Complementing your classification with Customer Segments 

Classifying your data is just the beginning, the second step is to understand who is behind the feedback. Not all customers are equal so being able to filter your feedback by your most valuable customers or most active users can help you prioritize work and make more strategic decisions with the data you already have.

In EnjoyHQ you can create customer segments and visualize customer request or complains per segment. Learn more about creating customer segments here.

You can build customer segments by grouping customers by similar customer properties such as the price of their subscription plan, location, engagement metrics, persona, etc. All these characteristics can be imported into EnjoyHQ from your integrations or using our API.

👉 Interested in learning how EnjoyHQ customers manage their feedback and build customer-driven cultures? You can read success stories here.   ☎️ You can also book a demo here


How Did We Do?


Powered by HelpDocs