Agile usability engineering
 |
Agile usability engineering is a method created from a combination of agile software development and usability engineering practices.[1] Agile usability engineering attempts to apply the principles of rapid and iterative development to the field of user interface design.
Early implementations of usability engineering in user-centered design came into professional practice during the mid–late 1980s. Early implementations of agile software development evolved in the mid-1990s. It has only been within the past few years that the human-computer interaction community have seen widespread acceptance of agile usability engineering.[1]
History[edit]
When methods such as extreme programming and test driven development were introduced by Kent Beck, usability engineering had to become light-weight in order to work with agile environments. Individuals like Kent Beck have helped to shape the methodology of agile usability engineering by working on projects such as the Chrysler Comprehensive Compensation System. Such time-driven projects have helped individuals experience and understand the best methodologies to practice while working in an agile environment.
An early example of usability engineering in an agile software development environment can be found in the work of Larry Constantine and Lucy Lockwood who designed a browser-resident classroom information management system. During this process, the design team worked directly with an education team, which served as both subject-matter experts and representative end users to develop initial user role models and an inventory of task cases. This process mimics participatory design. With this material, mock-ups were iteratively designed to achieve the desired goal of “the stringent design objective of enabling immediate, productive use of the system based on a single-page tutorial.”[2]
The following table displays the differences and similarities of light-weight processes compared to heavy-weight processes as suggested by Thomas Memmel.[1]
| Heavy-weight processes | Light-weight processes |
|---|---|
| Detailed, up-to-date documentations and models | Card and hand-drawn abstract models Travel light Communicate rather than document |
| High-fidelity prototypes | Abstract prototypes, use simplest tools |
| Develop and prove concepts with user feedback Iterate |
Courage Design for needs (user's tasks) rather than user expectations Retrieve design from models rather than continuous user feedback |
| Time-consuming usability evaluations, workshops with intense stakeholder integration | Fast usability inspections No need to evaluate if models are right |
Methods[edit]
Many projects that are used in the agile software development process can benefit from agile usability engineering. Any project that cannot use models and representatives will have issues in an agile usability engineering environment, as the projects must be as light-weight as possible.
Throughout the usability engineering phase in agile development, users work with the product or service in order to provide feedback, problem reports and new requirements to the developers. The process is done interactively with focus directed first on basic functionality and later on with more advanced features. As the process progresses to advanced stages, more users work with the product or service.[3] Solutions are quickly applied based on severity. The phase ends with a milestone.
Paul McInerney and Frank Maurer administered a case study confirming that UI design practices required adjustments; especially in order to adapt an iterative development. However, it was concluded that the resulting UI designs are certainly not worse than what would have been made with the standard heavyweight approach.[4]
The core practices in agile modeling as described by Scott Ambler, help to describe the focus in agile usability engineering. The core practices include Validation, Teamwork, Simplicity, Motivation, Productivity, Documentation, and Iterative & Incremental.[5]
A modified agile development process, with usability instruments included, was developed and presented in the CHI ‘08 Extended Abstracts on Human Factors in Computing Systems. The usability instruments includes extended unit tests for usability evaluations, extreme personas to extend the typical extreme programming user story, user studies to extend the extreme programming concept of the on-site customer, usability expert evaluations to solve ad hoc problems and usability tests to solve on-site customer representative problems.[6]
Issues[edit]
Due to the struggle of incorporating traditional usability engineering methods into an agile environment, many issues have risen. Without comprehensive resources, practitioners have tried to follow the patterns of others who have previously been successful.[7] Table 2 represents the table of Problems, Symptoms, and Possible Solutions developed by Lynn Miller and Desirée Sy and presented in the CHI ‘09 Extended Abstracts on Human Factors in Computing Systems.
The following table is a summary of the main problems experienced by User Experience practitioners while doing Agile UCD.[7]
| Problem | Symptoms | Possible Solutions |
|---|---|---|
| Not enough design time | • Developers waiting on designs • Design quality drop • Designs not verified with customers |
• Separate and parallel UX Design/Developer tracks[8][9][10][11][12] • Scope UX activities to be small, incremental[8][9] • RITE formative usability testing [13][14] • Rapid contextual design[15] • "Design studio"[16] • Design chunking[8] • Combine different UX activities into one session[17] • Bring user (and data) to you[17] • Lighten requirements gathering process[8][9][10][11][18] [8][9][10][11][18] |
| Sprints are too short | • Designs can't be finished in time • No time for usability testing • No time to set up customer contact |
• Separate and parallel UX Design/Developer tracks [8][9][10][11][12] • Scope UX activities to be small, incremental[8][9] • RITE formative usability testing[13][14] • Rapid contextual design[15] • "Design studio"[16] • Design chunking[8] • Combine different UX activities into one session[17] • Bring user (and data) to you[17] • Lighten requirements gathering process[8][9][10][11][18] |
| Not enough user feedback | • Feedback not early enough • No data to act on – opinions rule • Product isn't validated |
• Separate and parallel UX Design/Developer tracks[8][9][10][11][12] • Scope UX activities to be small, incremental[8][9] • RITE formative usability testing[13][14] • Rapid contextual design[15] • "Design studio"[16] • Design chunking[8] • Combine different UX activities into one session[17] • Bring user (and data) to you[17] • Lighten requirements gathering process[8][9][10][11][18] |
| Weak agile "customer"[16] | • End-users and clients won't participate • Cannot get buy-in from rest of team • Non informed decisions are made |
• UX person can act as Agile customer role[19] • Each UX person works on one scrum team[19] • Choose which scrum teams to work with wisely[18] • Validated designs are passed to developers to implement[8][9] • UX participates in cycle planning,[9] bringing appropriate user feedback[8] • No features go in unless something comes out[18] |
| UX is not full-time on one agile team | • UX time spent in many meetings instead of on designs and iterations • Demoralized by UX quality drop |
• UX person can act as Agile customer role[19] • Each UX person works on one scrum team[19] • Choose which scrum teams to work with wisely[18] • Validated designs are passed to developers to implement[8][9] • UX participates in cycle planning,[9] bringing appropriate user feedback[8] • No features go in unless something comes out[18] |
| No sprint/cycle planning | • Large backlog of features/bugs • Prioritization feedback ignored • No control over timing of designs |
• UX person can act as Agile customer role[19] • Each UX person works on one scrum team[19] • Choose which scrum teams to work with wisely[18] • Validated designs are passed to developers to implement[8][9] • UX participates in cycle planning,[9] bringing appropriate user feedback[8] • No features go in unless something comes out[18] |
| User feedback is ignored | • Feature set is cast in stone • No time to incorporate changes • No re-ordering of features is allowed |
• UX person can act as Agile customer role[19] • Each UX person works on one scrum team[19] • Choose which scrum teams to work with wisely[18] • Validated designs are passed to developers to implement[8][9] • UX participates in cycle planning,[9] bringing appropriate user feedback[8] • No features go in unless something comes out[18] |
| Missing the "big picture" | • No shared vision or end goal • Too much focus on details • Hard to prioritize/make design decisions |
• Persuade agile team to adopt Cycle Zero[8][9][10][11][20] [8][9][10][11][18] • Consider design goals from different levels of detail (product, release, capability, design chunk[12] |
| Poor communication | • Misunderstood designs • Agile team doesn't buy-into designs • Important information is lost |
• Include developers in design process[8][9] • Usability included in acceptance criteria[8][9] • Daily contact to check progress[8][9] • Design cards for stand-up meetings[8] • Issue cards for usability reporting[8] • Documents are for design team[8] |
| Team isn't co-located | • No sense of team – lack of trust • Language and/or time barriers • Not enough communication |
• Remote work tools (phone and web-based replacements[11][18] • Co-locate for cycle planning[11][18] |
| Dependency issues | • Requiring input from non-agile teams (e.g., marketing sign-offs, lawyers) | • A scrum leader or facilitator with strong persuasion skills can move things along quickly.[18] |
References[edit]
- ^ a b c Memmel, T (2006). Agile Usability Engineering. Retrieved 4 November 2013 from http://www.interaction-design.org/encyclopedia/agile_usability_engineering.html
- ^ Constantine, L. L., Lockwood, L. A. D. (2002). Usage-centered engineering for web applications. IEEE Software, 19(2), 42-50. doi:10.1109/52.991331
- ^ Stober, T., Hansmann, U. (2010). Agile software development: Best practices for large software development projects. (p. 3.7.2). Berlin, Heidelberg: Springer-Verlag.
- ^ McInerney, P. & Maurer, F. (2005, November). UCD in agile projects: Dream team or odd couple?. ACM Interactions, 12(6), 19-23. doi:: 10.1145/1096554.1096556
- ^ Ambler, Scott W., (2002). Agile modeling: effective practices for extreme programming and the unified process. Available from http://common.books24x7.com/toc.aspx?bookid=3755
- ^ Wolkerstorfer, P., Manfred T., et al. Probing an agile usability process. CHI ‘08 extended abstracts on human factors in computing systems, April 5, 2008, New York, NY. doi:10.1145/1358628.1358648
- ^ a b Sy, D., Miller, L. (2009). Agile user experience SIG. CHI '08 extended abstracts on Human factors in computing systems, 751-2754. doi:10.1145/1520340.1520398
- ^ a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac Sy, D. Adapting Usability Investigations for Agile User-centered Design. Journal of Usability Studies 2, 3 (2007), 112--132
- ^ a b c d e f g h i j k l m n o p q r s t u v w Miller, L., Case Study of Customer Input For a Successful Product, Proceedings of the Agile Development Conference, p.225-234, July 24–29, 2005. doi:10.1109/ADC.2005.16
- ^ a b c d e f g h i Federoff, M., Villamor, C., Miller, L., Patton, J., Rosenstein, A., Baxter, K., Kelkar, K., Extreme usability: adapting research approaches for agile development, CHI '08 extended abstracts on Human factors in computing systems, April 05–10, 2008, Florence, Italy. doi:10.1145/1358628.1358666
- ^ a b c d e f g h i j k Sy, D., Miller, L., Optimizing agile user-centered design, CHI '08 extended abstracts on human factors in computing systems, April 05–10, 2008, Florence, Italy. doi:10.1145/1358628.1358951
- ^ a b c d Patton, J. Twelve emerging best practices for adding UX work to Agile development. Oct 3, 2008: "Twelve (12) emerging best practice for adding user experience work to agile software development". Archived from the original on 2013-09-14. Retrieved 2013-12-14.
- ^ a b c Medlock, M., Terrano, M., Wixon, D. Using the RITE Method to Improve Products: A Definition and a Case Study. Proceedings of UPA 2002.
- ^ a b c Schrag, J. Using Formative Usability Testing as a Fast UI Design Tool. Proceedings of UPA 2006.
- ^ a b c Holtzblatt, K., Wendell, J.B., and Wood, S. (2005) Rapid Contextual Design. Morgan Kaufmann/Elsevier.
- ^ a b c d Ungar, J., White, J., Agile user centered design: enter the design studio – a case study, CHI '08 extended abstracts on Human factors in computing systems, April 05–10, 2008, Florence, Italy. doi:10.1145/1358628.1358650
- ^ a b c d e f Sy, D. Formative usability investigations for open--ended tasks. Proceedings of UPA 2006.
- ^ a b c d e f g h i j k l m n o p Sy, D., Miller, L., Informal SIG: Optimizing Agile UCD, CHI 2007
- ^ a b c d e f g h Miller, L. Interaction Designers and Agile Development: A Partnership. Proceedings of UPA 2006.
- ^ Sharp, H., Biddle, R., Gray P., Miller, L., Patton J., Agile development: opportunity or fad?, CHI '06 extended abstracts on Human factors in computing systems, April 22–27, 2006, Montréal, Québec, Canada. doi:10.1145/1125451.1125461