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

Interactive Conceptual Prototypes

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.

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

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.

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.

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.

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