Tag: gds

So, you’re going to be a user researcher: top tips to get you going

Leisa Reichelt

Originally published on the  GDS User Research Blog

More and more teams across government are putting user needs first and the demand for user researchers is high. In some parts of government, people who haven’t had any experience doing user research have now taken on this role. If you’re one of those people, this blog post is for you, and for your managers.

Welcome aboard

The first thing to say is, welcome aboard! Many of us think that doing user research is a rewarding career.

It’s exciting to see the user research capability within government growing and maturing, and we hope you’ll help us shape it in the future.

More to it than meets the eye

User research may seem pretty straight forward – find some people and ask them what they think. How hard can it be?

As with most things, you’ll find there’s much more to it than first meets the eye. Being a good user researcher is a craft, there’s much to learn and it takes plenty of practice.

Many of the researchers in my team have more than 15 years user research experience. They’ll be the first to say: “There are still things I’d like to be better at.” We’re all still learning,  everyday.

So, get stuck into learning your new craft with vigour. Don’t simply do what the person in charge of your project tells you to do. Very often, they  don’t know much more about user research than you do.

Here are some tips to help you get up to speed as quickly as possible so you can bring the real value of user research to your team.

Things you should read

If you’re new to user research, there are lots of quick, easy-to-read books that’ll get you off to a great start.

The essentials

Steve Krug wrote two books that every user researcher should almost know by heart.

Read a couple of these…

Choose one of these books as a good and fast introduction to how to approach user research in projects. They’re both great books.

These books will help you with the all-important techniques for facilitating user research sessions. You should read at least one of these.

Invest in these books…

A bit more of an investment in terms of time and money, but these books will give you a really thorough insight into how good user-centred design should happen.

Every user researcher worth their salt has also read…

The Design of Everyday Things by Don Norman. You’ll never see the world in quite the same way again.

Things we’ve written – you should read these too

There’s a lot of useful guidance on the GOV.UK Service Manual.

Plus, some blog posts you should make sure you’ve read:

There’s your ‘homework’. It’s a great place to start, but there’s more you can do.

Find your tribe

Cross-government user research meetup

There’s an active community of user researchers in the UK government. We talk on email and we get together at meetups where we learn stuff, do show and tells, ask questions and share knowledge. Everyone learns as a result. If you’re doing user research within the UK government, you should join the community.

Find a mentor, apprentice yourself

Exposure hours: 2 hours 6 weeks

Make sure you work with someone who’s an experienced user researcher.  This will make the biggest difference to your progress.

Ideally, your organisation will only hire people with no experience if they already have people who have lots of experience and who can mentor and support you.

Sometimes you do find yourself without much support. If that happens, there are two things you should do:

  1. Ask the organisation to hire an experienced user researcher. Even hiring an experienced contractor to work with you for a few months will make an enormous difference in your ability to develop as a user researcher. If you can get someone like this on the team, spend as much time with them as possible. Watch what they do, have them watch you and give feedback, ask them lots of questions about what you’re thinking of doing and why they’re doing what they’re doing. Be like a sponge.
  2. If you can’t get someone with user research experience into the organisation, use the network to find someone else in government to mentor you. We’re a pretty friendly bunch who want people to do well, and do user research well. Ask a good user researcher if you can shadow them a few days each month, and if they can visit you and give you feedback on what you’re doing.

We actually encourage all user researchers – even the experienced ones – to spend 2 hours every 6 weeks watching other researchers or being watched. The best thing you can do is find a mentor to work closely with you. You might want to use the government user research community to do that.

Training is a good starting point

Doing a training course is usually the first thing that people think about. Training is good, but it’s just a starting point, it doesn’t mean you’re really equipped to take on the role without support.

 

You don’t have to be the expert on users

User research is a team sport

Probably the most important thing to remember is that it’s not your job to be the expert on users. Rather, it’s your job to know the techniques that will allow your entire team to become expert in what users need – and need us to do – so they can easily interact with government. User research is a team sport.

And last but not least, enjoy!

Anatomy of a good sticky note

Leisa Reichelt

Originally published on the GDS User Research Blog

For many of our teams, the ‘unit of data’ in qualitative user research is the sticky note – or, more precisely, units of information captured onto sticky notes. People often think this is amusing, given we’re always talking about digital by default.

Using sticky notes to analyse research helps us take a fast yet thoughtful and collaborative approach to analysis, and in a way that no digital tool I’ve come across allows. There’s just something about moving bits of paper around…

As a result of making and analysing so many sticky notes, we’ve become a bit opinionated about what a ‘good’ user research data sticky note looks like.

There are good, bad and downright useless ways of recording data onto sticky notes.

Here’s what we’ve found works best:

  1. Capture verbatim quotes or direct observations. Don’t make analysis notes on the sticky note. Capture exactly what you’ve seen or heard the participant say. Let the sticky note become the voice of the user.
  2. One data point per sticky note. No bullet points. During analysis, you need to be able to independently move quotes and observations around, so don’t group them on one note.
  3. Code sticky notes with a participant ID. Mark each sticky note with a code that will help you identify which participant said or did the thing you noted. An easy way to do this is to number participants in the order you see them. Our sticky note example shows a number 5 – this note refers to the 5th participant in the study.
  4. Use colour thoughtfully. Colour coding can be very useful when you’re doing analysis, so think about how to use it meaningfully. We capture all observations on one colour sticky note, then use a different colour to indicate findings and another colour for actions. Some people like to use different colour sticky notes to indicate things that went well and things that were problematic. Other people use colour to indicate different types of participants, for example, ‘confident online’ and ‘not confident online’.
  5. Thick pens. Match the thickness of your pen to the size of your sticky note. Never use a biro. We usually use 3×5 inch sticky notes and a pen with 0.5mm width.
  6. Encourage observers to write in capital letters. Although it’s slower, it makes everyone’s handwriting more legible, which is important when you’re doing analysis.
  7. Decent quality sticky notes. There’s nothing more annoying than having your sticky notes rain from the walls while you’re trying to do analysis. When it comes to sticky notes, the glue really matters and you get what you pay for.

Follow these guidelines, and you’ll be set for a great research analysis session.

Sample size and confidence: how to get your team to trust qualitative research

Leisa Reichelt

Originally published on the GDS User Research Blog

If you’re doing qualitative design research, don’t worry about sample size. Sample size and statistical significance don’t matter*.

The only thing that matters is how confident your team is about the next decision they need to make** 

You might get that confidence from watching 2 people.

You might need to watch 20.

You might need to watch 20, then check your hypothesis at a larger scale with a survey or analytics.

It all depends on the confidence of your team.

There are only 2 things you need to do to start building confidence in your next decision:

  1. Start watching end users using the thing you’re making. (Do research in every iteration.)***
  2. Make sure enough of your team observe the research. (Research is a team sport, help your team get their exposure hours.)

As soon as you start doing this, you’ll be so busy working out what to do with everything you’re learning, you’ll have no time to worry about statistics.

You’ll know what is broken and what is not, and you’ll know what you need to spend more time learning about.

It’s as simple as that.

Footnotes

* Obviously it’s better to see a lot of people over very few

We recommend you see a handful in each iteration – keep iterating, and you’ll gradually get a larger and broader sample. Also, the ‘Is 5 people enough?’ question often discussed by usability people is irrelevant when you’re seeing 5 people in every iteration.

** Your next decision might be…

  • How do we fix the question in this form so that people can answer it better?
  • Is this service meeting the user needs?
  • What is the next most important thing we should prioritise in the backlog?
  • Does this work better than what we’ve currently got live?

*** Who do you watch?

It’s tempting to launch into a complicated segmentation exercise. Don’t do that. There will be some obvious segments – just start with those. Start talking to people and the segmentation that really matters will emerge from those discussions.

The important segments will sometimes be things you couldn’t have guessed at before you started meeting people. Start talking to the easiest people. Pick the people who are most likely to be able to (and want to) use your service and test with them. If your service doesn’t work for them, it won’t work for anybody.

As you begin to solve problems, make it harder for yourself by inviting people who are going to be more difficult – those with edge case and the complex user needs and those with lower (or no) digital literacy.

What user researchers do when they’re not researching

Leisa Reichelt

Originally published on the GDS User Research Blog

A lot of teams aren’t used to having a user researcher embedded full time. When we suggest that they should, we’re often asked:

But what will the researcher do when they’re not conducting research?

We’ve discovered that our user researchers are only actually researching about 30% of their time.

Whilst it is our job to understand end users and how they interact with our service, we think our most important job is this: to make sure that everyone in our team understands end users with the same empathy, accuracy and depth as we do.

Here are some of the things that embedded user researchers do when they’re not researching:

We work with the team to improve the service

  • Analyse research with the team, understand the key insights and work out what actions to take as a result.
  • Work with designers, content designers and developers to make prototypes for testing something new. We sit with the designer and developer so we can chip in and answer questions about what’s being made and why.
  • Spend time with the business analyst or product manager to prioritise features and stories. We also work through questions thrown up, as a result of research, around user stories and acceptance criteria.

We communicate what we know

  • Give research ‘playbacks’ and share key research insights with the project team and stakeholders.
  • Compile video clips from the research so those who couldn’t attend can see real users for themselves.
  • Write blog posts on our research findings.
  • Prepare and deliver presentations, demos and show-and-tells.
  • Make things to post on walls  to keep people thinking about our users, their needs and the challenges we need to overcome to make a great service for them.

We prepare for research

  • Organise upcoming research participants by either writing screeners for agencies or contacting potential participants directly.
  • Work with the design and development teams to work out future user research needs and to create research hypotheses.

We look at site analytics to…

  • See how, and if, we can use analytics to quantify findings we’ve observed qualitatively.
  • Spot patterns in the data and identify future research needs.

These activities are essential in making sure that the time and effort put into user research isn’t wasted. Research is only valuable if your project team understands it and acts on it. These activities help make that happen.

At least 3 days a week

We recommend that user researchers are embedded in a team at least 3 days a week. In fact, most researchers find that just 3 days a week leaves them stretched for time in getting everything done.

It’s a different approach to research than most are used to, but in agile projects, we’re finding it’s the only way that works.