User research + Agile

_06 UX-mobile-User-Research

Inspired by Alex DeWitt and Emmanuelle Savarit talks for Mobile UX London June event (sketchnote above) I decided to have a go at compiling my thoughts on what I have learned about making UX activities work in an agile framework.

06-ux-mobile-researhc      06-ux-mobile-researhc-2 06-ux-mobile-researhc3

1. what do you / your client / your team want to achieve with user testing?

Start by identifying what your team are wanting to achieve with user research – what do you want out of it?

E.g. We want to work in 2 week sprints to follow the rhythm of the project; to use research as a powerful tool to influence decisioning; to expose wider team member to research activities.

2. Set the plan for User research as a regular activity from beginning to the end of the project

After you have defined what you are wanting to achieve you are in a good place to put the appropriate plan in place to make user research a regular aspect of the project from end to end. By making it regular and part of the sprints you are turning ux activities into an integral (and non-optional)  part of the design and development process.

E.g.We’re going to do one to one user interviews, every 2 weeks. We’ll talk to 4 users for an hour each. Users will be recruited against the two target personas / segments. A debrief session will happen every week. We will iterate the process.

How many users should you test? Emmanuelle’s response was 16 is ideal but time consuming. 8 is enough to see patterns emerging. If you don’t have the resources go for less.

In past projects we’ve prioritised frequency vs number of users because of the benefits that come with (truly) making user research a regular activity and creating that rhythm.

Slide from Evgenia Grinblo

3. Identify the knowledge gaps

Focusing on the the questions that your team is trying to find answers to, will guarantee that user research keeps on having an impact because it is used as a tool to make informed decisions as the project moves through its different stages.

Every week in preparation for user research go around your team and ask them what they are working on and if they have any questions they would like to see answered. Look at the project’s kanban board and see how the things your team has told you about match with what’s on the pipeline.
I started using a user research backlog to keep track of the questions that the team raised, why, by who and the outcomes of each sessio. I move each user research ticket in progression against the columns of New, Next User session, Needs more testing, Done.

Appropriating the agile tools to the UX process brings consistency and makes it easier to communicate your activities with the rest of the team.

4. Process + team

And finally, iterate your process as you go along and get people on board. It might look something like:

  • 6 users every 2 weeks
  • 3 sessions running in parallel
    • every other wednesday from 13:00 to 18:30 (1 hour to setup, 1 hour per session, 15 m break in between, 1 debrief at the end)
    • 3x facilitators
    • 3 x notetakers – you’ll be recording the sessions, so the notetakers role is not write everything down. The notetaker is there to be critical, to grab the insights that are relevant and most importantly it allows you to bring people from the wider team into the research activities.
    • debrief – post-its and poster on the wall / key themes on online tool of choice / videos and quotes if possible.

One person will be in charge of running the whole thing and should allow some time to:

  • get recruitment going (2 weeks in advance)
  • source any software / hardware necessary
    • make sure you have enough disk space to record all sessions and have a standby computer
    • get good microphones – it makes a huge difference (learnt to avoid maplin the hard way)
    • get two go pros, find a way of setting one overlooking the users shoulder and the other one facing them
    • get the right software to mirror your device onto your machine
  • compile user sessions backlog; write script; define debrief goals; print user session pack (checklist, setup information; script; info about participants; debrief goals; contact details; note taking guidance)
  • communicate / invite the wider team – some PR skills won’t hurt
  • assemble team, train them when necessary, and brief them on the script (don’t forget to block the time on their calendars)
  • Run a trial session – test your setup everytime you change something e.g. move from apple to android
  • analyse and communicating your findings – this is the most crucial bit. You can do an amazing job with all of the above, but communicating your findings is the thing that will determine whether or not the insights that you have gathered about your users will make it into the project and as a consequence determine if you are really building something that meets your users needs and motivations.
    Ultimately you are responsible for spreading your findings and evangelizing the team with a constant growing understanding of user feedback.
    You need to follow through with team members that have requested something to be tested, in most cases having a debrief session with them. Communicating your research is an iterative process and needs to be adjusted to your audience. Ultimately people will respond to quotes and hearing it from the users mouth, whenever possible I use videos.

    UX is open source if there’s other agencies involved and they don’t want to share their knowledge, they are failing the users.

  •  iterate the process as you go along.

Go for it.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s