UX and Agile: How does UX Research Fit in Agile development?
It’s become a common buzzword for people to use: We work “agile”. Agile sounds modern and successful – and in many cases it is. But what does that mean for user experience and usability? How do agile and UX research fit in together? That’s what we’ll explore in this guest blog post.
The bangs before the big bang of agile
In the 1970s, an individual programmer could code a whole Operating System in a matter of weeks. As programs became more complex over the years, more and more developers worked together – and for longer and longer periods of time.
The early pioneers started to build procedures and hit the simple realization that the better a project would be planned, the better its results would be. One step follows the other, and only once the previous task is finished, the next task could be started. Pretty simple, right? What could possibly go wrong!
This is the widely known “waterfall” model (or as some like to call it: the traditional model).
Soon enough, there came a point when more and more developers weren’t satisfied with this approach anymore. Large software projects failed again and again. Dozens of programmers worked on different parts of the code for years and put it all together a few weeks before the deadline. You can imagine how messy that would get. Often, fundamental misunderstandings led to problems in the product definition and incompatibilities would appear because not everyone had worked with the same standards or expectation.
The result: bang! Go all the way back and fix the errors or just accept the poor result.
There had to be a better way to work. Enter: agile approach.
How does agile development work: the basic idea
In the 2000, a group of developers that wanted to improve their time-to-market came up with the concept of created: In this approach, their vision was that they would try to define as little as possible beforehand, to produce an executable code as quickly as possible and to work iteratively (i.e. in recurring cycles).
Similar to working in a modern factory, each programmer or team works independently on a piece of the whole. At the end of the sprint, they put it together and test if that works. The idea was is that such an approach promotes teamwork and problems are discovered early. Not only that, the motivation within the team becomes higher because you can directly see how something works.
Agile working in practice: Where does UX fit in?
There are different variants of agile development, but the following points are crucial for product designers and UX professionals within the team:
- The UX is not developed alone or in the UX team, but with the entire development team.
- The aim is to produce a functional application/usable pages as early as possible. Speed is key.
- After the defining the core functions, the implementation (a “sprint”) often starts immediately, making more changes on the details comes into play only later in the project. While this could be
- Regular tests are planned (e.g. at the end of each sprint). At first, this is only about the technology, but more and more companies are starting to integrate usability tests here. Before each sprint, it’s best to determine what should be tested with users at the end. So the test cases are defined – together with the requirements for the next sprint.
Example of using UX methods in agile projects
The challenge with agile is to always keep an eye on the user experience and integrate it in your UX strategy: what’s more important, the functional developments or the UX? UX is relevant in so many areas, so this can sometimes be problematic in the iterative, small-scale way of working in agile teams. In my personal experience and from what I’ve gathered studying successes and failures of some companies, the following UX methods work best in an agile context:
1. User interviews & on-site observations (in Sprint Zero)
The most important tip with working agile from a UX perspective is: Despite the requirement that as little as possible should be defined in the start to reach an MVP, as a UX’er it’s always your responsibility to take enough time to define the user groups, research user needs and develop solutions at the beginning. Some call this phase the Sprint Zero. What better way to do just that than user interviews? As development continues, it’s best if UX and design are always a sprint ahead of the developers. This means that in the current sprint you plan the parts that the developers will only implement in the next sprint. And you test with users what the developers implemented in the previous sprint.
2. Personas (created with the whole team)
A persona is a fictitious representation of target users that can go a long way in helping your team make decisions on core functionalities of the product, features, visual design, etc. In agile projects, UX’ers can use personas to help refine the requirements and tailor them realistically to the kind of users that the product is actually being designed for. A handy practical tip is also to simply link personas to specific user stories that your development team works with. Reason being: your user stories suddenly become based on concrete facts you already know about your users and the development team gets tangible reasons behind them.
3. Usability evaluation (of already implemented parts)
Once some parts are implemented, then you can feel free to kickstart your usability evaluation of what’s already done. If you’ve got enough users, a quantitative tool like Google Analytics or Firebase can help you with statistical info on user behaviour. Even if you don’t expect to have large sample sizes yet (as is often the case at first) then you can also use a qualitative UX research tool like Smartlook to watch heatmaps, session recordings, behaviour flows, etc. and get to know how your users interact with the design.
4. Card sorting
Card sorting is a simple way to get some feedback on which functionalities people want in a new program, and which issues they want solve or generally speaking. It’s a great tool on several questions you may have to face: designing navigational features within your product, categorizing user stories, or phasing out your project, you name it. All you do is get the stakeholders together and ask them to sort cards in a way that makes sense to them.
5. Prototype testing (of features/pages developed in the next sprint should be)
When all you’ve got is prototypes for doing your user research on how your users behave on your design, well, then you’ve got enough already. If you invest in a decent prototyping tool like Figma, you can even add interactions to your prototype and just watch how your recruited users use it, get their feedback on design solutions you implement, alternatives they may prefer, etc.
This article was kindly provided by Anish Girdhar from Purposefully Digital (anish@purposefullydigital.com).