Tips for bringing UX to the Agile party

19 minutes read

When I first heard about Agile software development it conjured up pictures of gnarly programmers cutting code on their skateboard, high fiving their buddies whilst shouting ‘DUDE!’ every 5 minutes. Sadly the reality doesn’t seem to be quite so interesting (alas the same is also true of the even more suggestively titled ‘Extreme programming’). There has been a lot of debate about how best to incorporate UX design into Agile software development, especially as like UX it’s still a very new field and people are still finding out what works best. Despite being a qualified SCRUM master (perhaps the world’s easiest qualification – you just have to sit through a 2 day training course) I don’t have all the answers, but I do have some tips when it comes to working on the UX side of things for an Agile project.

Getting UX into the Agile team

I think that one of the best things about Agile is that it reinforces the idea that design and software is (generally) very much a team effort. With this in mind it’s imperative that if you’re the UX guy or girl on the team that you try to sprinkle as much of your UX fairy dust around as possible. You should be working very closely with the whole team and yes that means working with those scary programmers (feel free to draw the line if they invite you to join them in their online role-playing game).

Be the voice for the user

Often you’ll be the only UXer in the Agile team so it’s important that where required you chime in as the ‘voice’ for the end user (don’t worry – you don’t have to throw your voice or anything). For example, if features are being discussed ensure that user needs and requirement are considered. If there is a product team make sure that you’re in it, or at least that someone in the team is looking after the UX side of things.

Build and foster a collaborative Agile team

Not only is it vital that there is a permanent UXer on the team (I know from my own experience that being parachuted in and out of teams can be very difficult) but I also think that it makes a huge amount of sense to co-locate the whole team together. Yes that might mean moving away from your UX buddies but just think of all the new friends you’ll make!

You should also endeavour to treat all your team mates like family (perhaps with out the family squabbles). That means sharing, caring and generally making an effort to get along. It means sharing all your UX activities, such as user testing, user interviews, personas and scenarios with the whole team and where possible getting the team to participate in these activities. For example, if you’re running some user testing allow the developers and product owner to observe. If you’re creating some personas try to sketch them out as a group. As they old saying goes – ‘many heads are better than one’.

Encourage empathy with the users

Alas not everyone can ‘feel your users’ pain’ like Counsellor Deanna Troi (from Star Trek next Gen). That’s why it’s important that the whole team not only understand, but can also empathise with the users of your site or product. There are a number of things you might do to encourage this, including:

• Using personas to really bring the users to life, and to create a shared view of who the site or product is being designed for. What would Ted need to be able to do? Does the design fulfil Joan’s needs and requirements?
• Collaborating where ever possible. For example, getting everyone together to create personas, to sketch out designs and to decide on your design principles.
• Sharing user feedback with the whole team. For example, following a daily stand up. This might be feedback on the results of user testing, user surveys, observation or user interviews.
• Encouraging the whole team to participate in user research. For example, observing user testing, exploring survey results, observing focus groups and being part of user interviews.

Make the team more design literate

‘Give a man a fish and he can feed his family for a day. Teach a man to fish and he can feed his family for a lifetime’. Of course we all know that this really leads to over fishing but the principle is the same with UX design. By making the whole team more knowledgeable about UX design you can help spread the UX workload and ensure that you spend more of your time on the more important stuff. Some of the ways that you might make the team more design literate include:

• Always explaining the rational behind designs. It’s important that before any design is picked up by designers or developers, that they know not just the ‘whats’ but also the ‘whys’. Ideally you should do this face-to-face but it could also be done using annotations or by going through the designs over the phone.
• Involving team members (where possible) in UX activities. For example, design workshops, user testing and piloting user surveys.
• Pointing people in the direction of good UX books, articles and resources. Don’t become the UX bore but if people are interested then let them know where they can find out more.
• Putting together best practice guidelines for developers to use. These should be as short and sweet as possible and might cover areas such as HTML standards, UI design patterns and UI design principles.
• Coaching other team members. For example, going through UI designs with them and running though how a user testing session works.
• Providing knowledge shares for developers. For example you might all get together at lunch time to discuss things like design principles, accessibility, good form design and which is better – BMX Bandits or The Goonies?

UX considerations during sprint zero

Now an Agile zealot might argue that it’s a waste of time to do any up front design because at the end of the day it’s the working software that counts. However, I’m a big believer in doing ‘just enough’ design upfront and that means just enough design during sprint zero to prepare for the upcoming sprints. You wouldn’t start building a house until you know how many bedrooms it will have and similar you shouldn’t start building a website until you roughly know what sort and how many pages it will have!

Gather those requirements during sprint zero

Sprint zero is often the only real time you have to gather requirements because during sprints you’re often too busy doing design stuff. You might therefore take this opportunity to:

• Get agreement on the goals and objectives for the project, including targets. If these aren’t clear then you’ll never know whether the project has been a success or not.
• Set the user experience vision for the project. What sort of user experience needs to be delivered? Are we talking the best thing since sliced bread or just enough to cover the basics?
• Go out and meet and observe your users (don’t spy on them though – that’s not very ethical). What are their needs and requirements? You can use this to create personas and inform the non-functional requirements.
• Carry out any user research. For example you might carry out surveys, interviews and focus groups. Find out as much as you can about your users because otherwise you’ll be guessing, and as they say, ‘ASUME’ makes an ‘A(R)SE’ out of ‘U’ and ‘ME’ (easily my favourite business cliché).
• Carry out competitor analysis. What are similar web sites and products like? What sort of sites do your users like?
• Analyse any analytics you might have. For example, what are the most popular sections on your site? Where are visitors coming from?
• Start creating usage scenarios. These are best created collaboratively and are basically stories outlining how a user (in the form of a persona) will use your site or product. You’ll find that potential features will emerge from these, together with lots of other user requirements that you might not yet have thought of.

As I’ve already mentioned I think that an important part of sprint zero is defining the user experience vision. There should be an agreed and common user experience vision so that everyone is singing from the same hymn sheet. The vision might be expressed in the form of a vision statement, a problem statement, a product review or even as a possible press statement following the launch of your new site or product (just don’t make it too fantastical). The user experience vision should continually inform the design – don’t just create it and let it gather dust somewhere.

It’s also very important to get an agreed view of the desired user experience. One way to help reach this agreement, or at least to find out where differences of opinion might exist is to ask the whole team to write short descriptions for the desired user experience. Microsoft’s product reaction cards are a good starting point for this. For example people might decide that the desired user experience should be:

• Cutting edge
• Intuitive
• Personal

Utilise personas to ‘Keep it real’

Personas are basically fictional representations of ‘real’ users, and are ideally based on empirical research (a persona based on a character from a TV show doesn’t really cut the mustard). They help the team to get an idea of who the site or product is being designed for and help build empathy for the end users. They can also be used to evaluate designs and to think about possible features and scenarios. Be mindful that it’s usually quicker to create personas with a core team (e.g. A UXer, analyst and product owner) and then to discuss these with the rest of the team than to try to create them from scratch with a large team (too many cooks and all that…).

Personas should ideally be based on empirical data, such as market research, surveys, analytics, ethnography and interviews. If this isn’t possible then assumed personas can be used. However these should be validated as soon as possible. If assumed personas are used initially then it’s a good idea to use a sketch or drawing instead of a photo in your persona description. This is so that it’s clear that it isn’t a ‘real’ persona (although I wouldn’t recommend a ‘Mickey Mouse’ or ‘Homer Simpson’ persona).

Personas can also be used to rapidly evaluate designs. For example, would Peter know how to use this? Would Sarah find this useful? They can also be used to help generate ideas for possible features. For example, what would James like to be able to do?

A UX’d product backlog

As anyone who has been involved in an Agile product can probably tell you, getting agreement on exactly what the product should do, i.e. what should go in the product backlog can be like trying to turn lead into gold. Even once you’ve got a product backlog you’ve then got the difficult job of prioritising stuff. Of course you could rely on your omnipresent, all knowing product owner but usually they will put in what they want, not necessarily what is going to be best for your users, and ultimately the product. Once again user experience tools and techniques can help.

Drive features & user stories using scenarios

Scenarios are simply stories outlining how people (usually in the form of personas) might use the site or product being designed. They ideally cover the complete user journey (i.e. not just the instance when the site or product is used) and usually concentrate on a particular user task or goal. For example you might put together a scenario for Bob using his address book to find the telephone number for his friend Sarah. You would basically map out from Bob’s perspective how that story might go.

Scenarios are really useful for generating and validating user stories (i.e. as a … I want to … so that …), and for providing context. In short they help to ensure that the envisaged use of a site or product is as realistic as possible (which is why coming up with fantastical scenarios of use is certainly not to be encouraged). I’ve also found it best to initially concentrate on ‘sunny day’ scenarios (i.e. where there are no real hiccups) and then worry about what happens when it all goes belly up.

Use personas to help prioritise

Personas are great. They not only help the Agile team to get an idea of who the product is being designed for, but can also be used to evaluate designs and to think about desirable features and scenarios.

For example you might take your product backlog, take your set of personas and for each feature outline whether you think the persona would:

• Love the feature
• Like the feature
• Be neutral towards the feature
• Loathe the feature

By giving the scores a ranking (e.g. love: +2, like: +1, neutral: 0, loathe: -1) you can quickly work out which features are likely to be loved and loathed by your users.

Ask users to prioritise features

Of course guessing how someone might respond to a feature is not as good as actually getting out in to the big bad world and finding out. I guess it’s the difference between ‘user scented design’, and ‘user centred design’. But how might you do this?

One way to get user input is to give them dummy money (Monopoly money works well and is less ‘stealable’ than real money) and to ask them to ‘buy’ the features they’d find most useful. Using any relative estimates as a guide, assign a cost to each feature, roughly relating to how complex designing and developing it is likely to be. For example a simple feature might cost £10, whereas a more complex one might cost £50. Costs should be relative so that a feature twice as complex as another should cost twice as much. It’s also a good idea to use some sort of picture, prototype or working example for each of the features so that users have a clear idea of what the feature is, and how it might be useful (without this the danger is that different users interpret features very differently). Then simply give people a wad of cash (the less money you give them the more carefully they have to choose) and ask them to buy the stuff that they would find most useful. Of course it’s worth bearing in mind that often what people ask for and what they actually need can be very different! It will however give you a good insight into what features users would like to see from your site or product.

Include UX criteria as part of the acceptance criteria

The acceptance criteria for a user story or feature outlines how it must perform to be deemed ‘acceptable’ for release (although often ‘acceptable’ is a very loose term). If this is a user story or feature with a UX element (i.e. it’s user facing) then it should also have UX criteria included as part of the acceptance criteria. Such UX acceptance criteria might include:

• Has been usability tested with no serious issues
• Task can be completed by 90% of users tested
• Has been reviewed by a UX person

Factoring UX into estimates

An estimate that has been plucked out of thing air (Hmmm… that would never happen) is worthless. In fact it’s worse than that, it’s downright dangerous which is why it’s so important that UX gets factored in to the equation whenever estimates are made. To ensure this happens you might want to consider some of the following.

Make sure that design estimates are in place

It’s really important to ensure that together with the estimate for actually coding a feature or user story, estimates for researching, designing and evaluating (e.g. user testing, expert reviewing) a feature or user story are also factored in. This is why it’s important that the entire team is involved in estimating the product back log – not just the development team (because otherwise the UX stuff can be conveniently forgotten).

Don’t forget to allow for iterations

Agile can be very focused towards completing features, without actually allowing adequate time to refine and iterate the feature. Introducing 2 or 3 additional iterative rounds for each feature or user story can help to ensure that these important design iterations are factored for. For example, you might increase the initial estimate by a third (i.e. 33%) to allow for a second iteration and by another quarter (i.e. 25%) for a third iteration.

Using 3 rounds, a feature or user story is moved to the next round once it has been evaluated. That is once that it’s been user tested, reviewed by a UX person or signed off by a user representative or the product owner. For more about this technique please check out Alistair Cockburn’s excellent Three cards for user rights.

Doing just enough UX design

Design is where the magic happens! It’s also probably the trickiest part of any Agile project because design has to happen in parallel with development. Doing all of the design upfront kind of defeats the object of taking an Agile approach, so how do you ensure that there is sufficient UX design before the mad rush to get everything coded begins?

Get a head start!

From my own experience I’ve found that unless you get a bit of a head start on the developers you’re forever playing catch up, and trust me, you’ll never truly catch up. So how can you get a head start? You could think about:

• Initially concentrating on features and stories that are technically difficult but require little UX design input. For example you might map out the interactions for a largely back-end process, such as exporting files or creating a new user account.
• Try to get more design and UX resources for the first few sprints. Things are always going to be busier for the first few sprints as a lot of the ground work is put in, so the more UX bums on seats you can get (to an extent) the better.
• Trying to get the development team to initially concentrate on the ‘bigger picture’ functionality. For example get them to work on shared components such as paging, menus and tables.
• Keep the developers quiet putting the build, test and live infrastructures together.

Get the bigger picture in place before getting into detail

You wouldn’t start shooting a movie without a script, or at least an idea of how the story goes (OK – maybe if you’re an Art house director). Similarly it makes sense to get the bigger picture stuff, such as sitemaps, scenarios, user journeys and high level page templates in place before you start working on the smaller pieces of the design. The danger is that without this framework in place you have to continually go back to refine things because they are inconsistent, or simply don’t come together as a whole.

It’s also worth keeping in mind that whilst Agile calls for design components and user scenarios that are relatively independent (so that scheduling is kept as flexible as possible), in practice this is rarely the case. It’s often therefore desirable to design and develop foundation features (i.e. that other features build on), even though they might be lower priority than others.

Stick to your design principles

Design principles are basic principles that can help guide the design of the site or product. For example:

• Don’t make me think – A task shouldn’t require any prior training, only a reasonable amount of background knowledge or memory recall
• Keep me in the know – Users should be constantly informed of whether something was successful or not

Try to come up with 5-7 design principles that will help keep the team focused on the agreed user experience goals for the site or product.

Concentrate on the most common scenarios

‘Anything is possible’ and even in a non-Agile project it doesn’t make sense to design for, and document all the possible eventualities. Instead concentrate on the most common usage scenarios (i.e. sunny day scenarios). Try to design for the 80% of usage – don’t let the design be unnecessarily guided by the other 20% of atypical usage (unless of course such edge cases are very important). Although the design obviously needs to consider exceptions and edge case scenarios, it doesn’t make sense to try to cover every possibility!

Design collaboratively

I know that it can feel like you’re somehow giving away your MoJo but collaboratively generating and evaluating design ideas can be a really good way to quickly put together designs, to build understanding within the team and to get buy-in. Sometimes the best ideas come from the most unexpected places and designs can be quickly and collaboratively generated and discussed using workshops, such as the design studio and design critiques, or simply by bringing designs out in to the open so that everyone can collaborate and critique (like Adaptive Path’s Sketchboards).

Design rapidly

Agile shortens the time frame for design. Whereas before you maybe had a week to work on some wireframes, now it might be a day, or even just a few hours. Short of inventing a time machine how can you speed up the design process? Some of the strategies you might want to think about include:

• Utilising design workshops with the whole Agile team to rapidly create, discuss and evaluate high level designs. Get everyone in the room, lock all the doors and tell them that they can only leave once you have all come up with a design!
• Using design patterns, such as for forms, logins, registration, tables and menus to help speed up the design process. There are a number of design pattern websites out there worth checking out, including Quince, UI patterns, Pattern tap and Yahoo design pattern library.
• Ditching those cumbersome wireframing tools such as Visio, Axure and OmniGraffle. Instead get out your pen and pencil and sketch your designs. It’s quicker and easier to change than using an application and you can even have a go at some paper prototyping.

Help build consistency with design patterns and UI guidelines

Building up a simple set of design patterns and UI guidelines can help to ensure consistency between pages and to speed up design work. You don’t need anything as detailed as Microsoft’s Windows User Experience Interaction Guidelines, just enough for the developers to work with. Most of the design patterns should ideally be created during sprint zero, that is once the framework and high level design is in place.

Getting Agile user feedback

‘The proof is in the pudding’ and this is true whether you’re talking about your design for a new website, or your new experimental cheese and chocolate flavour fairy cakes. Getting user feedback can sometimes be quite tricky in an Agile project because the focus is often on building stuff, not evaluating it so how can you ensure that your users are given the attention that they require?

Carry out remote user testing

There usually simply isn’t scope for much face-to-face user testing during Agile projects so think about carrying out remote user testing. There are loads of tools out there, such as UserVue, WebEx and Skype so there’s no excuse for not getting those designs tested. If getting hold of users is proving difficult (or impossible) why not use user representatives, such as friends and family? After all, some feedback is better than none!

Create low fidelity prototypes

There simply isn’t time within an Agile project to create a high (or even medium) fidelity prototype so instead use low fidelity prototyping methods such as paper prototyping, clickable wireframes and PowerPoint presentations to quickly evaluate concepts and designs. Remember that a prototype by it’s very nature is something that will be thrown away so there’s no point spending any more time and effort on it than you have to.

Killing threes birds with one stone

When getting user feedback it makes sense to cover as many bases as possible. Within a sprint you’re typically looking at a number of user stories or features at a time so in those precious few moments that you have with users think about getting:

• Requirements for the features and stories to be developed in a few sprints time
• Feedback about the features and stories currently being developed
• Feedback about the features and stories that were developed in the last few sprint

Carry out testing as part of UX reviews

Unlike more traditional waterfall projects, when it comes to Agile projects testing needs to be a continuous activity undertaken by everyone in the team, including any UXers (as painful as that might sound). It’s important that together with developers testing features and user stories as they are developed, ad hoc and more structured testing is incorporated into UX reviews. For example, can the site handle incorrect input? How does a website behave when a page is refreshed? Can the back button be used? Finding lots of bugs might not make you the most popular person in the team but if it stops shoddy software being shipped then it’s worth it.

Getting your UX designs down on paper

Everyone loves writing documentation right? Love it or loathe it documentation is a necessary evil for every project, even Agile ones. However, what is necessary for a traditional waterfall project is quite different from what is necessary for an Agile project, primarily because you’re working (or at least you should be) so closely with the developers. With this in mind what should you think about when it comes to documenting the UX design for an Agile project?

Keep documentation to a minimum

I’m a big believer in documentation being as minimal as possible. To paraphrase our old friend Albert Einstein, ‘Make documentation as minimal as possible, but not non-existent’. There’s often very little time within an Agile project to work on documentation, so think about using:

• Sketched designs instead of fancy pants wireframes. You can get the design across with a lot less effort.
• Skeletal personas with the most important details, rather than someone’s complete life history. Knowing where Joey went to school and who his best friends are might be nice but does it really help the design?
• Annotated screenshots and screen grabs. Grab a screen, scribble on it and hand it to the developers. Don’t worry about moving this pixel here, and this pixel there – getting the ideas across is the most important thing.
• High level scenarios. You don’t need to go into excruciating detail in your scenarios and storyboards – just enough for people to work out what is going on.

Explain the designs

A natural consequence of keeping documentation to a minimum is that you’ll need to spend more time talking about the UX designs, whether with developers or other project stakeholders (yep – no more throwing designs over the wall for the developers to fight over). Ideally this should be face-to-face but you could also do it over the phone. When this isn’t possible, be mindful that it can often be quicker to cover slightly more in the documentation (I know, I know – hardly minimal documentation) than have to continually go back and correct things that have been misinterpreted because of insufficient documentation.

Make designs appear unfinished

When discussing designs, wireframes or prototypes with developers or other project stakeholders it’s often a good idea to make them appear unfinished, so that it’s clear that they are not the final article. This isn’t an excuse to present half-arsed designs, more a means of setting people’s expectations. You could do this by:

• Using sketch designs. No one is going to assume that a sketch is the finished article.
• Using sketch templates. For example there are some good sketchy Visio stencils that you can use to give your wireframes that hand drawn(ish) appearance.

Keep a record of usability issues and good ideas

Sadly not all good ideas and findings make it to become features. Ensure that they don’t get lost by keeping a publicly available (and editable) log of good ideas and suggestions for the whole team to contribute to. Likewise keep a central record of usability issues so that if something can’t be immediately addressed it doesn’t get lost. A good example of this is Desirée Sy’s issue cards (see Adapting usability investigations for agile UCD, PDF) where a log of usability issues and feature requests are kept for the whole project team to see.

Finding out more about UX and Agile

This has been a bit of a whirl wind look at the UX side of things for Agile projects. As I mentioned at the start I’m certainly no Agile expert and can heartily recommend you also take a look some of the other Agile and UX resources out there, including:

• Agile product design – Jeff Patton’s excellent blog about Agile software development.
• Some of the best UX and Agile articles out there as compiled by Dave Potts
• The Agile Usability group – A group dedicated to discussing usability within Agile projects

Now where’s my skateboard ‘DUDE’!