Agile and Usability in tandem

When working in cross-functional teams, agreeing on a development method is usually the greatest task. Sometimes though, people are thinking on a too detailed level. My first computer science teacher told me to abstract the problem to find a simple solution, but I’ve often taught others to divide the problem into more simplified parts, and then find a solution to the smaller problem. From now on I promise I will try to do both at the same time (and try to remember what else he said :).

When the problem with combining usability and agile methods presented itself, I tried to divide and conquer. I would need to conduct interviews, do prototyping, and put forward an interaction design before the developers could start developing. To do this I would need to gather requirements beforehand from the customer as well. Not a good solution. It’s like placing a wall between the two methods.

The solution just lay there and stared at me. Think abstract! Usability is an iterative method, and so are agile methods. So instead of seeing them as two different tasks, the combination is quite straightforward. I removed the wall (with a little help from Eric Idebro & Illugi Ljótsson) and the solution presented itself:

The combination requires that in the first iteration (or ‘sprint’, as in Scrum) you only do usability tasks. A small specification with rough sketches and flows are presented, but they’re still based on interviews, etc. This is good enough for building a foundation. If this would be Scrum (and from now on we assume it is), this first sprint takes about 3 weeks, and the conceptual design will be a part of the product backlog as well as the tasks for achieving the usability goals. This makes it easier for the developers to recognize usability as important work.

Then, during 4-week sprints, usability tests are conducted about once a week. Although this is somewhat demanding (the architecture must be good, probably a three-tier architecture), the input you get will drive the design in a simple way. To do this in an easy and straightforward way, the sprint is divided into four smaller iterations. In the beginning of each iteration, something small is built that is testable with users, a part of the GUI and some functionality perhaps. The results are put in the sprint backlog (and you have planned for that on the sprint meeting), and change requests are dealt with the following week. This is for steering during a sprint, and you do it by refactoring your usability design. Quite complicated.

The work for the interaction designer during the sprint is to produce test cases for the usability tests, and of course, conduct these, while doing GUI design. For every test phase in every iteration, you’ll need real users. It is usually hard to find users and with this combined method you burn out users even faster, but on the upside there are enough test sessions to last for a lifetime.

At the end of the whole sprint, a full usability test on real functionality is done, the results of this test are discussed with the product owner, and will perhaps end up in the next sprint.

To work this way, there are some musts:

• The developers have to be interested in usability
• Continuous integration has to work really good. You have to deploy each week instead of each month.
• The product owner needs to know what user-centered design is, apart from just Scrum.
• The developers can’t be junior usability specialists; It would probably be too demanding since you need to refactor the usability as well as doing everything else at once.

But you can always try!

I understand that this is only the beginning, but it is a rough plan. I believe that for every project you have to adapt the method to the circumstances.