Mental health and wellbeing for user researchers
Opinium recently published an article which focused on mental health within the workplace, where the majority of respondents worked within the research sector. There are some terrifying facts held within it, but the one that stood out to me was that 85% of researchers said that they struggle with their mental wellbeing. Of those, 77% said that it affects their ability to do their work. The struggles they have faced included: feeling low, anxiety, stress, burnout and panic attacks.
The main causes that researchers listed were:
- The risk of something going wrong
- Unclear expectations
This really hit home for me, and in light of World Mental Health Day, which took place last week, I have decided to share why.
About 4 years ago, long before I joined Paper and the digital industry, I burnt out so badly that I eventually had a breakdown. My breaking point was that I was working on an R&D project where I had a huge workload, very little support or guidance and a lot of responsibility to deliver something that was perfect and, of course, profitable. When I spoke up about how hard I was finding balancing stakeholder expectations and the reality of the product I was developing, I was told to “keep pushing on”, that my team were “relying on me” and that I couldn’t “let my client down”. So I did, and eventually I burnt out. I barely left the house for 6 months; I had constant panic attacks. The extent of my anxiety lead me to depression as well.
It’s been a very long and difficult time trying to recover from that breakdown. I’m doing a lot better, but often those feelings come back. Research is my passion and I find so much joy in it, but I do have to remind myself that I can’t know every answer. I’ve also learned that I need to be open and honest about why research can be so emotionally draining, and why sometimes it can be hard to maintain mental wellbeing while I do it.
To that end, this article should help any overwhelmed, stressed or emotional user researchers to feel less alone. It’s tough work and we should talk about this as a community. We all need a support system, so I hope my insights can help you start a conversation with the people you work with.
The risk of something going wrong
The issue I struggle with the most is the risk of something going wrong, and I often struggle to separate that there is no “wrong” result of research from the fact that I want to support my team’s work with insights from users.
Research is uncertain and unclear by its definition. We start projects knowing who we want to talk to, what we’re researching and have a hypothesis of how users may react to our services; but the outputs are unpredictable. We are dealing with people after all, and they have the agency to make their own decisions.
We set out to solve a problem, but ultimately we have to respond to what we actually find through our research. The question then becomes - do we put that finding to one side and focus on the problem we were brought in to solve? Or, do we advocate for the problem that actually needs solving?
It takes a lot of confidence to go back to your teams, clients and stakeholders to say that the results you’re finding aren’t necessarily the results they wanted or expected
Research results are unpredictable and a researcher’s job is to understand users, hypothesise about why our assumptions were wrong and then represent our users’ experiences and needs to our teams.
When you start to combine this unpredictability with some of the typical traits of a researcher, you can see friction. Researchers are trained to think about what people really mean, to observe their behaviours and to think about everything from someone else’s perspective. If we struggle to shut this view of the world off, we can be prone to analysing the people we work with and becoming susceptible to team stress and pressures that we cannot solve.
The confidence required to tell a busy and pressured team your ‘inconvenient’ results cannot be understated. The solution to this challenge is to find a way to represent your findings in a way that means something to your team, and communicates why what you found is important. This adds a whole other stress of finding the headspace and creativity to pull together personas, user needs and insights.
How do you take 2 weeks worth of quotes, and make them relatable to a team who may not have seen users interact with your design?
Most of the teams we work with truly value research, which is amazing, but it brings pressure to do research perfectly. For teams that aren’t as sold on user research, we face the pressure to justify our methods and our findings on a regular basis.
It’s a lot to think about, and there’s a lot of things happening at once. It’s enough to make the most calm and collected among us feel anxious.
Workload is another problem that I very much relate to. I’m a perfectionist, and I don’t mean this lightly. Not only am I a perfectionist with my own work, I also think so ‘big picture’ that I end up carrying the weight of an entire project on my shoulders. Moreover, I don’t like to form an opinion until I have all the information, which means I want to speak to all of the users, and often don’t allow myself enough time to properly analyse, report and present back everything I’ve found.
So, when I feel like I have a lot of work on, I tend to spiral. I can’t settle into one task and instead find myself rushing between usability sessions, writing up notes, trying to pull out insights and thinking about which users I want to speak to next.
Agile ways of working should alleviate some of my spiraling woes, and generally promote mental wellbeing at work… It reduces the amount of work in progress and promotes focusing on one thing at a time, and doing it very well. It should make us more efficient, especially when you consider that it takes most people around 25 minutes to resume a task after context switching.
It also encourages transparency as teams share their progress, ask for help and reflect on how they’re doing over set periods of time through retros.
Agile also stops us from looking too far into the future, which for anxious people, often means worrying about ‘what if’ situations and spiraling. Accepting and acknowledging uncertainty in life is one of the healthiest things you can do for your mental health.
Structuring Agile research
When you think about how research is typically structured though, you may spot some issues with making it fit neatly into an Agile methodology.
The process of researching is traditionally timebound by a set end-date, and not by ‘sprints’ to track progress. Most academic or market researchers wouldn’t set themselves 2 weeks to complete one of the above phases, much less say with confidence that a phase is “done”. Most researchers will say that research is done when it’s finalised and written up, and most will caveat that it’s done “for now”.
It’s a special kind of pressure to try and fit research into a sprint framework. One option is to put all your various tasks into a backlog and explain at every planning session why it’s not done yet. Another is to set a sprint per task type, like ‘conducting research’ or ‘analysing research’; but this leaves you open to a lot of task switching, as it’s unlikely that your workload or users will (or should) stick to the pattern you have created.
So what’s next?
I don’t have any real solutions to these issues of workload, ambiguity or advice on getting research to play nicer with Agile ways of working.
All I can do is talk about how Paper has helped me overcome a lot of my anxieties, and how we work to ensure we’re all looking after our mental health:
- We encourage check ins every morning. Sometimes this is exclusively about how we’re feeling, but sometimes we talk about specifics of our day that we’re concerned about. It’s a lifesaver when you have 4 user research sessions or a day of meetings, as it gives you time to focus on how you feel and prepare for how that may impact your day.
- We try and only work 4 days a week on projects, and have a day where we work on Paper tasks. Like this blog post! We also have time to do R&D work or training. For me, it gives me a break from overthinking the details of my work and helps me feel refreshed.
- We have a weekly planning session where we share what’s happened in our week, how we felt and whether we need any help from the rest of the team. It helps us stay strong as a team, even if we only get to spend a day a week together.
- We remind each other that we can’t be solely responsible for everything. We encourage each other to do our best, but that some things are out of our control.
- We mentor each other, and are always available to talk through problems and offer outside opinions. We’re normally all on different projects, so we often have someone we can ask that isn’t too close to our workload.
- While we work in Agile, we focus solely on research and design so there’s a lot of shared experience of structuring big picture thinking into sprints. We always share what’s working well and how we handle sprints.
- We spent time writing user guides for ourselves, to make sure we can be mindful when offering help to the person who is struggling.
The wonderful Paper team