I’ve been doing a lot of presentations at conferences over the last year talking about agile and user-experience or UX and my experiences in making the two practices can work hand-in-hand. While many practitioners subscribe to the idea that you should do UX work one Sprint (or more) ahead, I don’t. If business analysts, testers, database designers, architects and developers can work on the same products for release in the same Sprint, why can’t UX people do the same? Why aren’t UX practitioners embedded with the Team more often? Why don’t they [want to] work collaboratively with the Team on the same products at the same time?
When I pose these questions, many designers recoil in fear. Most feel very strongly that design should always proceed development. Some, though, are starting to see that because collaboration is key to the success of an agile project (it’s a critical part of the agile manifesto), being part the team is the only logical way forward. The question is, though, how to make it a successful collaborative effort, particularly when so much of UX requires user research?
“UX work is mostly about discovery, agile [development] work is mostly about delivery. Two world – both concerns are necessary. Discovery never stop. And, discovery without delivery isn’t very valuable”
– Jeff Patton, 2008
In the past, I’ve done a lot of discovery work — user research, prototypes, wireframes, and testing UX concepts with users — to understand how people think about products and how they are most likely to want to use them. Doing the UX design for the CHOICE website back in 2008 was one such project that culminated in a large, hefty tome of requirements. Simply, this research was to ensure that the website product met users’ needs. In my Agile projects, though, I’m finding some of this research has already been done by others (like the marketing team and business analysts) in order to sell the project. In turn, these requirements help establish the project’s scope and prepare the Product Backlog so that project can begin. Most often, this type of research has been included in the project’s Business Case. Other times, though, I’ve found very little user-research has been done and users’ wants, needs and behaviour in using the proposed products is hazy at best. Given bodies like the Standish Group report that projects fail because requirements are unknown and products fail because only 25% of features that are designed are typically used when products are released, doing user research helps to reduce these risks and the waste in the project team’s efforts.
If very little is known about users, though, then I’ve following can help when I’m doing an agile project:
- Do user research during project initiation — Most of my projects have gone through some kind of project initiation phase where its governance frameworks, risks profiles, team structures and development environments are established. This is a good time, if I’m onboarded as part of the team at this time, to undertake some user research. The key is to timebox the activity (with the help of the Scrum Master) and to do the following:
- Collect a set of questions that need answering regarding users’ wants, needs and behaviours
- Rank the questions in the order that is most valuable in terms of the knowledge it will add to the team to produce great user experiences
- Get as many questions answered within the timebox of the project initiation
- Establish that the remainder of questions need to be answered in successive Sprints
- Incorporate this research time into the estimates of any products for the Sprint if those outstanding questions need to be answered first
- Re-rank the questions at the beginning of each Sprint
- If new questions arise about user behaviour, needs, etc, add these to be answered in successive Sprints, not the current Sprint
- Use Backlog Grooming time to answer some of the higher ranked questions in order to reduce the complexity of upcoming products in the Product Backlog
- Capture user research as pragmatic over perfect personas — David Hussman suggests that the key to user research in agile environments is to synthesis what is understood about users at that moment and create pragmatic personas from those in order to have meaningful discussions with other team members about design requirements. As more conversations are had, more information is gathered, and knowledge increases about users, I then embed that collective knowledge into the personas so they grow over time. I’ve also found this captured knowledge to be an effective tool for the Product Owner to help inform decisions about the ranked order of items in the Product Backlog so that it always delivers value to end-users.
- Assess how products are being used now to inform product UX needs in future Sprints — The biggest benefit in producing working, functional, usable products each Sprint is that it’s enabled me to engage users as they use them to gauge needs and wants for future products or iterations or improvement to current products. In the past I’ve used social media to elicit this feedback quickly and efficiently with minimal cost.
Overall, I store user-research in such a way so that I can call upon my bank of research about needs, wants and behaviour when you need it next time. I now have about 5 years worth of research from sources that include Forrester, Nielsen, and the Australian Bureau of Statistics. Ultimately, this saves me a lot of time in doing any user-research up-front.
The key to an effective agile project is to do all of a project’s normal tasks — plan, design, test, produce and deliver potentially shippable products — in short, fixed periods of time. Software developers have discovered that the key is to do this collaboratively, with analysts, architects, testers and developers working collaboratively, side-by-side, and in parallel rather than in serial. To deliver the best products to end-users in the shortest amount of time, and to deliver new features and functionality in a way that best reflects users’ needs, UX people must also be embedded within the team. The limiting factor is how well we adapt our old ways of working ahead of product engeinners and software developers to working in close collaboration with them as they build. Doing user research in a timeboxed and value-ranked way can help us get out of the mindset of big-design up-front to a nible, reflective, that is responsive to both the team’s needs to produce products and those of users who want great experiences from their products now, not in a year’s time.