Building a UX repository
Implementing an insights library that even non-researchers love
Imagine this....
Eve, a designer, is drafting the login flow for the member area. She is unsure which elements are best to build trust.
She brings it up in the design team weekly. Gus remembers that there had been user tests on trust indicators but since he had not been in the company yet he does not know any details. He refers Eve to Mike, who has been working longer in the company.
Mike remembers that a test on this was conducted by Susann and that one type of certificate was considered more trustworthy, but he does not remember which one. Susann left the company a year ago.
Eve searches on her own for files documenting the test but onl uncovers a Miro board stuffed with chaotic notes.
Project steps
How to build a UX repository
Let me talk you through it
1. Need realisation & buy-in
Why do we need a repository?
The first step was to convince the lead & management of implementing a repository to get resources (budget & time). The communication focussed on the following aspects:
Without repository, a company's knowledge about user needs (& where to find it) is exclusively stored in the mind of individuals.
-
if the right people are not asked, it will not be found
-
when people leave, so does their knowledge
-
in case people remember, their memory is biased & incomplete
-
the insights of tests are not connected
-
all of the above leading to duplicate work, thus waste of resources, or non-data based decisions risking success
Beyond preventing duplicate work,
a repository boosts collaboration.
-
ideally, anyone needing it can access, also non-researchers
-
ideally, it allows people outside the research team to also contribute to the company's body of knowledge
-
this easy access opens the possiblity for collaborative analysis: teams might reach diverse & unique conclusions of which researchers or single teams could not have thought of
2. Finding the right tool
What is important for
OUR repository?
After getting green light by the management, I set out to find the right tool: what are our needs? What would it need to be able to do? I identified:
4 key requirements
1. It should be aligned with UX research models (e.g. atomic UX) in strictly forcing the user to distinguish between fact, problem description (need/pain), and possible solutions.
-
Why? Preventing fruitless discussions where everything is merged to statements like “Users want to have an option to register digitally”. Here it is not clear where the fact ends and the hypothesis starts.
2. Collaboration: It should be easily sharable, accessible & learnable by non- research stakeholders like product managers and designers, rather than supporting research processes within the UXR team.
3. Scalable & dynamic: It should be easy to connect findings across several projects with updating and flexible linking, instead of a static documentation.
4. Budget friendly & concise: Focus on the features needed and thus not paying for non-required features e.g. it was not necessary to support the whole research process (e.g. video transcription).
After extensive desk research, demo meetings & tests of various tools I reached the conclusion that >>Glean.ly fits our needs best (see table).
3. A new way of working
Integrating the repository documentation into the
research process
From setting up the repository tool Glean.ly on, I have been documenting every user research project according to the Atomic UX Research framework.
STEP 1:
-
protocol each user test (complete annotation)
-
clean, translate & tag each testimony statement
STEP 2:
-
import the notes as FACTS into Gleanl.y (grey boxes)
= this is what users said or what was observerd; this is indisputable
STEP 3:
-
deduct INSIGHTS & connect them with
associated facts + connect them across tests (blue boxes)
= this is what we learned,
this is the usability problem/user pain
STEP 4:
-
deduct RECOMMENDATIONS or suggest solutions that could solve the issues found in the insights and connect them across tests (pink boxes)
= this is what we want to try out aiming to improve
Result after a 18 months
1689
facts
407
insights
135
recommen- dations
A growing network of insights across all user tests
-
some connections stronger, more reliable for decisions
(more findings confirming)
-
other connections weaker, indicating more research is needed (fewer / contradictory findings)
4. Sharing & collaboration
After about a year of collecting content, I started spreading awareness within the company. I presented a relatable case study with concrete examples in various settings and for various stakeholders, e.g.
-
tech talks for software engineering
-
product management meeting rounds
-
on the big stage on our company day in front of all coworkers.
At the same time, I started onboarding of the design team (individually and in detail) in workshops and 1:1 sessions. I am planning to roll out the onboarding process to product managers and cross-functional team members.
Signs of growing impact
-
a product manager (so non-researcher!) is contributing their key A/B test results to the repository and connecting them to qualitative UXR insights
-
other product mangers & cross-functional co-workers regularly explore it to check for relevant insights to base their decisions on
-
leads & management approach me regularly asking
“Do we already have insights on xxx?”
Then I can just share search results directly from the repository!
Happy End!
New scenario:
Eve, a designer, is drafting the the login flow for the member area and is unsure which trust indicators to display.
After a short onboarding to Glean.ly by the UX researcher, she starts exploring all the insights related to trust right away.
Afterwards, she can make the
informed decision to place a specific certificate at the landing page, the trust pilot widget close to the call to action, and to display the company's phone number in the top right corner of each screen.
