Agile User Interface Development

Two important disciplines in the area of software development have emerged over the last decade - Agile software development and user-centered design (UCD, also referred to as interaction design). These approaches are lauded by supporters as critical to end user and customer satisfaction with software but are seemingly at odds on some key points.

Agile software development processes have many variants, but the common themes include close communication with customer, rapid iterations, and a focus on delivering value as quickly as possible. Agile processes frown on long up-front design and analysis phases, preferring instead to mix analysis, design, development, and even delivery throughout the project.

Interaction design/UCD are a set of practices that are designed to uncover user goals in detail in order to create experiences that efficiently, effectively, and enjoyably guide the user through software to meet these goals. UCD practitioners spend as much time as is needed up front researching user behavior and goals, and developing interaction designs to support them.

This article will explore how these disciplines can peacefully co-exist. By considering ways to integrate UCD techniques into an Agile project lifecycle, development teams can get the benefits of both approaches. Understanding how best to satisfy user goals while simultaneously focusing on delivering frequent and continuous business value is a combination worth trying.

Background

Complex user interface development (referred to as UI development in this article) presents some unique challenges for an Agile development effort. Unlike projects where most of the functionality is behind the scenes in the form of automated business rules or payroll calculations, UI development projects often cannot afford to make drastic changes due to issues with user training and productivity loss, especially for applications that are used constantly (such as a call center application, email reader, or data entry system).

Many Agile projects rely on the ability to "just fix it in the next iteration" as a hedge against making the wrong decision. The idea is to fail quickly while it is still relatively inexpensive. But end users of UI development projects often need substantial training to use the systems, and are thus much less tolerant of dramatic changes in the user experience.

User experience disciplines such as interaction design promote a more up-front design process that researches and captures user goals to attempt to optimize software workflow before development begins. This is somewhat in conflict with the Agile approach - this upfront analysis and design can often take several months for a non-trivial project, and user goals may shift as the project unfolds.

But with restrictions on the degree of UI changes, and the high risk of delivering an inappropriate user interface in an early iteration, what's an Agile developer to do?

An Agile Approach to UI Design

An approach to this problem requires a quick check of Agile foundations. Many of the practices of Agile development are geared towards reducing risk and lowering the cost of change. In the case of UI development, the cost of incremental change and deployment is higher than we'd like because of concerns about end-user retraining and loss of productivity. We also run the risk of delivering the wrong user interface initially, but being limited in how much we can change it.

With this in mind, an approach that lowers the initial risk of delivering a UI that is "way off" will give us a good start in the right direction. If we get the UI right initially, then the types of changes we make in subsequent iterations won't be nearly as traumatic for our users, and will have lower deployment and training costs. By understanding the most important and common user goals and making the initial interface support these goals effectively in terms of efficient navigation, appropriate feedback, and a minimum of distraction, we stand the best chance of getting the design right. User goals tend to be more stable over the life of a project, unlike more detailed requirements.

To stay within the spirit of Agile, though, we ideally need this approach to allow us to get rapid feedback from our customers, and to quickly iterate our user interface to a point where we have confidence that our initial development effort will deliver what our customers need.

Agile Interaction Design

Interaction design is a discipline that looks to create optimal user experiences by studying the domain and environment of the target users of the software. Traditionally, this is done with an up-front research and analysis of user roles and goals, with an eye towards identifying the primary users of the system, what they need to do, and what secondary factors come into play (such as repetitive use, sensitivity to errors, etc.)

A more agile spin of interaction design would be to do "just enough" study of user goals to make a good first guess at what might work, then test it with real users. While not as thorough, this would allow quick turnaround and validation early in the process, instead of a longer up-front analysis.

In short, there is significant value in doing at least some up front work in order to get a better understanding of user goals, as long as it doesn't prevent development from starting as soon as possible. Depending on the makeup and philosophy of the team, this may take one of the following forms:

UCD work is performed an iteration ahead of development work. Designers work closely with users and developers to do "just enough" analysis to provide solid guidance. Feedback from end users and customers will play an even more critical role than in projects where most UCD work is done up front.

UCD work is performed in conjunction with development. Similar to above, but designers work in parallel with developers, perhaps starting with an initial user research effort at the beginning of the project. Designers constantly inform the team of customer feedback and changes to the design. This actually happens frequently on teams with no formal UCD staff. A potential tradeoff is that new discoveries of ways to streamline software workflow are likely to be found in mid-iteration, and may require rework of major elements of the system, slowing down overall team velocity.

Personas and Goals

A quick technique for discovering user goals is to use "personas" - specific user profiles of real people who might need to use the system, what their tasks are, and even their emotional outlook. For example, for an email system, we might have a persona that looks like this:

John is a busy executive at a Fortune 500 company. He is not very comfortable with computers, but uses email as his primary application. John gets about 100 emails a day, and usually sends less than 10. He does not enjoy using software, and prefers to call his associates in person.

A full persona description might go into even more detail, but the idea is to use not a "stereotype" of a user, but a specific instance of a user with certain goals and traits that is representative of your expected end user. Depending on the type of system, you might need several personas to represent the different kinds of users.

Once you've defined personas, you can start to analyze the kinds of goals that they have. A goal is really more about outcomes that they want to occur, not tasks that they perform. An example of goals versus tasks:

Goal: I want to stay up to date with my colleagues and keep track of past conversationsTask: I need to check my Email Inbox and view past conversations by Contact.

Eventually you'll need to come up with specific tasks that help your user reach her goals based on her preferences and needs. By starting with goals, though, you can refer to them as you consider different technical possibilities for achieving them. Just because a user performs certain tasks today doesn't mean that those are the easiest or most effective way of meeting their goals.

Paper Prototyping

One of the tools we can use for quick exploration of interface ideas is the use of paper prototyping. This is a technique of creating drawn or printed mockups of a user interface and testing them with users. The testing is done by having a facilitator act as the "computer", and having her add other pieces of paper demonstrating the functionality in response to a user "clicking" on different areas of the paper.

An entire book has been devoted to this subject - Paper Prototyping by Carol Snyder, and is an excellent reference for the techniques and tradeoffs of this approach.

The primary advantages of paper prototypes are that:

They are easy to create - anyone with paper and pencil can do it

They often uncover interaction issues that more formal prototypes do not, since users are less distracted by look and feel issues

They are clearly throw-away: you can't put a piece of paper "into production", regardless of how much pressure is applied.

Figure 1 - Drawing for use as a paper prototype

Other Prototyping Techniques

As beneficial as paper prototyping can be for quick feedback, sometimes it isn't practical. For example, if you have remote customers, facilitating a paper prototyping session can be difficult if not impossible.

One alternative technique is to take digital photos or scans of paper or whiteboard drawings, and to link these into interactive mockups using an HTML editor, presentation software, or specialized tools. This approach has the advantage of still using paper to model concepts, but allows remote customers to be sent copies, or review them interactively online with a conference call or webinar.

Figure 2 - A simple HTML prototype

Another option is to create a bare-bones HTML page for each screen of your prototype that just has text descriptions of the purpose of the screen, with links for each action needed on that screen. Web designers call this process wireframing.

As a last resort, you could create a prototype in a tool like Visual Basic or your favorite development language IDE. Many of these products have rapid prototyping features for creating dialogs and screens without programming. The main drawback, of course, is that these prototypes can look "finished" or very close to the target application technology. Because of the realistic look, end users may tend to focus on the details of the implementation instead of the workflow ("Shouldn't that button be left-aligned? It looks pretty ugly").

"Spike" Implementations

For certain projects, you may not be able to communicate a sophisticated interface technique or widget by simply drawing it. In these cases, it can be beneficial to create a "spike" implementation. A "spike" is a narrow slice of functionality that goes end to end, like driving a spike into the ground.

For example, if you're building a new kind of calendar widget or fancy animated toolbar, it might be necessary to spend a few days creating something close to the real thing so that you can demonstrate the subtle behavior to get feedback.

Summary

In general, Agile techniques work well for both back-end systems and non-trivial user interfaces. However, there are many useful techniques from other disciplines that can add significant value. Specifically, techniques from interaction design can help with designing and testing user interface ideas before investing time in coding, and certainly before those systems are put into production, where interface changes may be constrained by training and productivity concerns:

By using personas and goals, developers can get an early feel for what kinds of tradeoffs might be necessary when designing the software.

Prototyping techniques ranging from paper prototyping to interactive electronic prototypes can provide a means of rapidly iterating and testing user interfaces at a low cost.

Finally, spike solutions can be helpful when the user interface needs of a project are more subtle or complex than simple prototypes can communicate. By implementing a small slice of functionality that demonstrates a key user interface concept, a spike can ensure clear communication with customers.

Combining user experience design techniques with an Agile development process can create a powerful synergy that results in better software that end users love, while still delivering the consistent business value for which Agile is known.

About the Author

Dave Churchville has over 15 years of experience in software development and management ranging from Fortune 500 companies to tiny startups. He has worked with agile methods since 2000, and is the founder of ExtremePlanner Software which develops tools that help distributed Agile software teams communicate and collaborate more effectively.

I have often treated UEX like Architecture. It benefits from having a single clear vision and somebody to ensure that vision is adhered to throughout. It is best to get it right up front because of the cost of change if we don't get it right up front. People keep looking at it as an example of why we need to do some up-front work.

Yet like architecture, most of these impediments can be removed and the rest can probably be worked round. Is there any reason why we could not rank requirements by UEX risk much as we do by Architectural risk (or for some teams, much as we did before we were confident we could change as we go)? Is there any reason to believe that UEX will never become as easy to change on the fly as architecture is now (for some teams; apologies to those who haven't got there yet)?

I agree somewhat with the similarity of Architecture and UX, but I see them as different animals in some important ways.

While architecture can be "changed on the fly" in a well-kept codebase, user experience isn't as amenable, in my experience.

Architecture tends to be invisible, and other than performance or scalability issues, does not impact end users.

Conversely, UX is something that can have a dramatic impact on users, both initially, and whenever it's changed. The cost of change here isn't measured only in developer hours, it's measured in user retraining, impact to productivity, and even in user happiness (more fuzzy).

So unless you can remove the end-users, I'm still not convinced that UX is something that's a good idea to change on the fly (at least in signficant ways).

There is an interesting resource on the same topic: "Agile, Multidisciplinary Teamwork" by Gautam Gosh. It presents techniques and tools used to create requirements with a team composed of the different participants of agile projects.

First, this was an excellent article, Dave. And much needed. Many of us are struggling with trying to find the sweet spot of agile vs. deep analysis. When is our understanding of the problem "good enough"? When do the rewards of moving quickly outweigh the risks of making the wrong design decision?

Now, on to the cautions...

Persona creation is not "a quick technique for discovering user goals". User research is the only way to discover user goals. Personas are the end product of user research. Since personas are used to justify design decisions, if they are simply the quick result of a designer/developer's beliefs and assumptions, they will be wrong and we will build the wrong product.

Is there merit to agile persona creation? Can a persona be iteratively refined? If so, would it be cost-effective considering the ripple-effect (or potential tsunami-effect)? I feel another article coming on...

And a caution regarding "remote" usability testing with HTML prototypes: This techniques relies on the testers to be able to report, after the fact, on their "impression" of the product's usability. People are invariably horrible at doing that. They misremember, they forget observations, and they are prone to tell you what they think you want to hear. There is no substitute for conducting usability studies in person where the testers' actions and facial expressions tell most if not all of the story.

I hope you don't mind; I'm using this article as a link from my [email] signature job title (Sr UI Developer). This is a great article describing what my position (and many others like it) entail and mean to us.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.