Chapter 19
UX Methods for Agile Development
Objectives
After reading this chapter, you will:
1. Understand the basic characteristics of agile SE methods
2. Recognize the drawbacks of agile SE methods from the UX perspective
3. Know what is needed to integrate UX into an agile environment
4. Understand a synthesized approach to integrating UX into an agile environment
5. Appreciate the need for a dove-tailed staggering of process steps for UX to fit into the overall development process
19.1 Introduction
Just as our use of the term UX is convenient shorthand for the entire broad concept of designing for user experience, we use the term “SE” to refer to the entire broad concept that embraces the terms software engineering, software, software development, and the software engineering domain. This chapter is about an important way those two domains can come together in an efficient project development environment.
We believe that the rigorous UX process (Chapters 3 through 12 and 14 through 17) is the most effective path to ensuring a quality user experience with systems with complex work domains and complex interaction. However, because the fully rigorous UX process is also the most expensive and time-consuming, it cannot always be applied. Nor is it always appropriate, for example, for systems and products at the other end of the system complexity space in Figure 2-7.
Domain-Complex Systems
Domain-complex systems are systems with a high degree of intricacy and technical content in the corresponding field of work. Often, characterized by convoluted and elaborate mechanisms for how parts of the system work and communicate, they usually have complicated workflow containing multiple dependencies and communication channels. Examples include an air traffic control system and a system for analyzing seismic data for oil exploration.
Less-than-perfect development environments, short schedules, and limited budgets demand effective ways to adapt UX process methods to the turmoil and pressure of the real professional world. Anxious customers, especially for systems with simple domains such as commercial products, may demand early deliverables, including previews of prototypes about which they can give feedback. In such cases practitioners can use abridged versions of the fully rigorous lifecycle process, skipping some process activities altogether and using rapid techniques for others.
Alternatively, the software development side might require an agile development environment. Agile SE approaches, now well known and popularly used, are incremental, iterative, and test-driven means of delivering pieces of useful working software to customers frequently, for example, every two weeks. However, agile SE approaches do not account for UX. Because traditional UX processes do not fit well within a project environment using agile SE methods, the UX side must find ways to adjust their methods to fit SE constraints.
Agile
Agile development is a rapid and lightweight approach to software and system development characterized by ultra fine-grained iteration. Coding begins very early, producing early and frequent small releases representing small but working functionality.
Therefore, the entire system development team needs an overall approach that includes UX while retaining the basics of the SE approach. In this chapter we present a variation of our UX process methods that will integrate well with existing agile SE processes by accounting for the constraints imposed by those agile SE processes.
We begin by describing the essence of the agile SE approach and then identify what is needed on the UX side so that the two processes fit together. Finally, we describe an approach that brings the UX lifecycle process and agile SE together, retaining the essentials of each but requiring some adjustments on both sides.
19.2 Basics of agile se methods
Much of this section is based on Beck (2000), one of the most authoritative sources of information on agile SE development methods as embodied in the approach called eXtreme Programming (XP).1 We have taken words from Beck and other authors and tried to blend them into a summary of the practice. Accurate representations are credited to these authors while errors in representation are our fault.
19.2.1 Characteristics of Agile SE Methods
Agile SE development methods begin coding very early. Agile SE has a shorter, almost nonexistent, requirements engineering phase and far less documentation than that of traditional software engineering. As typified in XP, agile SE code implementation occurs in small increments and iterations.
Small releases are delivered to the customer after each short iteration, or development cycle. In most cases, these small releases, although limited in functionality, are intended to be working versions of the whole system, which run by themselves. Nonetheless, each release is supposed to deliver some useful capability for the customer.
In simplest terms, agile SE development methods “describe the problem simply in terms of small, distinct pieces, then implement these pieces in successive iterations” (Constantine, 2002, p. 3). Each piece is tested until it works and is then integrated into the rest. Next the whole is tested in what Constantine calls “regression testing” until it all works. As a result, the next iteration always starts with something that works.
To clarify the concept of agile software methods, a group met at a workshop in Snowbird, Utah in February 2001 and worked out an “agile manifesto” (Beck, 2000). From their stated principles behind this manifesto, goals for agile software development emerged:
Satisfy the customer by giving them early and continuous deliverables that produce valuable and working software.
Recognize that changing requirements are the norm in any software development effort.
Understand that time and budget constraints must be managed.
Practitioners of agile SE methods value (Beck, 2000):
Individuals and interactions over processes and tools
Working software over comprehensive documentation
The agile software development methods are further characterized by the need for communication, especially continuous communication with the customer. Informal communication is strongly preferred over formal. Close communication is emphasized to the point that they have an onsite customer as part of the team, giving feedback continuously.
A main principle of agile SE methods is to avoid Big Design UpFront (BDUF). This means the approach generally eschews upfront ethnographic and field studies and extensive requirements engineering. The idea is to get code written as soon as possible and resolve problems by reacting to customer feedback later.
And because change is happening everywhere, SE practitioners verify that they are writing the code correctly by the practice of pair programming. Code is written by two programmers working together and sharing one computer and one screen, that is, always having a colleague watching over the programmer’s shoulder.
Of course, pair programming is not new with agile methods. Even outside agile SE methods and before they existed, pair programming was a proven technique with a solid track record (Constantine, 2002). Another way they verify the code being written is via regular and continuous testing against an inventory of test cases.
19.2.2 Lifecycle Aspects
If this process were to be represented by a lifecycle diagram, it would not be a waterfall or even an iteration of stages, but a set of overlapping micro-development activities. In the waterfall approach, developers finish entire requirements analysis before starting design and the entire design before starting implementation.
But in agile approaches developers do just enough—a micro-level of each activity—to support one small feature request; see Figure 19-1, which illustrates XP as an example agile method. In the middle of these extremes are approaches where these activities are performed in larger scope units. In these middle-of-the-road approaches, lifecycle activities are applied at the level of overall system components or subsystems. In contrast, in agile methods it is applied at the level of features in those components.
Figure 19-1 Comparison of scope of development activities across methodologies, taken with permission from Beck (1999, Figure 1).
For example, building an e-commerce Website in the waterfall approach would require listing all requirements that must be supported in the Website before starting a top-down design. In an agile approach, the same Website would be built as a series of smaller features, such as a shopping cart or check out module.
19.2.3 Planning in Agile SE Methods
In our discussion of how an agile SE method works, we are roughly following XP as a guide. As shown in Figure 19-2, each iteration consists of two parts: planning and a sprint to implement and test the code for one release.
Figure 19-2 Abstraction of an agile SE release iteration.
Customer stories
The planning part of each iteration in Figure 19-2 yields a set of customer-written stories, prioritized by cost to implement. A customer story, a key concept in the process, has a role a bit like that of a use case, a scenario, or a requirement. A customer story, written on a story (index) card, is a description of a customer-requested feature. It is a narrative about how the system is supposed to solve a problem, representing a chunk of functionality that is coherent in some way to the customer.
Story-based planning
Expanding the “planning” box of Figure 19-2, we get the details of how customer stories are used in planning, as shown in Figure 19-3.
Figure 19-3 Customer stories as the basis of planning.
As shown in Figure 19-3, developers start the planning process by sitting down with onsite customer representatives. They ask customer representatives to think about the most useful chunks of functionality that can add business or enterprise value. The customer writes stories about the need for these pieces of functionality. This is the primary way that the developers understand users and their needs, indirectly through the customer representatives.
Developers assess the stories and estimate the effort required to implement (program) a solution for each, writing the estimate on the story card. Typically, in XP, each story gets a 1-, 2-, or 3-week estimate in “ideal development time.”
The customer sorts and prioritizes the story cards by choosing a small set for which the cost estimates are within a predetermined budget and which represent features they want to include in a “release.” Prioritization might result in lists of stories or requirements labeled as “do first,” “desired—do, if time,” and “deferred—consider next time.” Developers break down the stories into development tasks, each written on a task (for the developers to do) card.
The output of the planning box, which goes to the upcoming implementation sprint, is a set of customer-written stories, prioritized by cost to implement.
Controlling scope
Customer stories are the local currency in what Beck (2000, p. 54) calls the “planning game” through which the customer and the developers negotiate the scope of each release. At the beginning there is a time and effort “budget” of the person-hours or level of effort available for implementing all the stories, usually per release.
As the customer prioritizes story cards, the total of the work estimates is kept and, when it reaches the budget limit, the developers’ “dance card” is full. Later, if the customer wants to “cut in” with another story, they have to decide which existing customer story with an equal or greater value must be removed to make room for the new one. So no one, not even the boss, can just add more features.
This approach gives the customer control of which stories will be implemented but affords developers a tool to battle scope or feature creep. Developer estimates of effort could be way off, probably in most cases underestimating the effort necessary, but at least it lets them draw a line. With experience, developers get pretty good at this estimation given a particular technology platform and application domain.
19.2.4 Sprints in Agile SE Methods
Expanding the “sprint” box of Figure 19-2, as shown in Figure 19-4, each agile SE sprint consists of activities that are described in the following sections.
Figure 19-4 An agile SE sprint.
Acceptance test creation
The customer writes the functional acceptance tests. There is no process for this, so it can be kind of fuzzy, but it does put the customer in control of acceptance of the eventual code. With experience, customers get good at this.
Unit code test creation
The team divides the work by assigning customer stories to code for that sprint. A programmer picks a customer story card and finds a programming partner. Before any coding, the pair together writes unit tests that can verify that functionality is present in the code that is yet to be written as an implementation.
Implementation coding
The programming pairs work together to write the code for modules that support the functionality of the customer story. As they work, the partners do on-the-fly design (the agile SE literature says almost nothing about design).
The programmers do not worry about the higher level architecture; the system architecture supposedly evolves with each new slice of functionality that is added to the overall system. The programming pair integrates this code into the latest version.
Code testing
Next, the programming pair runs the unit code tests designed for the modules just implemented. In addition, they run all code tests again on all modules coded so far until all tests are passed. By testing the new functionality with not only tests written for this functionality, but with all tests written for previous pieces of functionality, SE developers make sure that the realization of this functionality in code is correct and that it does not break any of the previously implemented modules. This allows developers to make code modifications based on changing requirements, while ensuring that all parts of the code continue to function properly.
Acceptance testing and deployment
Developers submit this potentially shippable product functionality to the customer for acceptance review. Upon acceptance, the team deploys this small iterative “release” to the customer.
19.3 Drawbacks of agile se methods from the UX perspective
From the SE perspective, much about agile SE methods is, of course, positive. These methods make SE practitioners feel productive and in control because they, and not some overarching design, drive the process. These methods are less expensive, faster, and lighter weight, with early deliverables. The pair-programming aspect also seems to produce high-reliability code with fewer bugs. Nonetheless, agile SE methods are programming methods, developed by programmers for programmers, and they pose some drawbacks from the UX perspective.
Agile SE methods, being driven predominantly by coders, are optimized for code, judged by quality of code, and have a strong bias toward code concerns. There is no definition or consideration of usability or user experience (Constantine, 2002). Users, user activities, and the user interface are not part of the mix; the user interface becomes whatever the code hackers produce by chance and then must be “fixed” based on customer feedback.
In addition, there is no upfront analysis to glean general concepts of the system and associated work practice. The one customer representative on the team is not required even to be a real user and cannot represent all viewpoints, needs and requirements, usage issues, or usage context. There may be no real user data at all upfront, and coding will end up being “based only on assumptions about user needs” (Memmel, Gundelsweiler, & Reiterer, 2007, p. 169). There is no identification of user tasks and no process for identifying tasks.
Beyer, Holtzblatt, and Baker (2004) echo this criticism of using a customer representative as the only application domain expert. As they point out, under their “Axiom 2: Make the user the expert,” many customer representatives are not also users and, therefore, cannot necessarily speak for the work practice of others. Instead, they recommend devoting an iteration of contextual analysis with real users to requirements definition. They say they have done quick contextual design with five to eight users through early design solutions in one to two weeks.
Beyond these specific drawbacks, the agile SE method has no room for ideation in design. And it can be difficult to scale up the process to work on very large systems. The number of customer stories becomes large without bounds. Similarly, it is difficult to scale up to larger development groups; the time and effort to communicate closely with everyone eventually become prohibitive and close coordination is lost.
19.4 What is needed on the UX side
In some ways, the UX process lifecycle is a good candidate to fit with agile software methods because it is already iterative. But there is a big difference. The traditional UX lifecycle is built on having a complete understanding of users and their needs long before a single line of software code is ever written. In this section we discuss the considerations necessary to adjust UX methods to adapt to agile SE approaches (Memmel, Gundelsweiler, & Reiterer, 2007).
To work in the UX domain, an agile method must retain some early analysis activities devoted to understanding user work activities and work context and gleaning general concepts of the system. At the same time, to be compatible with the agile SE side of development, UX methods must:
emphasize team collaboration and require co-location
include effective customer and user representatives
adjust UX design and evaluation to be compatible with SE sprint-based incremental releases by switching focus from top-down holistic design to bottom-up features design
Thoughts on Integrating UX into Agile Projects
Dr. Deborah J. Mayhew, Consultant, Deborah J. Mayhew & Associates1
CEO, The Online User eXperience Institute2
I have been working in software development since 1975 and have watched a number of formal, commercial software engineering methodologies (including one of the first in the industry) emerge, evolve, and be abandoned for the next new idea. The latest one is agile, which has been around for almost 10 years now. When it first emerged I had been working in the UX field for about 20 years. I had written my book The Usability Engineering Lifecycle (1999b, Morgan Kaufmann Publishers), which describes a top-down, iterative approach to software user interface design set in the context of the prevalent development methodologies at that time: object-oriented software engineering and iterative development. The Usability Engineering Lifecycle (UEL) fit in quite nicely with those software engineering methodologies.
Then the agile methodology began to get popular. Initially, I learned about this new development methodology by working with a client who was building project management software tools to support agile project managers. I was trying to help this client design a usable interface to their software tools, and they were developing their tools using the agile methodology, so I had to try to adapt my approach to usability engineering into that methodology.
I struggled with this because it seemed to me that there was an inherent conflict: the agile methodology focuses on very small modules of functionality and code at a time, doing requirements analysis, design and development start to finish on each one, often with different development teams assigned to different modules being developed on overlapping timelines.
In contrast, the successful design of a user interface requires a top-down approach because all the functionality must be presented through a consistent overall architecture. A piecemeal approach to interface design, in which many different developers design separate modules of code, had always been a big stumbling block to good user interface design in the past, and it seemed that the agile methodology would perpetuate that problem even while solving others.
So, I was skeptical that good usability engineering practices could be applied successfully in an agile development environment.
I have only recently had another opportunity to work with a development team following some version of the agile methodology and have evolved with them what I think is a successful approach to overcoming the potential conflicts between agile and the UEL approach to designing for an optimal user experience.
My client had already adapted the agile methodology in a way consistent with Nielsen’s findings about best practices for integrating usability engineering into agile development projects (Jakob Nielsen’s Alertbox, November 4, 2009, http://www.useit.com/alertbox/agile-user-experience.html). In Nielsen’s words, the key things are to
Separate design and development, and have the user interface team progress one step ahead of the implementation team …
and to
Maintain a coherent vision of the user interface architecture. Create the initial vision during a ‘sprint zero’ period—before any implementation has started—and maintain it through annual (or semi-annual) design vision sprints …
I believe that these approaches are necessary but not sufficient. They do not solve the problem of separate agile teams creating different modules of code, with no one overseeing the user interface across the whole system. Each team can do visioning up front, and design before development in a “sprint zero” phase, but that does not ensure consistency in the user interface across code modules developed by different teams.
My client had embarked on a very large, multiyear project. They were breaking down what in the end would be one very large functionally rich system into small chunks of functionality and assigning these chunks to different agile teams, each with their own assigned user interface designers. These teams were working mostly independently on overlapping project schedules. They had an approach similar to Nielsen’s ideas of a planning phase at the beginning of each project for high-level design, and a “sprint zero” in which detailed user interface design could start and stay a step ahead of coding. There was, however, only haphazard communication and coordination across teams regarding user interface design.
To be a little more concrete, an analogous project to the one I actually worked on would be the development of a system to support the customer support representatives of a credit card company. The functional chunks cast as separate projects in this analogy would be individual user tasks, such as processing requests for monthly payments, balance transfers from other credit cards, adding new credit cards to an account holder’s account, closing out an account, contesting a fraudulent charge, and the like. A single customer service representative might be handling all these types of tasks, but different agile teams were designing and developing them.
When I got involved with my client’s overall effort, separate projects were at many different stages in their agile processes, some still in the early planning and designing stages, others well along in their sprint process. My role was to provide feedback on design ideas generated by the project interaction designers on the projects, some of which were in early planning, some in sprint zero, and some halfway or more through their sprints.
I started performing heuristic evaluations for individual agile teams, one at a time. As I proceeded from project to project, I naturally started seeing two things: inconsistencies in interface design across projects and less than optimal designs within projects. In response to these observations, I started doing two things.
First, with each heuristic evaluation, I documented some sample redesign ideas in wireframe form to better communicate the issues I was identifying. As I went from one project to the next, I consistently applied the same redesign approaches when I encountered analogous design situations. So, for example, the first time I discovered a need for a widget to expand and contract details, I would document a particular design for that purpose. Then when I encountered the same need on another project, I would be sure to recommend the exact same design to address that need.
Second, I started capturing in list form those design situations that were coming up repetitively across pages and projects (the need to expand and contract information details would be an example of something in that list). This list became the foundation of what would eventually become a set of user interface design standards for the whole system. Those standards might not exactly reflect my design suggestions, but at least everything that a standard could be designed for would be identified and documented in one place.
Sometimes I would design for a situation when I first encountered it, apply it in later situations, and then even later come across the same situation on a new page or project in which my design solution just did not work well. In those cases, I would revisit the consistent design I had generated to date, redesign it, and then reapply the new standard to all analogous situations encountered across all projects I had evaluated to date, as well as going forward.
In this way, a common set of standards was continuously developed and evolved as each new agile project launched and proceeded. Rework was required when the need for a different standard was discovered on new but analogous functionality, but at least there was a single mind (mine) overseeing all the related agile projects so that opportunities for consistency were discovered and ultimately attended to. This just does not happen when different designers are responsible for different modules of functionality and no one is keeping track of the big picture.
I think proceeding in this way to design the overall user interface of a system that is divided up into many agile projects is analogous to designing the system architecture in this methodology. Modules of code designed and developed by separate and relatively independent teams have a similar risk of ending up being a mish mash of inefficient and hard to maintain code. Someone needs to oversee the evolution of the final system architecture, and rework may be required to go back and recode modules that did not adhere to the final system architecture model when they were developed initially. If we are willing to do the rework, this is a reasonable way to address both system architecture and user interface architecture in a methodology that certainly has other benefits but carries the risk of resulting in systems with no underlying models that support both technical and human needs.
19.4.1 The UX Component Must Be Lightweight
According to Memmel, Gundelsweiler, and Reiterer (2007), many of the rigorous UX processes out there, such as Mayhew (1999b), Rogers, Sharp, and Preece (2011), and the full Wheel process described in this book, are considered as heavyweight processes, too cumbersome for the unstoppable trend of shorter time-to-market and shorter development lifecycles. As a result, developers are turning to lighter-weight development processes.
However, the term “lightweight process” can be thought of as a euphemism for “cutting corners.” As Constantine (2001) puts it, “shortcutting a proven process means omitting or short-changing some productive activities, and the piper will be paid, if not now, then later.”
Sometimes, however, we have no choice. The project parameters demand fast turnaround and the rigorous process simply will not do. Therefore, we seek something in the middle ground, a lighter-weight process that, although compromising quality somewhat, can still meet schedule demands and allow us to deliver a system or product with value for the customer.
Traveling light means communicating rather than documenting. In general, heavyweight SE processes require detailed, up-to-date-documentation and models, whereas lightweight SE processes rely on index cards and hand-drawn abstract models. The artifacts maintained should be few, simple, and valuable (Beck, 2000, p. 42).
19.4.2 The UX Component Requires Collaboration and Co-Location with the SE Team
Traditional UX practice often implied handing off a refined interaction design as a formal hi-fi prototype or a complete wireframe deck. We did our contextual inquiry and analysis independently of their requirements gathering. Now this “fire-walling” of the UX and SE teams will not work. We must work together with the same customer representatives and users.
Our deliverables will now be less formal and somewhat incomplete because the details will be handled on a social channel, meaning we will communicate directly, person to person. Each team, UX and SE, must have access and visibility into the other team’s progress, challenges, and bottlenecks so that they can plan to maintain synchronization.
To achieve this intimate communication, the entire project team has to be co-located. You all have to work in the same room, a working arena plus walls for whiteboards, posters, and diagrams. Everyone has to be continuously present as part of the team—readily available and knowledgeable.
You cannot rely on just email or a call on the phone. When you need to talk with someone else on the team, that person must be sitting with you as you work. This imperative for co-location in the agile approach can be a show-stopper. If, for any reason, your organization cannot afford to keep the entire project team in one location, it will preclude the agile approach.
19.4.3 Effective Customer and User Representatives Are Essential
An important SE requirement is continuous access to one or more co-located customer representatives, but on the UX side we will also need access to real users. Many “methods” call for including customers and users. So when you say that you need a customer representative in your project, others in your organization and in the customer organization may not understand how seriously this role is taken in agile methods and how integral it is to project success. Unless you have articulated criteria for the customer representative role, you are likely to get someone who happens to be available regardless of their real connection to the system.
Your customer and user representatives must truly represent the organization paying for development and must care about the project as a real stakeholder in the outcome. These representatives must have a good knowledge of all work roles, corresponding user classes, workflows, and the work domain. And perhaps the most important requirement is that these representatives must have the authority to make decisions about project scope and enough knowledge about what the organization really needs.
19.4.4 A Paradigm Shift: Depth-First, Vertical Slicing
Almost everything in both the process and the deliverables depends on whether the project approach is breadth first or depth first. Acceptance of the outcome will depend on how well the customer understands these choices and agrees to the approach you choose; it is up to you to set expectations accordingly.
The traditional UX process is breadth first, looking at the whole system broadly from the beginning—methodically and systematically building horizontal slices and integrating and growing them vertically. The resulting product is an integrated system design built top-down or inside-out in “horizontal” layers. This approach involves building a whole elephant from the inside out, laying down a skeleton, adding inner organs, fleshing it out with muscles to hold it all together, and wrapping it up with a skin.
However, as we said before, this approach works against early deliverables to the customer. There is often nothing to show customers early on. There just is not anything that even looks like an elephant until halfway or even later through the project.
In traditional development methods, associated deliverables will begin with documentation of development work products and descriptions of design-informing models, such as personas, user classes, or task descriptions. Development does not get to design-representing deliverables such as screen sketches, storyboards, and low-fidelity prototypes until later in the process.
So the customer has to be patient, but “patient” does not describe most customers we have met so far. Nor can you blame them; they do not want to be paying the bills for a long time without seeing any results.
Alternatively, and in almost complete contrast, agile methods are depth first, taking a narrow product scope but starting with more depth, building vertical slices and integrating and growing them horizontally. This is the approach you need when you have limited resources and have short-term demand for design-related deliverables, such as a prototype. The narrow product scope means addressing only a few selected features supporting related user work activities and system functions, but developing them in some depth.
This is like building an elephant by gluing together deep, but narrow, vertical slices. It might be for only a slim section of the backbone, maybe a part of a kidney or a slice of the liver, and a little bit of skin. But you are not going to see anything of the face, the feet, or the tail, for example. In other words, the customer might see some screen sketches and a low-fidelity prototype a lot earlier but they will be limited to a narrow set of features. This agile approach has a benefit in today’s development market in that you can get at least something as a running deliverable much faster.
As more and more vertical slices become available, you put them together to construct the whole system. If slices here and there do not quite line up in this integration step, you must adjust them to fit. As you add each new slice, adjust the new slice and/or the rest of the elephant, as needed.
19.4.5 Controlling Scope Is a Necessity
Earlier in this chapter, we explained that agile SE customer stories are the basis for planning, through which the customer and the developers negotiate the scope of each release. At the beginning there is a time and effort “budget” of only so many person-hours or only a certain level of effort available for implementing all the stories.
Exactly the same approach to controlling scope works when UX and SE are integrated, still using the cost to implement the software as the criterion for setting scope boundaries. However, UX plays an involved role in negotiating with customers based on early conceptual design and user experience needs. More about this soon.
19.5 Problems to anticipate
In a special-interest-group workshop at CHI 2009 (Miller & Sy, 2009), a group of UX practitioners met to share their experiences in trying to incorporate a user-centered design approach into the agile SE process. Among the difficulties experienced by these practitioners in their own environments were:
sprints too short; not enough time for customer contact, design, and evaluation
inadequate opportunities for user feedback and the user feedback they did get was ignored
customer representative weak, not committed, and lack of co-location
no shared vision of broader conceptual design because focus is on details in a bottom-up approach
Regarding the last bullet, building a system a little piece at a time is not without risks. Nielsen (2008) claims that agile methods can end up being a terrible way to do usability engineering. His reasons centered mostly on the fact that taking one piece at a time tended to destroy the whole picture of user experience. If requirements come in piecemeal, it is harder to see the big picture or the conceptual design. He claims that a piecemeal process hinders consistency and is a barrier to an integrated design, leading to a fragmented user experience.
Beyer, Holtzblatt, and Baker (2004) also believe that it is difficult to design small chunks of the interaction design without first knowing the basic interaction design architecture—how the system is structured to support user tasks and how the system functions are organized. In contextual design, interaction architecture is established with storyboards and what they call the “user environment design,” which they say is just what you need for effective user stories.
In the end, it is up to skilled and experienced UX practitioners to keep the big picture in mind and do as much as possible along the way to maintain coherence in the overall design.
19.6 A synthesized approach to integrating UX
Because traditional agile SE methods do not consider the user interface, usability, and user experience, there is a need to incorporate some of the user-centered design techniques of UX into the overall system development process. Most of the related literature is about either adjusting “discount” UX or user-centered design methods to somehow keep pace with existing agile SE methods or trying to do just selected parts of user-centered design processes in the presence of an essentially inflexible agile SE method.
While it is possible that XP, for example, and some abbreviated user-centered design techniques can coexist and work together, in these add-on approaches the two parts are not really combined (McInerney & Maurer, 2005; Patton, 2002, 2008). This creates a coping scenario for the UX side, as UX practitioners attempt to live with the constraints while trying to ply their own processes within an overall development environment driven solely by the agile SE method.
The traditional user-centered design process, even rapid or abridged versions, and the agile SE process are a fundamental mismatch and will always have difficulty fitting together within a project. This means that we need to synthesize an approach to allow the UX process in an integrated agile environment without compromising on essential UX needs, the topic of this section.
Here we especially acknowledge the influence of Constantine and Lockwood (2003), Beyer, Holtzblatt, and Baker (2004), Meads (2010), and Lynn Miller (2010). What we have synthesized here is also built on our experience with traditional UX methods and our broad experience in industry consulting and practice that required quicker and less costly design methods and where customers often demanded early deliverables.
19.6.1 Integrating UX into Planning
Figure 19-5 shows a scheme for integrating the UX role into the planning box of Figure 19-2.
Figure 19-5 Integrating the UX role into planning.
Add some small upfront analysis (SUFA)
If we simply try to include the UX role as an add-on to the agile SE process, the entire operation would still proceed without benefit of any upfront analysis or contact with multiple people in the customer organization and with multiple users in all the key work roles. As a result, there would be no initial knowledge of requirements, users, work practice, tasks, or other design-informing models. This would be crippling for any kind of UX lifecycle process.
Any serious proposal for integrating UX into planning must include an initial abbreviated form of contextual inquiry and contextual analysis, something that we call “Small UpFront Analysis” (SUFA), in the left-most box of Figure 19-5. The UX role works with the customer to perform some limited contextual inquiry and analysis (Chapters 3 and 4).
In addition, the UX person also assists the customer in other responsibilities, such as writing and prioritizing stories. These stories are now called users stories rather than customer stories because their substance came from users in the upfront analysis.
Although this begins to change the basic agile pattern, it gives the UX team more traction in bringing UX into the overall process. Interest in enhancing this kind of additional upfront analysis is gaining ground. There is some initial agreement (Beyer, Holtzblatt, & Baker, 2004; Constantine & Lockwood, 1999) on the necessity for talking with multiple customer representatives and real users to help understand the overall system and design needs.
Some (Constantine & Lockwood, 1999; Memmel, Gundelsweiler, & Reiterer, 2007) add that a measure of user and/or task modeling would be a very useful supplement in that same spirit. There is obviously a resulting loss of agility but, without these additions, the whole approach might not work for UX.
Beyer and Holtzblatt’s “original” approach to upfront analysis and design is called contextual design (Beyer & Holtzblatt, 1998) and has a head start toward agile methods because it is already customer centered. They took another step toward agility with the follow-up book (Holtzblatt, Wendell, & Wood, 2005) and developed that into a true agile method in Beyer, Holtzblatt, and Baker (2004). Much of this section is based on their explication of the agile version of rapid contextual design in this latter reference.
Goals of the SUFA include:
understand the users’ work and its context
identify key work roles, work activities, and user tasks
model workflow and activities in the existing enterprise and system
forge an initial high-level conceptual design
identify selected user stories that reflect user needs in the context of their work practice
Because of the “S” in SUFA, the contextual inquiry and analysis involved must be very limited, but even the most abbreviated contextual studies can yield a great deal of understanding about the work roles and the flow model as well as some initial task modeling. By adding this SUFA we can build a good overview of the system as a framework for talking about the little pieces we will be developing in the agile method.
A broad understanding of scope and purpose of the project (second box from the left in Figure 19-5) will allow us to plan the design and implementation of a series of sprints around the tasks and functionality associated with different work roles. This SUFA has to be focused carefully so that it can occur in a very short cycle—maybe even in one week!
Even though the UX person is trained to do a SUFA and could do it alone, the customer should help with SUFA, as shown at the lower left in Figure 19-5, to be in a better position to later write user stories (next section).
User interviews and observation. Your customer will help you identify users to interview. Create a flow model on the fly and in collaboration with the customer representative. Identify all key work roles in this diagram. Annotate it with all important tasks and activities that can be deduced from the user stories.
Agile contextual inquiry can be as brief or as lengthy as desired or afforded. We suggest interviewing and observing the work practice of at least one or two people in each key work role. There is no recording and no transcript of interviews. The UX practitioners write notes by hand directly on index cards—a Constantine hallmark. Use small size, 3″ × 5″, index cards to discourage verbosity in the notes.
Aim toward effective user stories. We are looking for user stories to drive our small pieces of interaction design and prototyping. But what kind of user stories do we seek? Stories about work activities, roles, and tasks can still be a good way for designers to start. However, as Meads (2010) says, users are not interested in tasks per se, but are more interested in features. Following his advice, we focus on features, which are used to carry out related user work activities and tasks within a work context.
UX role helps customer write user stories
In the third box from the left in Figure 19-5, the UX person helps the customer write user stories. Because both roles participated in the SUFA, user story writing will be easier, faster, and more representative of real user needs. The UX role influences the customer toward creating stories based on workflows observed in the agile contextual inquiry part of SUFA.
UX role helps customer prioritize user stories
By helping the customer representative prioritize the user stories, the UX person can keep an eye on the overarching vision of user experience and a cohesive conceptual design, thereby steering the result toward an effective set of stories for an iteration.
19.6.2 Integrating UX into Sprints
In Figure 19-6 we show UX counterpart activities occurring during an agile SE sprint (Figure 19-4).
Figure 19-6 UX counterpart of an agile SE sprint.
While the SE people are doing a sprint, the UX person and customer perform their own version of a sprint, which is shown in Figure 19-6. They begin by picking a story and, with the conceptual design in mind, start ideation and sketching of an interaction design to support the functionality of the user story.
The design is cast in a narrow vertical prototype for just this feature for evaluation. Often time permits only a low-fidelity (e.g., paper) prototype. If there is time the design partners make a set of wireframes to describe the interaction design. This feature prototype is integrated into their growing overall user interface prototype.
If there is time, the UX design partners do some user experience evaluation on this one part of the design and iterate the design accordingly. If there is even more time (unlikely in an agile environment), in the spirit of agile SE methods, the UX design partners can run this collection of all evaluations again on the whole integrated prototype to ensure that the addition of this design feature did not break the usability of any previous features.
UX practitioners submit this user interface prototype to the customer for acceptance review. Finally, the team “deploys” this small iterative interaction design “release” by sending it on to agile SE developers for coding as part of their next sprint.
19.6.3 Synchronizing the Two Agile Workflows
We have described agile SE planning and agile SE sprints, plus UX integration into planning and UX integration into sprints earlier in this chapter. But we have not yet talked about how the UX and SE teams work together and synchronize the workflow in their respective parts of the agile process.
Dove-tailed work activities
Miller (2010) proposed a “staggered” approach to parallel track agile development that featured a “criss-cross” interplay between UX activities and SE activities across multiple cycles of agile development. As Patton (2008) put in his blog, the overall approach is characterized as “work ahead, follow behind.”
As Patton says, UX people on agile teams “become masters of development time travel, nimbly moving back and forth through past, present, and future development work.”
Based roughly on Miller’s idea, we show a scheme in Figure 19-7 for how UX people and SE people can synchronize their work via a dovetail alternation of activities across progressive iterations.
Figure 19-7 Alternating UX and SE workflow in an agile process.
In the original agile SE approach, SE people started first with sprint 1, taking a set of stories and building a release. That worked when the only thing that was happening was implementation. Now that we are bringing in UX design and evaluation into the mix, we need a few changes.
First, the UX people need some lead time in their sprint 0, in Figure 19-7, to get the interaction designs ready for the SE people in their sprint 1. During this ramping-up sprint 0, SE people can focus on building the software infrastructure and services required to support the whole system, what Miller calls building the “high-development, low-UI features.” When the UX people are done with designs for release 1, they hand them off to SE people for implementation in sprint 1, which includes implementation of both functional stories and interaction design components for that cycle.
Previously, the team had something to release right after sprint 1, but now it takes two sprint cycles, sprint 0 and sprint 1, to get the first release out. This is just a start-up artifact and is not a problem for subsequent releases.
Not all UX design challenges are equal; sometimes there is not enough time to address UX design adequately in a given sprint. Then that design will have to evolve over the design and evaluation activities of more than one sprint. Also, sometimes in interaction design, we want to try out two variations because we are not sure, so that will have to take place over multiple sprints.
Because of the staggering or dovetailing of activities, people on each part of the team are typically working on multiple things at a time. For example, right after handing off the designs for release 1 to the SE people, the UX people start on designs for release 2 and continue doing this until the end of sprint 1 (while the SE people are coding release 1). In any given sprint, say, sprint n, the UX people are performing inquiry and planning for sprint n + 2, while doing interaction design (and prototyping) for sprint n + 1, and evaluation of the interaction design for sprint n − 1.
Following the “lifecycle” of a single release, release n, we see that in sprint n − 1, the UX role designs for release n, to be implemented by the SE people in sprint n. UX evaluates release n in sprint n + 1. SE fixes it in sprint n + 2 and re-releases it at the end of that sprint.
Prototyping and UX evaluation
At the end of each sprint, UX people must be able to deliver their UX design to SE people for implementation in the next sprint. This means they must embody their design solution within some kind of prototype, usually a narrow vertical prototype encompassing multiple related user stories for just the feature (user story) they are considering. There will be time only for a low-fidelity prototype; these days wireframes are the de facto standard for prototypes in this kind of development environment.
Perhaps an even more agile form of low-fidelity prototype is a design scenario, maybe in the form of storyboards, which can be used as an early and simple vehicle to draw out feedback from the customer and users. Kane (2003, pp. 2, Figure 1) shows how a scenario can be seen as a mini-prototype, both narrow and shallow, at the intersection between a vertical and a horizontal prototype. A scenario can distill “the system to the minimal essential elements needed for useful feedback” (Nielsen, 1994 Nielsen, 1994a).
The traditional UX process, of course, calls for extensive UX evaluation of the prototype. However, there will almost never be time to evaluate the prototype in this same sprint, but you will be able to evaluate this UX design in the next sprint.
Prototype integration
UX is all about holistic designs, and you cannot ensure that your emerging design is on track to provide such a holistic user experience unless you have a representation of the overall design and not just little pieces. Therefore, after each new feature is manifest as a prototype (e.g., wireframe), it is integrated into the growing overall user interface prototype, covering all the user stories so far and the broader UX vision. The small feature prototype drives coding but the integrated prototype helps everyone with a coherent view of the overall emerging interaction design.
The value of early delivery
As Memmel, Gundelsweiler, and Reiterer (2007) say, you have the potential to deliver design visions to customers before you even have completed requirements analysis. In contrast, with the traditional rigorous UX process, this is an amazingly early deliverable and amazingly early involvement of the customer.
Feedback for the first feature can go far beyond just that one feature and its usage. This is the first opportunity for the team to get any real feedback. A lot of additional things will come out of that, not specific to that feature. For example, you will get feedback on how the process is working. You will get feedback on the overall style of your design. You will hear other questions and issues that customers are thinking about that you would not have access to until much later in the fully rigorous process. Your customers may even reprioritize the story cards based on this interaction. This early feedback fits well with the agile principle of abundant communication.
Exactly what is “delivery” in an agile environment?
A stated goal of agile SE methods is to release a product every few weeks. Why would anyone want to do that? Why would customers and users put up with it? Well, if you are talking only about functional software and not the user interface, customers will love it. They get to see very early manifestations of a working system, however severely the functionality may be limited. Also, agile SE developers can actually release their small iterations of functional code even to end users, as changes in the internal code are not visible to customers or users.
However, multiple releases of the user interface, each with a changing design, are not a good thing for users, who cannot be expected to track the continuous changes. They invest in learning a user interface; so a constant flow of even small changes, even if they are improvements, will not be acceptable.
This is always a risk with an agile approach, so it is up to the UX person to mitigate these transitions by making each release an addition to the capabilities but not completely new. Users should be able to do more, but not necessarily change how they do things that are already delivered.
Continuous delivery
Delivery to customers and users is continuous but in pieces. At the end of any given sprint, call it sprint n, the customer sees a UX prototype of the upcoming release and in the next sprint, sprint n + 1, they see the full functional implementation of that prototype. In sprint n + 2, they see UX evaluation findings for that same prototype and, in sprint n + 3, they see the final redesign. Each of these points in time is an opportunity for the customer to give feedback on the interaction design.
Planning across iterations
Figure 19-7 shows planning in a single box at the bottom, extending across all the sprint cycles. That is to convey the idea that planning does not occur in discrete little boxes over time at just the right spot in the flow. Planning is more of an “umbrella” activity, distributed over time and is cumulative in that the process builds up a “knowledge base” founded on agile contextual inquiry with users. The planning process does not start over for the planning of each cycle.
Instead the same knowledge base is consulted, updated, and massaged, working with the original SUFA results and anything added to supplement those results. Because an overview and conceptual design are evolving in the process, this kind of UX planning brings some top-down benefits to an otherwise exclusively bottom-up process.
Communication during synchronization
This kind of interwoven development process brings with it the risk of falling apart if anything goes wrong. This intensifies the need for constant communication so that everyone remains aware of what everyone else is doing, what progress is being made by others, and what problems are being encountered.
Agile processes can be more fragile than their heavyweight counterparts. Because each part depends on the others in a tightly orchestrated overall activity, if something goes wrong in one place, there is no time to react to surprises and the whole thing can collapse like a house of cards.
Including emotional impact
How can you take emotional impact into account within an agile approach? It is more difficult to think about emotional impact within an agile approach because you do not have good ways to connect to the overall user experience for the system. You will have limited time to create a conceptual design that fosters a strong positive emotional response. You will have to manage and do as much as you can by including emotional impact as part of the small upfront analysis, in design ideation, and in evaluation.
Style guides
Maintaining a style guide throughout the UX part of an agile development process is perhaps even more important than it is in the fully rigorous process (Constantine & Lockwood, 2003). An agile style guide with the minimal design templates, motifs for visual elements, and design “patterns” (e.g., a standard design for a dialogue box) supports reuse, saves the time of reinventing common design elements, and helps ensure design consistency of look and feel across features. Your style guide can also document “best practices” as you gain experience in this agile approach.
1 There are other “brands” of approaches to agile SE methods beyond XP, including Scrum (Rising & Janoff, 2000), but for convenience we focus on XP.