Agile Problems, UX Solutions, Part 1: The Big Picture and Prototyping

By Ritch Macefield

Published: November 12, 2012

“Intelligent UX strategies can solve certain problems that are characteristic of agile development, as well intrinsically benefit our UX design work.”

This is the first installment of a two-part article about how intelligent UX strategies can solve certain problems that are characteristic of agile development, as well intrinsically benefit our UX design work. My starting point: a few arguments that I made in a recent UXmatters article: “(Why) Is UXD the Blocker in Your Agile UCD Environment?

To summarize what I wrote in that article: For a variety of reasons, particularly the ever-increasing need for software development speed, agile development methods are gaining in popularity. In many ways, this is good for UX professionals because agile fits well with the philosophy of true user-centered design (UCD) and, therefore, potentially fits well with good UX design practice. For example, a great way to define the requirements for agile sprints is for the UX team to provide the development team with an initial, functional prototype for each sprint—a prototype that they’ve already subjected to stakeholder review and successful usability testing. This approach is best supported by a modern, fourth-generation prototyping tool such as Axure RP Pro, iRise, or Justinmind Prototyper.

We know that an approach that integrates UCD, user experience, and agile can work very well. However, this approach does not mitigate a fundamental problem with agile development methods.

An Agile Problem: Incoherent Design Solutions

“A consequence of decomposing development projects into sprints is that successful sprints do not necessarily mean that a software system hangs together in a coherent way. … The result is not necessarily success for the development project as a whole!”

In the above-mentioned article, I also explained that a key way in which agile approaches achieve their speed is by breaking down the development process into lots of short, sharp sprints of the same length—typically, just two to six weeks—that have clear goals—for instance, to get a search feature working. Success, in purely agile terms, means a team has met their goals for each sprint. However, a consequence of decomposing development projects into sprints is that successful sprints do not necessarily mean that a software system hangs together in a coherent way. So, even if every sprint is a success, the result is not necessarily success for the development project as a whole!

For example, I recently observed a large-scale software development project on which the UX team supplied the development team with a prototype as the input for each agile sprint, as I’ve just described. However, one of the sprints resulted in a primary navigation design that was incompatible with the design the development team had implemented in a previous sprint. The result: the UX and development teams had to rework the output from both sprints extensively—adding to the project backlog. Of course, this wasted a lot of time—a particularly egregious sin in an agile environment.

Subsequent analysis of this problem revealed the root cause: two different UX designers had led the prototyping work for the two sprints in question, and neither the scrums nor the regular UX team meetings had caught this design communication problem—despite both UX designers’ being reasonably experienced. This analysis also revealed that the system had a number of major inconsistencies in the way the user interface worked and, while these problems weren’t as serious as the primary navigation’s incompatibility problem, resolving these inconsistencies also involved a significant amount of additional rework.

Clearly, the potential for agile development to generate inconsistent or even incompatible sprint outcomes is something that is fundamental to agile methods rather than a problem that is particular to UX design. However, it is clear from this example that problems that originate during UX design can easily trigger such problems during agile development, resulting in the familiar sound of “Why is UXD the blocker in our agile UCD environment?” echoing around the project team!

A UX Solution: Conceptual Prototyping

“Produce a big-picture, or conceptual, prototype as your first major UX design artifact on a project.”

In the real world of large-scale software development, we can’t reasonably expect that the same UX designer will lead design for all sprints. Similarly, we can’t expect scrums and UX meetings to catch all problems with inconsistencies in designs—even though some of them might be substantial. However, intelligent UX strategies can address this problem.

My first suggestion is that you produce a big-picture, or conceptual, prototype as your first major UX design artifact on a project.

Conceptual Prototypes

Conceptual prototypes define a conceptual model of a software system from a user’s perspective….”

In a UX context, conceptual prototypes define a conceptual model of a software system from a user’s perspective, including things like the following:

  • the scope of the tasks that the system will perform—For example, for a document database, some of these tasks might be searching, browsing, setting up alerts, and managing favorites.
  • the macro, or high-level, information architecture—For example, how to classify and organize the key functions and documents.
  • a broad template design for key page types—For example, where the primary navigation goes and what the header and footer should contain.

Because of the holistic nature of conceptual prototypes, their use makes it more likely that you can start off a design in a way that promotes its overall coherency—so you can avoid, or at least significantly reduce, the types of inconsistencies and incompatibilities that I described earlier.

Conceptual prototypes are wide rather than deep—that is, they cover all of the key aspects of a software system and avoid getting bogged down in details….

Conceptual prototypes are wide rather than deep—that is, they cover all of the key aspects of a software system and avoid getting bogged down in details such as error handling or the aesthetics of visual design. Often, UX professionals see width and depth as antagonistic factors in prototyping, because we must sometimes achieve one at the expense of the other—in terms of the time we can devote to either. However, high width–low depth prototypes can provide an ideal balance. Their low depth means you can iterate these prototypes relatively quickly, while their high width makes sure you keep your focus on the big picture. Conceptual prototypes help you to identify and make key design decisions at an early stage.

Note—Conceptual prototypes are often a factor within the realm of lean UX—another contemporary initiative that aims to improve software development speed. The only difference is that, in a lean UX context, you might produce conceptual prototypes for the purpose of rather than as a result of initial research and ideation.

Of course, UX professionals recognize and have widely discussed and evaluated the benefits of working with conceptual prototypes—their use is common practice. However, I want to suggest two relatively novel extensions to their use—within the context of an agile development environment:

  1. Interactive conceptual prototypes
  2. Persistent, holistic prototypes

Interactive Conceptual Prototypes

“APAD tools have only a limited ability to represent a software system’s conceptual model because the key interactions that a system supports constitute a fundamental part of its conceptual design.”

Many UX professionals associate conceptual prototyping with grayscale wireframes, which they produce with what I called Adapted Presentation and Diagramming (APAD) tools in my recent UXmatters article, “Are You Still Using Earlier-Generation Prototyping Tools?” Common examples of such tools include Visio, OmniGraffle Pro, and PowerPoint. Among the many limitations of APAD tools in addressing modern prototyping needs—which I explained fully in that article—is their extremely limited ability to model interactivity. As a result, APAD tools have only a limited ability to represent a software system’s conceptual model because the key interactions that a system supports constitute a fundamental part of its conceptual design.

This is one reason that I believe in modeling at least some key parts of a system’s interactivity in a conceptual prototype. Another is that it usually enables a UX team to help validate a conceptual design by conducting various forms of usability testing with interactive prototypes. This can be particularly valuable when a team is considering the use of novel interaction models or mechanisms. Due to their very nature, most such models and mechanisms ultimately prove unusable, so it is important to identify these as early as possible during a project.

There are only two significant issues you must consider when using conceptual prototypes for usability testing:

  1. You should develop the prototype and usability test plan together to ensure that the prototype is sufficiently detailed and robust to support the desired test tasks, while at the same time avoiding your wasting time prototyping unnecessary functionality.
  2. The test facilitator should both have an intimate knowledge of the prototype and be highly experienced, so she can elegantly manage the common situation in which a prototype breaks—perhaps because a test participant has done something unanticipated or gone off task.
“Within an agile context, it is typically possible to create a sufficiently robust interactive prototype quickly enough only by using a fourth-generation prototyping tool….”

This means you cannot just hand off your conceptual prototypes to an external agency for usability testing by a newbie facilitator as though it were working software—which unfortunately is common practice.

Again, relating this to lean UX, it is easy to understand that conceptual prototypes are a quick way of gaining a tangible and powerful means of doing user research.

I’ve argued for including interactivity in conceptual prototypes, but it is important to note that, within an agile context, it is typically possible to create a sufficiently robust interactive prototype quickly enough only by using a fourth-generation prototyping tool—and only if your organization possesses the skills necessary to use these powerful tools to their full potential!

Persistent, Holistic Prototypes

“I advocate for the creation of persistent, holistic prototypes, which begin as a conceptual prototype, then evolve incrementally into an increasingly more comprehensive prototype of a whole system….”

Many UX professionals consider their conceptual prototypes to be highly ephemeral—becoming redundant as soon as a team has agreed on a design concept. In agile environments, once the sprints start, a team often rejects the idea of retaining some sort of big-picture prototype, and their focus instead moves to producing prototypes for each sprint—what I refer to as sprint-specific prototypes.

In contrast, I advocate for the creation of persistent, holistic prototypes, which begin as a conceptual prototype, then evolve incrementally into an increasingly more comprehensive prototype of a whole system before the agile sprints begin. To help you understand this idea better, Figure 1 shows a model for integrating prototyping with agile development, and I’ve also provided an example.

Figure 1—A model for integrating prototyping with agile development

A model for integrating prototyping with agile development

Suppose you were designing a new document database system. You’d start off by creating a conceptual prototype, then iterate it throughout review and test cycles until you decided to go with a design concept. Suppose you were then to arbitrarily decide that the first sprint would enable users to describe, list, and paginate documents. You would prototype this functionality by adding it to your conceptual prototype. Early feature ideas might well prove to be ephemeral and lacking in depth, because your goal is to generate and explore various types of design solutions—and perhaps subject them to focus group or stakeholder reviews. Features that you add later on may well have more depth and might be useful for usability testing. You might even produce different, even competitive, versions of a design for comparative analysis.

“This prototyping process should typically begin at least three sprint cycles ahead of the first development sprint. The result: the first version of a persistent, holistic prototype, from which you could then abstract only the parts of the prototype that were relevant to the first sprint.”

In keeping with the ideas Desiree Sy set out in her article, “Adapting Usability Investigations for Agile User-Centered Design,” this prototyping process should typically begin at least three sprint cycles ahead of the first development sprint. The result: the first version of a persistent, holistic prototype, from which you could then abstract only the parts of the prototype that were relevant to the first sprint. You wouldn’t want to burden and potentially confuse the development team by including aspects of a software system that are outside the scope of a sprint. You should also specify the functionality to be developed during the first sprint, producing complete requirements documentation for that sprint and thus delivering your first sprint-specific prototype.

Prior to each sprint, repeat this process of designing by elaborating on your persistent, holistic prototype; conducting usability testing using the prototype; then abstracting specifications for your sprint-specific prototypes. Often, your work on your persistent, holistic prototype may be for overlapping sprint cycles.

The final feature of this approach to prototyping is incorporating feedback at the end of each sprint. In keeping with core agile principles, it is common for user interface designs to evolve, even mutate, during a sprint. Further, such alterations might well occur directly in the implementation of working code rather than your going through any form of UX prototyping process first. This has two consequences:

  1. Unlike the persistence of the holistic prototype, the lifespan of each sprint-specific prototype should end with the sprint it serves.
  2. The working software may well get out of sync with your persistent, holistic prototype.

Some inconsistencies between the working software and your persistent, holistic prototype might be unimportant, so you could safely ignore them. Indeed, you should keep in mind that the purpose of a persistent, holistic prototype is never to fully model a working software system. Attempting such a detailed synchronization would be a waste of time—if it were even possible at all. However, at the end of each sprint, you may want to update your holistic prototype, making any significant changes that you think might impact your UX design work for future sprints—for example, changes to the design of the primary navigation.

Creating and maintaining a persistent, holistic prototype is unlikely to be a viable approach without the skilled use of a fourth-generation prototyping tool….”

Again, in my opinion, creating and maintaining a persistent, holistic prototype is unlikely to be a viable approach without the skilled use of a fourth-generation prototyping tool—not least because it may require overlapping, multiuser prototyping activities; and because it cries out for revision control and locking down versions of prototypes for coding.

Clearly, there is significant cost in maintaining persistent, holistic prototypes—even using fourth-generation prototyping tools and assuming skilled prototypers are available. So, this begs the question: is creating them of sufficient benefit?

Persistent, holistic prototypes extend the benefits that initial, interactive conceptual prototypes provide over an entire project lifecycle. They act as a beacon, helping you to drive and maintain a coherent design. In more tangible terms, they enable usability testing at the prototyping stage, using more realistic scenarios, in which tasks involve functionality that a development team implements across multiple sprints. In other words, using persistent, holistic prototypes makes it more likely that you can ultimately achieve the “good conceptual model” that Don Norman’s legendary “Design Guidelines for Interfaces” [1] demand. Your team may well realize benefits that more than offset the cost of creating these prototypes—particularly by reducing rework and the opportunity costs that would otherwise accrue as a result of increased time to market.

In Part 2 of this series, I’ll discuss extending the uses of persistent, holistic prototypes through the rigorous use of interaction design patterns and pattern languages.

Reference

[1] Norman, Donald A. The Psychology of Everyday Things. New York: Basic Books, 1988

2 Comments

When we do this, it works well. The challenge for us is getting the product owners to involve User Experience early enough in the process.

Same old challenge then, Sean :-)!

Join the Discussion

Asterisks (*) indicate required information.