Hello!
This post is going to be slightly different to others I’ve done where I take a well known pop culture metaphor, strangle, stretch and mangle it until it fits my narrative of how product development is just like Arrested Development/Spongebob/Gremlins 2: The New Batch. With us approaching the end of the year I thought it might be interesting to some to share my current processes and ways of working, whilst there likely won’t be many snarky Muppet memes I think it could still be useful to some, or at least interesting to those who want to know more about how I do my job. There have been a fair few (at least more than 5) who have reached out to me on Linkedin or Twitter about what my role is, how I got into it and what I actually do, so alongside the reading material I share with them (remember shy bairns get nowt and all that), I thought this could be interesting, or at least cathartic for me.
This could also alleviate or compound some of my imposter syndrome, we won’t know unless I’m feeling contented and floaty or hiding under my desk behind a barricade of indifferent cats. So let’s get on with things.
Planning stuff
When conducting user research my approach to planning remains fairly consistent. Find out who the stakeholders are, why they want something investigated or reviewed and gathering as much context about the work as I can. I want to know the preconceived notions or hidden motivations as to why people are wanting the research carried out. I’ve been in the unfortunate position in the past to be told what the research was going to say prior to it being carried out, with the user research just being done to check a box. Whilst people may have notions of what they’re going to find out or what their users are going to say, it’s sometimes difficult to drag it out of them prior to starting research. I know some of my colleagues prefer to go in completely blind so that they’re not influenced, but as a preference I like to have everything tipped out on the floor so I’m aware of all motivations, assumptions and secret hidden biases people have before starting on the research - the important thing is to note, acknowledge and be aware of them.
Ways I practically do this is throwing everything at the wall, sit with the team and get them to share everything they know, think they know, believe that could be true on post-its and share it amongst the team. Depending on the team this can be facilitated by myself or someone independent who I work with creating a workshop guide. The outputs of this work will help me define my approach, write any discussion guide and also understand the team’s knowledge around the problem/opportunity, the users and the constraints the project may be facing.
When working in a team I ensure that I get the support to take as much as the team out with me as possible. This pays off in many ways, it puts team members in front of those they’re wanting to build products and services for, it brings other perspectives to the research and it also helps to have people who may be subject matter experts alongside you. To be clear they’re primarily observers to the research but they’re also encouraged to ask non-leading questions and take ownership of the research; I may be the designated user researcher but we’re all finding stuff out together. To ensure I get the time needed to get the team to join me in research - whether it’s for a new project or evaluating an existing service I work directly with the product management side of the team to ensure time is prioritised for the team to speak to our users. Time of colleagues is incredibly valuable and there are always fires to put out, however research and speaking to users is prioritised accordingly - speaking to the users and stakeholders is not the job of ‘the UX people’, everyone does it, and it leads to better results.
Practical stuff for planning too - do I need consent forms? Do I know who the users I’m speaking to are? Do I need to have conversations with marketing/sales/management people to unlock doors for me? - as an aside to this, I’ve seen this blow up all kinds of wrong a designer randomly rang a group of users to set up usability tests, when in actuality they were already speaking to senior management about how unhappy they were…
In short: tip out all the Lego on the floor to see what you’ve got, but ensure that everyone is involved in this to be transparent, but, also to show that you’re being open and transparent.
Finding stuff out
Qualitative Interviews
Everyone comes out to do user research with me, the research is not mine, it belongs to the team. Usually the way I like to conduct interviews is in person where the people we’re speaking to are naturally based, whether it’s a workplace or home, alternatively somewhere where they’d be interacting with the thing we’re working on. There are benefits to getting your users in house to see how the sausage is made, meet teams on our own base and see how we work, even dropping in some of the C-Suite to say hello, but by far the biggest gains and most insightful discoveries have been sitting with their users in their own location (or creeping remotely using video-conferencing/screen-sharing technology).
Whilst I don’t believe that my methods fully follow ethnographic research methods (we still have stuff we directly want to find out), I do believe that following this method yields great insight and actionable results.
The way I approach the conversations hasn’t particularly changed much in the past few years when conducting research - I’m trying to find out answers to core questions:
Who are the users?
Within this: where do they sit within an organisation? What kind of team are they in? Who are their users? Who are their stakeholders?
What are they trying to do?
Within this: what are their actual goals? What are their appetites/aversions? Why are they doing this?
How are they currently doing this?
Within this: what are the processes? Where does the thing that our team are looking to understand sit within this? What tools do they use? Are there any necessary constraints? User process maps are usually created at this time, often built with the help of users directly.
One key question I’ve found incredibly valuable during this is ‘show me how to do this as if it’s my first day joining your team’ - this allows users to show us how it’s supposed to be done, but also, how they actually do it.
What currently works?
Within this: understanding their journeys, the positives and benefits of current processes.
What can be improved?
Within this: what’s actually wrong with the way things currently function? What constraints are put on to teams, and why are they done this way? In this section I often break out the ‘If we had a magic wand, how would you see it working?’ - it often creates fascinating results of how users envision their work.
Specialty questions
These are often related to something specific to the project if it hasn’t automatically come up through conversation, probing in to a specific problem where we think there’s more information to be gathered.
Their questions
At the end of an interview/session I always give those we’re speaking to the opportunity to ask us questions about our work and or project, sharing what we’re doing and how what we’re doing could potentially positively help them in the future.
The way I conduct this research is typically longform conversations that take approximately an hour with myself and a team member shadowing me. I primarily lead the conversation and take notes whilst the other team member takes notes which we combine once the session is over.
Tools I typically use to do research with - if on site with people, pen and paper. I find it easy for me to keep conversation going with brief notes written down that I can refer back to. I use quotes from users as anchors to grab on to and build narratives around - I find that this helps create a well rounded view of the entire situation whilst also understanding any emotions around the narrative.
When remotely conducting research I do like users to share their screens and have their cameras on if they feel comfortable, but it is not a prerequisite. The situation should be one that enables free flowing conversation which is safe and honest, if cameras preclude that, they’re staying off. I still use pen and paper for most note taking, but also if possible have a shared document open with any observers or other note takers to save time later on.
If possible I like to record sessions using tools provided, getting informed consent prior to the session and again before recording commences, this helps as a reference and resource point in case there are any further questions or we want to share with the team.
What I’m keen to press here is how the conversation, whilst structured, remains a conversation. You’re speaking to humans with frustrations, thoughts, stories and ideas, simply reading a sterile list of questions and anticipating one word answers in return is not a positive experience for anybody.
All that jazzy quant
Over the past year I’ve been lucky enough to work with data scientists who can do amazing technical wizardry with quantitative data (although they claim it’s easy and just a load of self-taught Google-ry, they’re humble as well as incredibly intelligent). Previously my quantitative knowledge was limited to running surveys and reviewing outputs from Google Analytics or similar in A/B testing - now however I work with wondrous data people who can help me understand far more.
The way that I work with data scientists is simple, I engage them early, share the whole problem and be honest with what we’re trying to look for. Beyond surveys and try to understand behaviours of people en masse. Instead of going directly to data people with a ‘yes no’ question, I share what we’re trying to find out and work together to build hypotheses, questions, assumptions and an idea of what we’re trying to measure. From there we define an approach and methodology that works, with a representative sample size to gather insight. It’s a collaborative approach that works and creates and shares insight across teams.
There are loads of other ways to gather insight and find out what matters to users, but I realised part-way through writing this blog that it would be never-ending (or at least too long for one post) if I listed everything I do, so you know, probably best to play the hits. However, some other techniques which are worth mentioning:
Card sorting
Building user journeys with users on site
Building a new service from scratch with users
Testing products with users on site
A/B testing
Content versioning
Clickable mocks
Focus groups
Workshops
Wow, yeah., there’s, there’s more than I plan to write about, but yep. *points*
Thinking about things
Analysis is a large part of the role, what do I do when we’ve got the raw materials, the insight, the stories, the ideas, the frustrations and the long list of wants from users and stakeholders. Well before we get to that bit, let’s take a step back.
One of the benefits of conducting research as a team is sharing our thoughts following interview sessions. Speaking to each other on what we observed, what we think the top takeaways are and if we’ve spoken to multiple people - what are the narrative threads and similarities. Having people who were also in the room to bounce ideas off and add fresh perspectives is incredibly valuable. Ensuring we don’t fall down a rabbit hole of thought and end up lost, speaking to people who were involved straight helps clarify the main talking points throughout the day and gives some guidance on how to conduct the analysis.
Typically when undertaking analysis I like to throw everything we found out on to post its and then cover the wall to allow me to think things through in an open environment - the pandemic has limited the space for me to do this, but I have managed to convert a little wall in the house to meet these needs - next up a whiteboard! By rewriting everything out I remind myself of what was said, observed and what we took away from the sessions, bringing them back to life in a more objective and clinical way, allowing for reflection away from the actual situation.
I include notes such as what the setup of the rooms were, the technology used, any emotions and draw out the process - it’s at this time I like to draw out what I think the themes are from the day and find out what the core user needs are of everyone involved. By simplifying whole journeys - not limited to our involvement - we can understand what’s most important to users and what they’re trying to achieve, alongside why it matters to them. We must get a full well rounded view of those involved to understand their motivations alongside the impacts of any changes that might occur.
To say this is ‘thinking time’ could be reductive, but I don’t think it is, it’s time in deep thought where I start to draw out journeys, points of contact, friction and success. Once I understand the motivations I try to work through what’s stopping people from meeting that in the easiest way possible and why that’s the case. To help me think I usually include some kind of music, most likely film and video game scores, angsty emo or old talk radio on YouTube as background. This is known commonly in the office as ‘Jason has his headphones in and is writing stuff on walls’, so you know, ‘thinking’ is probably a good way to describe it.
Once I’m happy with the first pass of the analysis I run it by colleagues who were out on the research with me to gather their thoughts, I am more than willing to be told I’m wrong, but also will defend my thinking and how I arrived at the conclusions. Their insight and thoughts are crucial, whilst I prefer to ‘just get my head down’ I do encourage others to add to the wall of notes and themes.
The typical outputs I have from this is a group of key themes - likely no more than 5, of what matters to our users, this analysis allows me to show what matters to users in a quick and effective way. Thematic analysis is not for everyone but I’ve found it possibly the most valuable tool alongside quotes.
Quotes from users are beautiful things, they’re the voice of your user, direct and honest. They can convey something eloquently, evocatively and engaging, in a way that a GANTT chart could never do. Quotes from users stick with you and the team, I still remember some wonderful quotes from users on previous projects that have long since passed. If you can’t have a user directly working within your team, bring their voices in loud and bold so people don’t forget them.
Sharing things
So following planning, conducting research and then undertaking analysis - how do you show what you’ve done to make it impactful? The answer, as it is most of the time, a very unsatisfying - it depends.
Who are you presenting it for, why does it need to be presented? Is it something that can change? Or is it an end of project report that will stand as an authoritative artefact? Are the people getting the outputs of the work, your team or other stakeholders?
Your stakeholders have needs too, some of them want the work to be all neatly tied up in a report that gives clear next steps, some want options to potentially follow, others want to ‘walk through the process’, others want fancy journey maps and personas. There is no magic bullet to present research findings as stakeholders' needs are sometimes as varied and colourful as the needs of your users you’re interviewing.
So instead if listing EVERY way you can present insight, how about some of my favourite ways that people like and seem to work.
Wherever possible I try to carve out a piece of the shared whiteboard or digital equivalent with all the ongoing and upcoming work, plans and the insight. As mentioned earlier, being seen is a big part of user experience work to show that it is going on and is being measured.
As part of our job is to tell stories and narratives of those we’re looking to serve I am a big fan of engaging visual methods. Using Bikablo visual facilitation methods has helped me greatly in this. Bikablo is primarily to be used in facilitating workshops in a different way, however I have found it incredibly useful in presenting research findings - either within the office on a dedicated space and or presenting insight in shared decks.
The Bikablo style-drawn decks I create are primarily to be presented and not read, due to the style of it, space is at a premium and I must present the most pertinent and relevant information. Instead of relying on reams of text I must present what I want to get across to stakeholders. It allows creative freedom and visual metaphor. Each slide is different although I use templates for some. It remains uncommon so can be visually striking and arresting, I’ve been told that it ‘has character’ so I’m going to keep that as a compliment.
One issue with the style currently is that it’s not wholly accessible, so I am working on providing additional text to accompany it to ensure everyone can share the information.
Personas are a divisive tool, I like to use them as guides but not as precious artefacts to not be challenged. Personas can be spun up and used then quickly disposed of. These people are based on real people, but they’re made up, so have fun with them but also make sure that they don’t become a blocker. I have three persona templates I regularly use, primarily as wide ranging proto-personas based on core user needs. They contain user quotes, user motivations and user frustrations. They may not involve the actual product at all if it’s not relevant to them and their journey, at least from their perspective.
To make them more engaging I name them after obscure famous people, the real names of 90s wrestlers, drag queens, characters from soaps or obscure sitcoms. All have images of people using thispersondoesnotexist.com to put a (not real) face to our users.
An additional method that I’ve found successful in conveying needs, particularly relating to emotion and frustration is using memes. Yep, behind every snarky or funny image is an actual message, and what’s more engaging and disarming potentially frustrated stakeholders than a meme. A picture may say 1,000 words, but memes will relate to your audience and stay with them at a base level in a way that will be more effective than a 1,000 word report.
Finally, I ensure that user research is presented as much as it can be, whether at stand ups, reviews, show and tells, retrospectives and planning. We share our findings with those we spoke with for the insight, senior leadership is encouraged to review and engage with findings.
And that’s it
So yeah, that’s a whirlwind (checks page count, 7. Dear god, 7.) guide through what I do and how I do it. I hope that you’ve found it interesting, insightful or just have a better idea of what I do day to day. So with that said, I’m always trying to learn and try out new things, if you have any ideas or methodologies that work for you, I encourage you to share them.
Thanks everyone!