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 has been defined in order to make usability engineering more light-weight in order to work with agile software development. Many of the processes used are the same as the ones used in agile software development.
Early implementations of usability engineering in User-centered design came into professional practice during the mid to late 1980's. Early implementations of agile software development evolved in the mid 1990's. However, it has been only within past few years that the human-computer interaction community has seen widespread acceptance of agile usability engineering.[1]
History
When methods like Extreme programming and Test driven development were introduced by Kent Beck, usability engineering needed to become light-weight 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. These time-driven projects have helped individuals be able to 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 is when Larry Constantine and Lucy Lockwood designed a browser-resident classroom information management system. During this process, the design team worked 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, mockups were iteratively designed to achieve the objective. The end product achieved, “the stringent design objective of enabling immediate, productive use of the system based on a single-page tutorial.”[2]
Table 1 displays the differences 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. |
Table 1: Comparison of heavy- and light-weight processes exemplified by a few chosen aspects of principles and methods. [1]
Methods
Many projects that are used in the agile software development process can benefit from agile usability engineering. Any projects 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, named the Transition Phase in the IBM Rational Unified Process, users work with the product or service in order to provide feedback, problem reports, and new requirements to the developers. The process is done iteratively 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 (project management).
Paul McInerney and Frank Maurer administered a case study that confirmed 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
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.
| 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][18][11] [8][9][10][18][11] |
| 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][18][11] |
| 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][18][11] |
| 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][20][11] [8][9][10][18][11] • 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 |
• Telecommuting tools (phone and web-based replacements[18][11] • Co-locate for cycle planning[18][11] |
| 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] |
Table 2. Summary of the main problems experienced by User Experience practitioners while doing Agile UCD.[7]
References
- ^ a b c d 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.ezproxy.rit.edu/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-centred 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: http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html
- ^ 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 Kaufman/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 Cite error: The named reference "fourteen" was defined multiple times with different content (see the help page).
- ^ 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
More Info
[1] Interaction Design Encyclopedia