Agile Problems, UX solutions, Part 2: Thoughts on Patterns and Prototyping

By Ritch Macefield

Published: December 17, 2012

“Intelligent UX strategies can solve certain problems with agile development—in addition to intrinsically benefiting our UX design work.”

This is the second in my series of two articles about how intelligent UX strategies can solve certain problems with agile development—in addition to intrinsically benefiting our UX design work. Please read Part 1 of this series, “Agile Problems, UX solutions: The Big Picture and Prototyping,” to completely familiarize yourself with the key concepts and terminology that I’ve explained there, which underpin the discussions in this article.

In summary, Part 1 explained that common and quite reasonable UX practices can trigger fundamental problems with agile software development methods that can ultimately lead to the implementation of inconsistent or even incompatible user interface design solutions for similar interactions in different parts of a software system. Because agile realizes these inconsistencies in working code, either or both of the following consequences can occur as a result:

  • Addressing such inconsistencies can require a significant amount of time for rework—a particularly bad sin in agile development.
  • Some of these inconsistencies may remain in the production software. As a consequence, its usability may be significantly reduced. Consistency is an inherent factor of usability, as enshrined in Don Norman’s “Design Guidelines for Interfaces.” [1]

In Part 1 of this series, I proposed maintaining a persistent, holistic prototype throughout the entire life of a software development project to help mitigate such problems. Now, to further mitigate these problems, I propose extending the uses of such prototypes through the rigorous use of interaction design patterns and pattern languages.

To understand this proposal, readers should have a clear understanding of the differences between interaction design, information architecture (IA), visual design, and usability engineering, which in combination form the wider discipline of UX design. For a solid grounding in these different aspects of UX design, I suggest you read my UXmatters article “UX Design Defined.” It is also necessary to understand the basics of interaction design patterns and pattern languages.

What Are Design Patterns and Pattern Languages?

“Interaction design patterns are repeated collections of interface objects … that work together to solve common interaction design problems.”

UX professionals sometimes misuse the terms pattern and pattern language—using them in an interchangeable manner. Indeed, even Web sites specializing in patterns and pattern languages sometimes confuse these terms!

Within a software system, interaction design patterns are repeated collections of interface objects—for example, links, buttons, and text boxes—that work together to solve common interaction design problems. For example, Figure 1 illustrates a common progressive navigation pattern that solves the problem of how users can traverse the steps in linear tasks.

Figure 1—Progressive navigation pattern

Progressive navigation pattern

Pattern languages work at a higher, or meta, level to describe collections, or libraries, of patterns. Various taxonomies exist to define a pattern language. Most of these overlap considerably. The following taxonomy is representative:

  • NameHow is each pattern uniquely identified within the library? This depends on naming conventions and other formalized notations that the pattern language uses. The identity of a pattern can also include an associated image, or icon.
  • Description—Of what does the pattern consist, and how does the pattern work from an interaction perspective?
  • ProblemsWhat interaction problems does the pattern solve?
  • SolutionsHow does the pattern solve these problems?
  • When—In what context of use does the pattern apply? Examples might be when a user is signed in or after a user has made an error.
  • Examples—What are some examples of the pattern’s use? Ideally, the examples would be working software or a functional prototype.
  • Related patterns—How do these patterns relate to each other? Not all taxonomies for pattern languages include this item. In my opinion, this is unfortunate because this information is particularly interesting and important for two reasons: First, this part of the taxonomy addresses the classification of patterns—for example, you may want to classify patterns relating to navigation, form input, or advertising. In other words, this defines a kind of information architecture for a pattern library. Second, and perhaps more important, it defines the reuse of patterns within the library.
“The classification of patterns … defines a kind of information architecture for a pattern library.”

To explore pattern reuse further, let’s consider the progressive navigation pattern illustrated in Figure 1. That pattern consists of two button elements. An important thing to note is my use of the term element. I’ve used it quite deliberately because, although these elements would certainly be part of any pattern library, elements are not patterns. Unlike the patterns they constitute, elements cannot be decomposed. This why experts in pattern languages sometimes refer to them as atomic elements—forming an analogy with the periodic table of elements from which physical compounds are formed.

Now, let’s consider the lightbox pattern illustrated in Figure 2. This pattern comprises four elements: two types of background, a title, and a close box. Next, Figure 3 shows the integration of the progressive navigation pattern shown in Figure 1, the lightbox pattern shown in Figure 2, and a progress indicator pattern—within a more complex wizard pattern. This demonstrates the reuse of patterns within wider hierarchies, or networks, of patterns.

Figure 2—Lightbox pattern

Lightbox pattern

Figure 3—Wizard pattern

Wizard pattern

It is worth noting at this point that—as many UX design managers have found to their surprise and sometimes cost—fully and accurately defining a pattern language for a pattern library is a non-trivial exercise! This is true both in purely intellectual terms and in regard to the practicality of constructing a library using some kind of software tool that is available to a UX design team. Defining how patterns relate to each other is particularly challenging. Indeed, there are parallels here with the notoriously difficult task that software architects face when defining class hierarchies in object-oriented software.

Are Patterns and Pattern Languages Useful?

“Pattern languages can be an excellent communication device, helping everyone involved with a software development project to understand an interface design.”

The relative lack of research in the area of patterns and pattern languages makes it difficult to answer the question of the usefulness of patterns and pattern languages definitively. However, Wania and Atwood provide some useful insights. [2] Their paper, in addition to being relatively up to date, provides a good summary of the key research in this area, along with an interesting discussion of their own primary research. From this paper, we can draw a number of conclusions that have relevance here:

  • All modern software systems make extensive use of interaction design patterns.
  • All UX designers use patterns in their work—although this might often be an unconscious process.
  • Different UX designers use patterns to different degrees and prefer different patterns to solve the same interaction design problems.
  • When UX designers working on a design project are asked to use a pattern library that is based on a robust pattern language, this is likely to increase the consistency of their use of patterns in a user interface design. This, in turn, increases the usability of the user interface.
  • Pattern languages can be an excellent communication device, helping everyone involved with a software development project to understand an interface design.
  • The use of a pattern library does not increase interface design speed.

Now, that I’ve laid this groundwork, let’s examine how you can use patterns within the context of an agile development environment and combine patterns to form persistent, holistic prototypes.

How Are Patterns Useful in Creating Persistent, Holistic Prototypes?

“Once you’ve created and, ideally, tested the first version of a persistent, holistic prototype, you can extract the patterns that it contains into a pattern library.”

Once you’ve created and, ideally, tested the first version of a persistent, holistic prototype, you can extract the patterns that it contains into a pattern library. Document the patterns using a robust pattern language, including their atomic elements—for example, links, text, buttons, and panels. Pay particular attention to elements at this point, because they form the fundamental building blocks of all patterns.

In producing all subsequent versions of the prototype, adopt the policy of using only elements and patterns that are part of the pattern library in the design. Of course, as you progress, it will often be necessary to add new patterns and elements to the library. When adding patterns and elements, follow this process:

  1. Carefully consider whether you really do need any new patterns or elements.
  2. If you do, try to generalize existing patterns and elements because, although this may necessitate some reworking of the code, this is better than designing completely new patterns and elements.
  3. If you do need to produce a completely new pattern, build it, as far as possible, using patterns and elements that already exist in the library.
  4. When creating a new pattern, pay careful attention to
    1. ensuring that the pattern is as close as possible to an optimal solution for the problems it addresses. If possible, validate this through usability testing in a realistic context.
    2. ensuring that the development team can build the pattern efficiently within their working code
    3. maximizing the anticipated contexts of use for the pattern and any new elements they employ
“The pattern library rather than the prototype itself will contain much of the information about how the development team should implement the user interface design in working code.”

This way of working has some significant consequences, as follows:

  • The pattern library rather than the prototype itself will contain much of the information about how the development team should implement the user interface design in working code. Indeed, I have worked on pattern libraries whose patterns were pixel perfect and contained virtually all of the information that developers required for implementation. For example, include hex values for colors, dimensions, the names of any image assets and references to where they reside, and even the code objects and libraries that are necessary for the implementation. In turn, much of the work of defining elements and patterns in a pattern library is offset by a significant reduction in the amount of specification work that is necessary during sprints for specific prototypes.
  • Much of the value that UX designers add to a project is in the pattern library rather than the prototype.
  • The process of designing with a pattern library both introduces some additional overhead and requires a degree of rigor that is not present in many UX design contexts.
  • Ideally, both developers and usability engineers should be fundamentally involved in defining the patterns—probably at an earlier stage in the overall development process than would otherwise be the case.
  • In comparison to the development model that I presented in Part 1 of this series, sprints start one cycle later. Before the development team begins to develop working code for patterns, you may need to run a pilot test to determine whether the pattern language meets their needs—particularly if the pattern language includes a lot of information that is relevant to the implementation, as I described earlier.

Figure 4 illustrates how to adapt the development model that I presented in Part 1 for use with a pattern library.

Figure 4—Extended development model

Extended development model

Is Integrating Pattern Libraries into Persistent, Holistic Prototypes Beneficial?

“The initiation and maintenance of a pattern library adds considerable overhead to the interaction design process.”

To assess the benefits of integrating pattern libraries into persistent, holistic prototypes, we can begin by revisiting Wania and Atwood’s conclusion that pattern library usage does not increase user interface design speed. [2] Thus, it is not possible to justify the approach I’m describing here purely in terms of increased prototyping speed. To answer this question, let’s conduct a qualitative cost-benefit analysis.

What Are the Costs?

This whole approach to integrating pattern libraries into persistent, holistic prototypes is quite novel, so inevitably constitutes a business risk. More specifically:

  • The initiation and maintenance of a pattern library adds considerable overhead to the interaction design process.
  • This approach is very likely to delay the beginning of the first sprint.

Plus, the overhead and rigor of designing user interfaces exclusively using a pattern library will be new to many UX designers. In my experience, some UX designers may perceive—wrongly in my opinion—that using patterns stifles creativity. This constitutes a further risk that UX management might need to address.

What Are the Potential Benefits?

“The rigorous use of a good pattern library is likely to increase both the amount and the consistency of pattern use….”

There are potentially three key benefits in adopting such an approach:

  1. According to the conclusions of Wania and Atwood, [2] it is easy to infer that, in an agile environment, different UX designers, leading different sprints, would be likely to use different patterns to solve similar interaction design problems. It is easy to imagine that a single UX designer might even use patterns in an inconsistent manner. Indeed, I have seen instances of this myself. Such inconsistencies can result in significant time and expense for rework or reduced usability in the final software product—in other words, a lower-quality product. However, it is easy to argue that the rigorous use of a good pattern library is likely to increase both the amount and the consistency of pattern use and, therefore, to help mitigate these problems.
  2. Again, from the conclusions of Wania and Atwood, [2] it is easy to argue that the use of a pattern library is likely improve communication between the UX team and the development team. This is particularly true during the early stages of a sprint, when developers are trying to understand the sprint requirements. Further benefits of this nature are possible if the development team is involved in defining the pattern language and the pattern language includes notations that assist in the implementation of elements and patterns. For example, for Web-based systems, I often use CSS classes to help describe user interface elements, which the development team can simply copy and paste into the working code.
  3. The collaboration inherent in this approach—both within a UX team and across product teams—may result in patterns that provide more optimal interaction design solutions than would otherwise be the case.

Summary of This Cost-Benefit Analysis

At this point in time, there seem to be too few organizations adopting this approach to draw any conclusions regarding whether its benefits outweigh its costs or how costs and benefits may differ across different types of agile software development projects. However, I have worked with a few organizations that are moving toward such an approach and are already recognizing benefits. We can also draw some parallels with the software engineering discipline, which has long made extensive use of patterns in class libraries. It seems clear to me that our UX discipline will ultimately move in that direction, too.

Fourth-Generation Prototyping Tools

“You can use a fourth-generation prototyping tool to implement a pattern language and, therefore, a robust pattern library.”

This article would not be complete without addressing the critical relevance of fourth-generation prototyping tools to prototyping with patterns. Earlier, I described some of the challenges of constructing and maintaining a good pattern library. Fully utilizing a fourth-generation prototyping tool facilitates your meeting these challenges.

I always smile when UX designers confuse the simple stencils that are available in tools like OmniGraffle and Visio with the sophisticated library facilities that are available in tools like Axure and iRise. These facilities let you

  • model the interactivity in patterns
  • model the states of elements in patterns
  • fully specify elements and patterns
  • classify elements and patterns
  • reuse elements and patterns
  • publish descriptions of the patterns in a library on the Web

You can use a fourth-generation prototyping tool to implement a pattern language and, therefore, a robust pattern library. Having said that, my experience is that even these tools are not yet ideal for this task. Therefore, making this work in practice requires considerable thought and expertise in using the features of these tools.

For some organizations who want to adopt a software development approach similar to that which I’ve outlined in this two-part series of articles, implementing and gaining expertise with a fourth-generation prototyping tool will be essential. You may view this as another cost and risk in addition to those that I described earlier. However, you should not view implementing a pattern library using such a tool in this way because their use is easy to justify in many other ways, as I’ve explained in my UXmatters article “Are You Still Using Earlier-Generation Prototyping Tools?

References

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

[2] Wania, Christine E., and Michael E. Atwood. Pattern Languages in the Wild: Exploring Pattern Languages in the Laboratory and in the Real World. Proceedings of the 4th International Conference on Design Science Research in Information Systems and Technology, May 7–8, 2009.

Join the Discussion

Asterisks (*) indicate required information.