With more development moving to an Agile process, User Experience and Design (UXD) professionals are faced with the task of adapting their activities, deliverables, and even their own role to an Agile development process. Education on general Agile development principles and activities is readily available (for example, see IBM Agile resources). While Agile development principles and best practices such as continuous user feedback and iterative development are familiar to UXD professionals, the focus on efficiency and time-boxed iterations can present a challenge.
To develop a list of best practices for the UXD professional using an Agile development process, we reviewed many of the first IBM Agile projects and external industry references. All these best practices are targeted at maintaining a focus on stakeholders and users while increasing productivity and efficiency.
These best practices are organized in the following general categories:
- Incorporating continuous user feedback
- Working across multiple iterations
- Understanding your stakeholders
- Designing the user experience
Incorporating continuous user feedback
Continuous user feedback is one of the core principles of the Agile process and leverages UXD professionals' skills in user research and evaluation. Many Agile project teams use stakeholder "proxies" to provide design and development feedback across multiple iterations. These proxies often have detailed knowledge of many stakeholders, but they are not a substitute for actual customers and users.
- All stakeholders (principals, users, partners/deployers, and developers) should be an integral part of the design and development team. Many IBM development teams have received ongoing feedback through design feedback programs, managed beta programs, and customer advisory councils.
- Customer "proxies" (representatives for actual customers) are useful to provide high-level feedback and guidance, especially for principals and users. Proxies can be members of the development team with in-depth customer knowledge, such as user researchers, marketing/sales representatives, technical services teams, support staff, or architects with extensive customer contact. You might be able to identify employees within your organization with roles and goals similar to your customers. Such customer proxies can provide first approximations or "quick and dirty" validation of design or requirements, but they should never be considered a substitute for working directly with users. All key product design and development decisions should be validated or tested with representative stakeholders, preferably in their business context.
Working across multiple iterations
One of the biggest challenges of Agile development is the time-boxed iterations. The UXD professional is faced with doing user research, design, and evaluation for each iteration and then repeating the process for subsequent iterations. This typically requires working on multiple iterations during the same time period. For example, you may be doing design for iteration N while evaluating iteration N-1 and doing user research or developing user stories for iteration N+1.
- Cycle 0: Use the initial project start-up time before code development begins to do user research and high-level design, even though the design will undoubtedly change over iterations. This information should be communicated in the vision document, use cases, and user stories.
- User research and design for a specific iteration should precede the actual code development for that release. Ideally, this would be done at least one iteration in advance of development although it can also be done "just in time" early in the iteration.
- Usability evaluations with live code will take place after the milestone is made available to users.The results from these evaluations should be fed into the subsequent releases.
- Non-UXD professionals may be able to assist or perform some traditional UXD activities. For example, product testers may help with evaluations and user interface developers may help with basic UI design.
Understanding your stakeholders
As mentioned above, it is important to understand all the stakeholders for your product: the principals who make the purchasing decision, the business partners or deployers who are responsible for installing and configuring your product, the users who will interact with the product, and the development team. Although you may have some representative stakeholders or proxies on your design team, it is also important to communicate this stakeholder information to everyone on the project team.
- User research should include a definition of the roles, personas, goals, tasks, environment of use, and limitations and constraints. This information should be communicated in the product vision document, personas, and user stories.
- Use cases, green threads, and user stories should be used to describe the overall value of the product, as well as the value of each milestone driver.
- Standardized user roles and personas (especially if they are from the previous release of the product) can serve as the templates or building blocks for your product to improve consumability, integration, and team productivity. If you are reusing user research, be sure to validate it with your targeted user group.
Designing the user experience
If you have an existing user interface architecture from a previous release, or you have done the high-level design in Cycle 0, then design can focus on an upcoming iteration. In keeping with the Agile principle of reducing waste, prototyping can be used effectively to communicate design, get early user feedback, and reduce development effort. Wherever possible, leverage existing best practices in design through the use of design patterns, widgets, and visual elements such as icons.
- User interface prototyping is still feasible in Agile development. Use high-fidelity prototyping for user interactions that are difficult to code (to eliminate waste) or are difficult to evaluate with low-fidelity prototypes.
- Get iterative user feedback on designs prior to code development to ensure that development time is well spent.
- Product builds can also be used for early user feedback and evaluation. In many cases this can be done before the milestone driver is ready to ship. Builds are also an ideal time to ensure that the design is being implemented as intended.
- Design must be communicated in some form to the development team, although extensive User Interface Specifications are not popular in an Agile development process. Consider using prototypes, wireframes, screen captures, or other lightweight design specifications.
- Design changes should be communicated through daily scrum meetings.
- Designers and developers should utilize reusable assets (for example, design patterns, widgets, visual elements) and tools as much as possible for consistency and productivity.
