How we do agile research analysis

Agile analysis shapes our research

Conducting research for agile projects means that we need to work fast, include the whole team and provide clients with opportunities to get involved. We embed research in all our work and remain flexible in our approach. This means sometimes we’re working on a full on eight-week discovery phase and have the capacity to combine several research activities (such as in-depth interviews and in-situ observations), but other times we’re conducting quick usability testing to support development sprints.

Analysing research means looking at how everything fits together:

This means we review collected data briefly after each activity to check that we’re still learning. We adjust upcoming sessions continuously to make sure we’re not simply doing more research for the sake of it, but instead adding value and depth to our insight.

We reserve time for the ‘final’ in-depth analysis and  write-up. This shows what we did, what we learnt, what we recommend based on those learnings and how we might go about doing that. We don’t do lengthy reports, but instead focus on prioritised, actionable user needs evidenced by snippets of what people actually did or said.

Collect data in a way that allows you to get it ‘on the wall’

We base our findings on what was actually said or done by real people. This means our outcomes depend on having reliable, easy-to-analyse qualitative data. While hand-written notes usually make up most of the data, other sources help us cross-check and fill in the gaps down the line. They also show what actually happened when memory fails; this is where conflicts arise and assumptions start to creep in. Some of the complementing resources we use at dxw include:

  1. Recordings such as screen captures, video, and audio that can be reviewed and used to extract quotes or provide visuals
  2. Sketches and photos showing the physical layouts of places and people using existing services and technology to access them
  3. Offline materials such as brochures, training manuals and paper forms relating to the service we’re testing
  4. Quantitative data such as results from surveys and analytics

Analyse together, write up and share

In research terms, by putting something “on the wall” we’re making an affinity diagram. These can take all shapes and forms, but there are some common ways to go about putting them together:

  1. Collect data. Write one thing per post-it or card so they are easy to group and move around. Even with typed notes, print them with grouping and moving around in mind. It’s important to make sure that the notes you’re working with capture your findings well. For more about that, read our post on how to observe and take notes for agile analysis.
  2. Find a large space like a wall, floor or whiteboard and lay everything out in a way that allows you to see who said or did each thing without disclosing their identity.
  3. Group data in ways that makes sense. This could be stages in the service, steps in user journey, specific user groups or  topics.
  4. Give groups names (known as themes or headings) and describe each one. This will help you make sense of what’s going on allow you to extract user needs.
  5. Discuss and iterate with the team until consensus is reached about the validity and priority of user needs. Brainstorm possible actions and write epics or user stories, depending on where in the research, service or product stage you are.
  6. Write up and share your findings. Select and include supportive quotes and snippets of videos. Video is particularly effective, as it will improve the credibility of findings and help those who were not present empathise with real users. We run show and tells with the client to present findings instead of handing over a slide deck. This also gives us opportunity to answer questions about research, reflect and think about next steps.
  7. Own actions where possible. For short-term client projects this may not be possible, but for longer and more complex projects it is partly a  researcher’s responsibility to follow up and keep teams focussed on user needs.

At dxw, we work in the open and welcome change, so we’d love to hear how other teams do agile research and analysis. We’re particularly interested in what researchers working in an agency environment and the public sector find difficult. What approach do you take to translate research into action quickly while meeting user needs?

dxw are hiring:

Marketing & Events Coordinator

Systems Administrator/Developer

General Application