How to Easily Use Agile UX in Your Project

"Usability tests are too expensive, take too much time, and the results come in way too late anyway" – sadly, these clichés still persist today. This is exactly where Agile UX comes in, helping you and your company test and optimize UX quickly and efficiently.

What Is Agile UX, Anyway?

By now, agile software development has made its way into most companies. The advantage: there's no need for unnecessarily extensive corrective measures. "Fail fast – learn fast" is the motto. In agile UX, user feedback is gathered within one to two days at most. This feedback flows straight into the development process and helps you optimize quickly. Gone are the days of classic usability tests with time-consuming prototype creation upfront, extensive preparation, and lengthy documentation afterward. Agile UX relies on fast feedback loops and fits beautifully into agile development.

Is Agile UX Testing Even Right for Your Project?

Agile UX tests are designed specifically for agile teams that rely on regular user feedback but don't want to wait long for results. Agile UX tests can be used in every phase of the development process and help uncover usability problems early or evaluate product ideas with real users. Even at very early stages of development, you can gather valuable feedback on content and information architecture. Usability problems can be tested long before implementation. That way, you can make sure you end up with an easy-to-use product that users simply love.

Preparation Is the Key to Successful Agile UX Testing

In the beginning, God said, "Prepare yourselves," and God saw that it was good! That's more or less how you could sum up Agile UX testing.

As you can see, we place great value on clean, well-founded preparation. It's the only way we can make sure no important questions or usage scenarios are overlooked. The preparation phase includes the following steps:

1. User research
2. Rough concept and vision
3. Prototyping

So that testing fits seamlessly into the agile process, we focus on the last 1–2 days before the User Feedback Day. YES! There's a dedicated day for gathering user feedback. The advantage: work on the project can continue right up until shortly before the User Feedback Day.

UX testing happens frequently and iteratively. That means we test with fewer participants, but much more often. Otherwise, there'd be no way for us to limit the test to one or two days at most.

The User Feedback Day

So how does a User Feedback Day actually work? First of all, everyone involved in the agile process is invited to observe the test. Involving stakeholders must never be limited to asking questions and signing things off. To keep everyone on board with your project, these people also need to be involved on site. This way, the purpose and goals of the UX test are explained to them in more detail. It also becomes clear that the first insights can already be gained during testing – but that this requires input from all observers and decision-makers.

Now that everyone involved is fully convinced that the time isn't "wasted" but important and purposeful, we need to introduce some observation rules:

1. Observe at least 3–5 sessions: The more sessions you can observe, the better. But rather than observing none at all: one is better than none. In my experience, 3–5 sessions offer the best compromise.
2. Observe actively, not just passively: If you don't take notes, you're throwing away a huge amount of knowledge and potential. Active participation by every observer in the user test is important. Laptops stay closed, phones stay in pockets, and conversations happen only during breaks. In that moment, nothing is more important than the user test.
3. Discuss during breaks: As mentioned in point 2: observations are discussed during the breaks, not during the test. Besides discussion time, you should also plan a break for recharging.

Testing on its own is nice and fun, but without proper documentation, insights get lost. That's why, even before the User Feedback Day, everyone involved needs to know how observations will be recorded. There are plenty of tools you can use: classic Excel and Word, or Jira, Confluence, MeisterTask, and so on. Personally, I like to use Evernote Business, because it lets you capture all information in individual notes and share them with the team. Whichever method you choose: make sure not only collecting but also processing the results is clearly defined. To give you a starting point for how such an observation log can be standardized, here's a look at mine:

• Participant name (pseudonymized)
• Behavioral observations (couldn't find the "Sign up" button)
• Possible solution ideas
• Frequency of an error (to see whether certain errors occur more often)

Based on this data, you can discuss the insights with your team. At the end of the User Feedback Day, all insights should be walked through with everyone involved.

CONCLUSION: AGILE UX TESTING PAYS OFF

Agile UX testing pays off. Fast feedback, manageable costs, and a product that's easy to use and delights people. Agile teams can't get around agile UX – especially since agile UX also integrates beautifully into Scrum. If you'd like to learn more about agile UX, feel free to get in touch, and together we'll figure out whether agile UX is worth it for your project.