Putting our user research to work
Talk to anyone working at the intersection of libraries, museums and digital, and you’ll hear the same refrain: “I wish we could do more user research, but…”
Time constraints, project budgets and not enough dedicated, in-house expertise usually mean institutions like ours have pockets of documented user research distributed across teams: audience insights, lessons learnt from previous end-of-project evaluations, and lots of verbal, anecdotal reports of user behaviour. We like to ask questions and find the answers, but what we lack is a joined-up picture of behaviour and needs over time.
This is the situation we found ourselves in when we set out to redevelop our websites under one flagship site at wellcomecollection.org.
Products, not projects
We started on our redevelopment by shifting away from one-off or isolated projects, into product development. Thinking of our digital platform as a product makes it a living, ever-evolving thing. We don’t want to build it and forget it; we want to continually make positive changes to the site based on what we know our users want and need.
That’s why we have a dedicated user researcher who works side-by-side with software developers, designers, data analysts, delivery managers and product managers.
How it works
The user researcher is a core member of our multidisciplinary product team. They lead on all aspects of our qualitative user research programme. That includes recruiting of research participants, shaping our research objectives, conducting face-to-face interviews and usability tests, running unmoderated online tests, and then drawing out insights to share with the team.
This is what we try to do:
- Talk to users every sprint (we run a two-week sprint cycle).
- Get the product team involved in the research process, and invite colleagues in as observers. We’ve started to use Jared Spool’s exposure hours as a success measure to ensure the users’ voices are embedded in our work.
- Use a variety of research methodologies — not just in-person interviews, but also task-based usability testing, informal pop-up testing, and unmoderated tests; coupled with A/B tests and anonymised usage data.
- Capture insights in actionable nuggets.
On the other hand, we try very hard not to:
- Strive for 100% confidence in our designs or irrefutable user profiles. To keep things moving, we need to be mindful of going too deep or too broad, trying to find out everything about everyone. As astutely pointed out by the team at Doteveryone, “Know when you have gathered enough to prove a point, and move on.”
- Create in-depth reports for posterity and/or the black hole of shared drives.
The important thing is to do just enough research to learn enough to move us forward, to reduce any major risks and to gain confidence that we’re going in the right direction.
The five big challenges
Keeping up with the pace of research isn’t without its challenges. We’ve got five big ones:
- Recruiting research participants who meet the relevant screening criteria, who are available when we need them. We have a small but growing user panel we can draw from, as well as our social media channels and external recruitment agencies. But it takes time and effort and needs planning.
- Inviting participation from disabled, D/deaf and neurodiverse folks, so often ignored in qualitative research. Without them it’s likely we’re missing out on key insights that would open Wellcome Collection to people who could be marginalised and excluded from participation.
- Striking a balance between multi-sprint discovery research with the week-to-week business of testing our work in progress (new designs, features and functionality, and iterative improvements).
- Absorbing new user insights into our UX processes: writing user stories, creating or tweaking our user journey maps.
- Creating a productive feedback loop with other teams who gather visitor feedback and generate and commission audience evaluation.
From sign-off to feedback
It’s taken us time to embed user research as a practice into our product development, but the benefits of doing so are showing themselves every day.
Being part of the user research process keeps the product team honest. When we observe research and testing as a team, we are all witnesses to the same experience. We might each pick up on different details, but by spending time taking notes and analysing the sessions together, we come to a shared understanding of where our users need us to focus our attention next.
Regular research has also allowed us to shift from getting sign-off to getting feedback. Rather than internal managers having the final say on quality or completion, users get to tell us what ‘good’ looks like to them.
By doing user research at least every two weeks, we’re getting user input that feeds directly back into our product development. User research shapes what services and features we build, and what gets priority.
This has significantly changed how expectations for ‘good’ are set and communicated to our internal stakeholders.
The timing couldn’t be more perfect. This change to how we work comes at a time when Wellcome Collection as a whole is thinking harder than ever about barriers to access and inclusion. We’re all looking at how we can improve the experience of every person who engages with us — and the organisation is developing a voracious appetite for understanding our users. It’s been rewarding to share our user research with our colleagues and to see user-centred design processes take hold across our museum and library.
Special thanks to Dr Hayley Thair for getting this post started with an early draft, and for putting our user research programme in motion. Additional thanks to Tom Scott and Danny Birchall for their feedback and editorial chops on this piece.
