In 2003, Jakob Nielsen recommended that "development projects should spend 10% of their budget on usability". Although many countries are now making tentative steps out of the recession, the effect on tech budgets has put an even greater squeeze on the availability of funds for heavyweight usability testing. This has, no doubt, given considerable impetus to the use of lightweight methods in usability testing and the movement towards agile usability engineering.
Unfortunately, with every attempt to save money and time, certain aspects of the process and component processes are sacrificed. Miller and Sy (2009), in Agile user experience SIG, outlined the major problems associated Agile UCD, which are:
Not enough design time - In agile UCD the emphasis is on speed, which can see developers and usability engineers pushed for time. The pressures on time can move the focus from quality onto the timescale; producing a predictable knock-on effect for each iteration of the product.
Each iteration or sprint is too short - This can sometimes mean usability testing is aborted entirely for a particular sprint. In addition, users and customers may not be consulted, observed or tested, which means there are potential ramifications for all proceeding iterations. Perhaps worst of all, there might not be enough time to complete a particular stage, prototype, or the product full stop.
Insufficient user feedback - Connected to the problem above; when there is so much pressure on each stage to be completed within a certain timeframe, user involvement is typically seen as the most easily sacrificed part of the process. So, on occasion, developers may be forced to make improvements to a product with very little feedback to guide their adjustments. This means that designers will guess and assume the role of their users when assessing the current design, which is fraught with problems in itself and leads us to the next problem...
Non-informed decisions dominate - If the iterative process is driven by 'best-guesses', rather than progressive user feedback, the UCD part of the project is sorely lacking. As a workaround, a usability engineer may be assigned to each sprint or part of the process to act as the 'customer' and guide decision-making.
UX part-time for one or more agile team - This means that the overall project becomes similar to the game Exquisite Corpse (cadavre exquis), where each team is working blind or with very little information from the preceding phase or from another team working concurrently.
No sprint/cycle planning - A lack of planning can set the project off on the wrong foot, and it is very difficult to wrestle things back. It can also result in an endless backlog of unimplemented features and persistent bugs. Again, this may be counteracted by involving a UX designer/engineer/specialist at each stage.
Ignoring User Feedback - Time, budget, stubbornness, suspicion of test users, and a disregard for the benefits of UCD may result in one or more teams ignoring user feedback entirely, which leaves the product much like the original prototype or based on the needs perceived by the various teams.
Too local, rather than global focus - Everyone should be reading from the same hymn sheet. Unless everyone is driving toward a common goal, with an eye on the bigger picture, the end result can seem confused and inconsistent.
Lack of communication - Unless members of each team discuss their ideas, express their feelings, and provide possible solutions, the process suffers. Each individual team should then liaise with and pass on as much information as possible, to inform and support one another. Unless teams communicate, important factors and problem solutions may be overlooked.
Team members in different locations - A lack of proximity can cause communication problems. Additionally, it can upset team dynamics and limit the process of sharing ideas and building positive relations.
Dependency issues - The process can be rocky if the team(s) have to consult or involve non-agile teams or members, such as lawyers and accountants.
As you can see, marrying UCD and agile methods is not always a smooth process and there are lots of things to consider when taking such an approach.
However, as agile UCD usually involves a relatively large number of people from various departments, many of these problems will be out of your hands. To avoid most of these problems, try to sell the benefits of this approach before the process begins, so everyone is pointed in the same direction.
References & Where to Learn More
Course: Interaction Design for Usability
da Silva, T. S., Martin, A., Maurer, F., and Silveira, M User-Centred Design and Agile Methods: A Systematic Review
Denning, S. The Case Against Agile: Ten Perennial Management Objections
Moczar, L. Why Agile Isn't Working: Bringing Common Sense to Agile Principles
Sonmez, J. 5 Things that will make your agile development project fail
Images: Header, Agile Methodology, Agile Process, Comic
Header Image: Author/Copyright holder: Unknown. Copyright terms and licence: Unknown. Img
