Simple things should be simple, complex things should be possible.
—Ward Cunningham, XP contributor and inventor of the wiki
A common Agile challenge is how to incorporate the visual design and navigation (User Experience (UX) and User Interface (UI)) into a rapid iteration cycle. When teams attempt to resolve complex (and seemingly subjective!) user interactions while trying to code and test incremental deliverables at the same time, they can often end up “churning” through many iterations. This can be a source of frustration with the Agile process. UX/UI implementation is further complicated by the necessity of user experience testing. As running user experience tests and gaining feedback cannot always occur within the same iteration that implements new functionality, the result can be delayed feedback that complicates productivity and introduces delays in delivery.
Fortunately, Agile teams have found a number of practices for addressing this important design element. Keys include having the UX design track a bit ahead as part of the architectural runway for a system, centralizing design but not implementation, and leveraging iterations and working code to drive out uncertainty and risk through fast feedback.
Summary Role Description
In SAFe, Agile Teams have the responsibility for implementing the code, including the user interface (UI) elements. However, in order to provide a consistent user experience across the components and systems of the larger solution, one or more User Experience designers is typically dedicated to the Agile Release Train. In general, they need to track a bit ahead, and be ready with wireframes, style sheets and other artifacts as part of the Architectural Runway necessary to provide some common guidance for the new Program Increment functionality.
UX Designers typically have the following responsibilities:
- Work with stakeholders to understand the specific business targets behind the user-system interaction
- Provide Agile teams with the next increment of UI design, UX guidelines, and design elements in a just-in-time, (but timely enough) fashion
- Continually validate user experience via user experience testing
- Work with System Architects and teams to build and maintain the technical foundation for real-time UX validation, feedback, tracking statistics etc.
- Share UX guidelines across the program; educate developers on the best practices of maintaining good UI design
- Assist test engineers and the System Team in UX testing and testing automation
- Lead UI design workshops and UX/UI Community of Practice
- Attend sprint planning, backlog refinement and PI and System Demos whenever critical UI-related work is involved
UX/UI Design in Agile
In Agile the flow of UX design is somewhat different and typically includes the following characteristics:
- Uses low-fidelity prototyping to develop runway for future implementation
- Is extremely incremental
- Relies on fast and frequent feedback via rapid code implementation
- Is highly collaborative
- Uses Spikes for UX research activities
- UI criteria are included in Definition of Done and User Story acceptance criteria
UX in Relation to System Design and Testing
In order to enable an effective UX design process and fast and reliable UI implementation, the following design criteria are important:
- Clear separation of UI and application logic
- Effective UI coding conventions
- Effective organization of UI assets and ease of re-use, extension and modification of styles
- Support for collection of usage statistics, UI error logging, feedback mechanism
Many of the UX guidelines and requirements are directly testable. Some can even be automated more simply the other functional tests. (For example: a simple test script could check for “use horizontal menus on all screens”, and thereby prevent developers from accidentally diverging from this criteria.)
UX Designers in Agile Program
Most solutions elements interact with the user in some fashion, so proper UX design is as important (or sometimes even more important) than other aspects of good software system engineering, especially in the larger systems. This impacts that the way in which UX Designers collaborate with the rest of the program. The following two organizational models are the most common.
Centralized UX Guidance and Implementation
Although it might appear attractive from the perspective of empowerment and velocity of the Agile team, fully distributing UX development to the team can be problematic. Therefore, some organizations create a central user interface design team (as in Figure 1) that iterates somewhat independently from the development teams. They run a common cadence and iteration model, but their backlog will contain user experience story spikes, user experience testing, prototyping, and implementation activities that are used to define a common user experience. They typically work one or two iterations ahead to discover upcoming functionality and define how it should be implemented.
Distributed, Governed UX Development
However, it’s likely that the central team becomes a bottleneck for the development teams, and worse, the problem gets larger at scale, because there are a larger number of dependencies that must be addressed. To mitigate this problem, we’ve seen a hybrid model effectively applied for larger systems, as shown in Figure 2.
In the “distributed but governed” model, there is a small, centralized UX design team who provides the basic design standards and preliminary mock-ups for each UI, but the teams have team-based UX implementation experts for the implementation. In this case, the UX experts are distributed among the teams, but the centralized authority provides HTML designs, CSS style sheets, brand control, mock-ups, usability guidelines, and other artifacts that provide conceptual integrity of the UX across the entire solution. The central team also typically attends iteration and PI demos to see how the overall system design is progressing.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chap. 7.
Last update 21 July, 2014
This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.