Getting Agile with User Experience Research

Spotless | 8 years ago

Mark McElhaw – Published: 25th Mar 2010 10:09 GMT

User experience (UX) and Agile haven’t had an easy working relationship–in part because their origins lie in different stages of software development. User experience focuses on research, planning, design and testing; Agile is about building better code. This article looks at ways to apply an Agile approach to research and planning. And if you’re one of the many who didn’t get enough time for planning and design, we have some recommendations for different types of user research during the build phase.

How does Agile differ from UX?

UX and Agile are approaches, and shouldn’t be confused with methods such as SCRUM, the most popular Agile process, and user-centred design (UCD), the standardUX method. With UCD, outcomes from each stage feed the next; with Agile, the focus is on creating functioning code, similar to creating all the pieces of a jigsaw, and then assembling them. Jeff Paton says Agile builds the leaves of the tree first, then works out the branches.

How do people fit UX into Agile sprints?

UX within an Agile context normally refers to UX designers, not to UX researchers. Design refers to wireframes interaction design, sitemaps, and sometimes prototypes. Research applies to requirements gathering, users’ needs analysis, personas, scenarios, and user testing. And research is really hard to fit into an Agile environment. The common solution is called ‘Sprint zero’, which starts user research and design a month or so before the build, and continues from there. (This is also known as developing in parallel, so that design Sprint is always about a month ahead of build Sprint).

A month, however, is a pretty short time, so research is often hastily conceived, and based on customer preconceptions, unless you’re building something for internal use. A major publishing house built their intranet using an Agile framework, and they developed technical, business, and UX work streams in parallel. They managed to do three weeks research in advance because the project team were also the end users, so they easily constructed personas and scenarios.

How is it possible to conduct research during a build?

While UX within Agile largely focuses on design, here are a couple of ways of conducting research. Typically, researchers only conduct usability testing against a functioning system, not necessarily during every Sprint.

There are a few ways of getting around this:

Test with less functionality, or focus on the functionality built during that Sprint. Sessions don’t need to be as long, and you can test with more people.

Alternatively, test the project as a whole, making sure the product fits for its purpose. This means testing with fewer people, and opens all the variables to change.

Finally, the RITE (Rapid Iterative Testing and Evaluation) method is good at dealing with any issues that come up and fixing them there and then.

Research is an opportunity to talk to people who will use the product, so use it to:

How could user testing happen in a one-week Sprint?

A one-week Sprint typically starts on Tuesday, so that deliverables are ready by Friday (allowing for leeway over the weekend). Testing can work on Monday morning so results are ready to present Monday afternoon in preparation for the Sprint Review. The team can prioritise issues for the backlog, and schedule them for the next Sprint. The UX practitioner is on hand to advise on design issues and recommend mock-ups to cover workflow gaps when testing disparate pieces of functionality built for that Sprint.

It’s even possible to gather requirements within the test, and create some rough personas over a few rounds. This helps the team see the highlights and understand different behaviour styles among people using the product.

So how would you go Agile with UX in the research and planning phase?

One way to combine Agile with UX is anticipate each deliverable such as business goals, personas, and scenarios, and refine them iteratively. While UX practitioners understandably don’t like to make assumptions as they can miss important insights, this approach encourages you to consider the necessary components, and, in a word, be prepared. Anyway, most people find it easier to respond to something than to come up with a solution on the spot.

This happened on a banking project to create a sales dashboard that could be used by four investment sectors. At the start the project team were interviewed to work out a generic workflow, some rough personas and some designs. Members of staff were interviewed and the outputs were refined. After three weeks and three design iterations, the bank selected one, and the development team had produced a ribbon tool bar categorised by the stages of the sales lifecycle.

What all does this mean?

User experience and Agile can learn a lot from each other. From a UX perspective, when you engage the development team with early research, it reminds them of the context for which they’re building pieces of code. Ongoing research during the build keeps them engaged with the people they’re building for. From an Agile perspective, there’s no reason why the research and planning phase can’t occur in Sprint, and showcasing each deliverable is a good way to check against technical, business, and design considerations. The deliverable can be a working requirement, specification, or plan, instead of merely working code. User research can fit within build Sprints as small as a week, and designed to include requirements gathering and testing either the whole system concept or discrete functions.

How can user research fit into Agile Sprints?

Question

Yes

No

Are your customer’s staff?

Consider testing with 3-6 staff every week. You avoid recruitment costs, and ensure the project gets as much coverage as possible.

Try testing with 3-6 customers every 2-4 weeks. This creates a fixed cost to factor into the project, accommodates testing of functionality, and ensures the product is fit for purpose when views are aggregated and reviewed against requirements.

Can you solve the issues in the next sprint and build?

Test with 5-6 people for 30 minutes on the functionality built for the Sprint, and create mock-ups to give it context.

Test with fewer people for an hour to test the project as it stands.

Can you fix the issues within the sprint?

Consider an RITE approach.

Consider presenting findings, and following them with a solutions workshop rather than creating a detailed document.

Do you have a very limited budget?

Consider using 3 users every release.

Try scheduling user research within every Sprint.

Are you really working in an Agile framework?

Test with people on every Sprint.

Carry on with user testing when there’s something useful to test.

Would you consider an Agile approach to user experience?

Start technical, business, design, and user flows at the same time, and run them in parallel.

Test with 4-8 users and a smaller set of tasks which you can change as the testing progresses.