Integrating Prototyping Into Your Design Process

Written by: Fred Beecher
Just like with any other UX research or design tool, context plays a critical role in determining how effective prototyping will be for you.

Prototyping is a big deal right now. We get wrapped up in mailing list threads, new tools are released at an astonishing pace, books are being published, and articles show up on Boxes & Arrows. Clients are even asking for prototypes. But here’s the thing… prototyping is not a silver bullet.

There is no one right way to do it.

However, prototyping is a high silver content bullet. When aimed well, a prototype can answer design questions and communicate design ideas. In this article, I talk about the dimensions of prototype fidelity and how you can use them to choose the most effective prototyping method for the questions you need answered.

The dimensions of fidelity

A prototype’s fidelity has the most influence over its effectiveness. Fidelity simply refers to how realistic the prototype is. Most of the time when we talk about a “high-fidelity” prototype we are referring to a prototype that has some visual or industrial design applied to it. But that leaves out what’s most important to UX designers, what it’s like to actually work with the prototype!

Fidelity is multidimensional.

Not only can you have a prototype that looks like a realistic product, but you can also have a prototype that works like a realistic product. I call these dimensions of fidelity “visual fidelity” and “functional fidelity.” By varying your prototyping methodology along these two dimensions you can ensure that your prototyping effort is successful given your particular context. Let’s take a look at some examples.

version w/ arrows

A prototype can be as simple as a series of hand-sketched wireframes that flow together. This is a good example of a low visual fidelity prototype. These wireframes show layout and functionality but have no visual design. Take the same wireframes, integrate a visual design, and your prototype has a high visual fidelity. While you might think of them as being similar, these two prototypes are most effective in two different situations.

That same series of sketches is also a low functional fidelity prototype. Moving through screens drawn on paper is much different than working with the developed system. But if you render those sketches in HTML, JavaScript, & CSS, they have a high functional fidelity. Working with an interactive prototype is very similar to working with the developed system. Again, high- and low-fidelity prototypes are most effective in two completely different situations.

After spending all this time talking about fidelity, I want to share one of my favorite quotes on prototyping. Bill Buxton said this in his Interaction08 keynote:

There is no such thing as high or low fidelity, only appropriate fidelity.

Appropriate Fidelity

“Appropriate fidelity” refers to a level of prototype fidelity that allows you to achieve the goals you’ve set for doing a prototype in the first place. By varying the fidelity of your prototype along the dimensions of visual design and functionality, you make your prototype more effective at achieving some goals and less effective for others.

bottom left Low Visual and Low Functional Fidelity

Very low fidelity prototypes are extremely useful to UX designers. Why? They can be made swiftly, changed without repercussion, and still help visualize a concept. Low visual & functional fidelity prototypes are helpful at answering large structural questions. Here are some examples:

  • Does the system have all the features required to support the user’s goals?
  • Does the workflow make sense at a high level?
  • Which UX concept works best?
  • Coming to consensus on a UX concept with stakeholders, e.g.“Is this what you meant?”

bottom right Low Visual and High Functional Fidelity

In my own practice, this is the type of prototyping I do most often. What I make are interactive, HTML interactive wireframes. Everything is black, white, and gray, but the interactions are extremely close to what they’d be in the developed system. These types of prototypes are effective in many situations:

  • Evaluating the usability of proposed designs for new systems
  • Exploring isolated interactions as a proof-of-concept
  • Validating UX design direction with stakeholders
  • Validating the implementation of requirements with stakeholders
  • Supplementing printed documentation for development teams
  • Performing remote testing

Remote testing has become more and more important over the last several years. At Evantage, we do approximately 75% of our user testing remotely. It would be difficult for us to get good data about our designs for modern, highly interactive sites if we were limited to representing those designs using low-to-medium functional fidelity prototyping techniques such as clickable PDFs or interactive PowerPoint presentations.

By prototyping isolated interactions at a high functional fidelity and testing them with users, I can get really good data about whether that interaction works before I base an application around it…. If those ideas are actually pretty slick, I can release the design with confidence instead of with gritted teeth.

I also want to expand on proof-of-concept testing. This technique supports creativity and innovation. By prototyping isolated interactions at a high functional fidelity and testing them with users, I can get really good data about whether that interaction works before I base an entire application around it. This allows me to explore my crazy ideas and find out if they are, in fact, crazy. But if it turns out that those ideas are actually pretty slick, I’ll know that and can release the design with confidence instead of with gritted teeth.

top left High Visual and Low Functional Fidelity

At first thought, these prototypes may not make much sense. Why bother making something look nice if it doesn’t work? Well, because how something looks can have a huge impact on how easy it is to use. A high visual and low functional fidelity prototype allows you to test that with users. You can print out screen images and do a paper prototype test with them, or you can image map some JPGs and do what I’ve heard termed a “slap and map” test from within a browser.

top right High Visual and High Functional Fidelity

High visual and functional fidelity prototypes are the Rolls-Royce of prototypes. They take more time and effort to build than a lower fidelity prototype and are correspondingly more complicated to manage. Most of the time, this extra cost isn’t worth it. But there are a few situations where it is:

  • Evaluating the usability of proposed UX designs for an existing system
  • Performing usability tests with non-savvy user groups
  • Supplementing printed documentation for offshore development teams

Prototype testing is all about data, right? In the first two situations above, the prototype’s high visual fidelity reduces the confounding factors a wireframey prototype can introduce into test results, thus maintaining the quality of your data. In the third situation, the high visual fidelity helps minimize the design communication and interpretation problems inherent in offshore development.

Integrating Prototyping Into Your Design Process

What I’ve talked about so far has focused on the tactical, on how to prototype effectively to achieve specific goals. What I want to talk about now is more strategic. How can you integrate prototyping effectively into your design process?

First off, do what you’d do to begin any organizational change. Start small. Find a small project, express the value of prototyping and your interest in doing it, and do it. It would be best to start with something richly interactive though, as prototyping is more crucial the more interactive a system is. Of course, make sure you use a prototype of the right visual and functional fidelity for your purpose.

People like shiny things that move. The cool factor of prototyping will be difficult to resist.

As you near completion of the prototype, make sure you walk through the prototype with the project’s stakeholders. Ask them if something like this was what they had in mind. This will impress them on two levels. First, people like to feel important, and you’re soliciting their opinions. Second, people like shiny things that move. The cool factor of prototyping will be difficult to resist. When these stakeholders are involved in future projects, it’s very likely they will actually request a prototype as a result of their first experience with you.

Once you get buy-in, you can start integrating prototyping into your process. But just like different methods of prototyping are more effective for answering certain questions, different business contexts call for different ways to integrate prototyping.

Corporate, Agile, Mature UX Practice

This situation is fast-paced and iterative, but as an employee (as opposed to a contractor or consultant) you have the opportunity to own the UX of your company’s products. In this situation, there are three points in the design process that prototyping can be of benefit.

  • Low visual and functional fidelity prototypes can help select good UX concepts from several that you develop at the beginning of a project.
  • High functional fidelity proof-of-concept prototypes can help develop those concepts into usable designs.

You can work with a dedicated prototyper to build a separate prototype using code that can be reused in the production system to build efficiencies into an Agile process.

Corporate, Waterfall, New UX Practice

In this situation, the organization might not be comfortable enough with UX design to support the development of multiple UX concepts. You might just have to begin developing the wireframes and prototypes to meet the organization’s need for documentation and measurable signs of progress. This situation relies heavily on the prototype for communicating and validating direction with project stakeholders, with user testing often not yet being a real possibility. Here’s how prototyping can help:

  • High functional fidelity prototypes can help you communicate better with stakeholders and get their input on your direction
  • These prototypes should also be used for user testing, if at all possible.
  • Walk through the interactive prototype at the same time you walk through the printed documentation for the developers during handoff.

Consulting/Agency

When doing UX design for an external client, a lot of the magic is worked behind the scenes. The result is a process that is relatively unencumbered by internal politics. The challenge is to convey the importance of iterative prototyping to clients who sometimes feel like they’re paying for the same thing twice.

  • Sketch two or three of your design concepts into simple, low visual and functional fidelity prototypes and test them to decide which to go with. At this stage, testing can be very informal and done with anyone capable of putting themselves in the user’s shoes (e.g., other UX designers, customer service staff, or product managers who used to be users).
  • Build a small interactive prototype that shows the critical interactions, walk through it with stakeholders to validate your direction, then test with users.
  • Revise the prototype based on the test results, flesh it out to support more holistic tasks, and test again.
  • Revise the prototype and use it to supplement the paper documentation as you walk through both with the development team.

Just like with any other UX research or design tool, context plays a critical role in determining how effective prototyping will be for you. If you follow the simple guidelines above and prototype to an appropriate level of fidelity for your context, you will achieve your goals and improve your design. No firearms required.

UI Pattern Documentation Review

Written by: Patrick Stapleton

Introduction

User interface (UI) patterns have the potential to make software development more efficient. The prospect of such efficiency gains has led to interest in user interface (UI) patterns by individuals and organizations looking for ways to increase quality while at the same time reducing the costs associated with software development.

The very nature of UI patterns requires that they be familiar to end-users. An individual UI pattern is a discrete, repeatable unit of user experience. I refer to collection of patterns as a library.

In many cases, less proprietary patterns are more useful in solving a design problem as they can be implemented more uniformly across platforms. This characteristic and the efficiency gains make patterns an excellent opportunity for software companies to come together and promote UI patterns to the wider development community.

Producing a common pattern library, however, implies that the patterns presented are at the very least, consistently documented and most probably presented in the same single classification system. Currently though, patterns are classified and documented in various manners across publishers with no clear standard evident.

The problem

To date, the most common approach to propagating a single user experience standard is the development of UI guidelines and principles documentation within an organization. Development teams  — usually incorporating a user experience specialist — then reference this documentation during implementation and upgrade processes.

However, as the numbers of systems grow within an organization, so does the effort needed to maintain the quality and consistency of the user experience. For many organizations, it is now impossible to assign much, if any, time of a user experience specialist to all implementation efforts, and experience has shown that the UI guidelines and principles approach to propagating a single user experience standard does not scale well.

There are two common issues, both major.

The first issue is ensuring developers are familiar with all the principles and guidelines.

Documentation to fully describe a UI standard is, by its nature, extremely detailed and complex. Getting developers to know all this information intimately is an ongoing and often un-winnable battle.

The second major issue is that the application of guidelines and principles can be open to wide interpretation.

Requiring developers to combine guidelines and apply principles together to create a complete UI can be inefficient. This synthesis process can result in widely-varying solutions to a single design problem across teams — especially when working with widely distributed and possibly culturally diverse groups. Removing these variances to create a more consistent user experience requires rework.

The solution

UI patterns to a great extent mitigate the problems of weight and interpretation experienced with the principles and guidelines documentation approach of the past. In essence, patterns can be seen as prepackaged solutions based on guidelines and principles.
Patterns and pattern libraries are more convenient for developers because they solve common higher-level design problems without the need for deep knowledge of often-complex guidelines and principles documentation. Also, they implement best practices, so developers don’t synthesize what are often “slightly original” solutions that would need to be reworked later.

Much of the value of a pattern to the developer is its less granular and more physical nature. Principles of good UI design dressed up as UI patterns add little value over traditional guidelines and principles documentation, as seen in many of the UI patterns as described in the Design of Sites; examples such as “Low Number of Files” — while an important design principle or guideline — do not deliver up a usable UI component.

Also important is creating the patterns to begin with. The guidelines and principles that form the foundation of patterns still need to be developed before any patterns themselves are developed.

Integrating UI patterns

Integrating UI patterns into the culture of software development is to a large extent still beginning. Next-generation development tools such as those proprietary ones being developed by enterprise software companies that implement patterns natively are now or will be soon in the hands of developers around the world.

Embedded drag and drop UI patterns hold the promise to empower developers to create better user interfaces, faster — unsupervised by user experience specialists. While this may strike fear in the hearts of many a user experience specialist, issues of scale dictate such a pragmatic approach. Be aware though, that they also can perpetuate problems if the UI patterns implemented are out of sync with end-user expectations.

Why standardize UI patterns?

Currently, there is no recognized standard for the classification or documentation of UI patterns, as seen by browsing through pattern libraries from:

  1. Martin Welie’s UI patterns
  2. Jennifer Tidwell’s UI Design Patterns
  3. Sari Laakso User Interface Design Patterns
  4. The Design of Sites: Patterns, Principles and Processes for Crafting a Customer-Centered Web Experience by van Duyne, Landay and Hong.
  5. Yahoo Design Pattern Library

The variety isn’t surprising, since applying the pattern concept to user experience design is a relatively recent phenomenon. However, the successful introduction of a single classification and documentation standard could significantly increase the value of a UI pattern library to developers by…

  • Reducing confusion among pattern versions across collections. Not surprisingly, many of the same patterns exist across collections. A standard classification system (discussed below) can help developers make sense of both these patterns and their different versions in collections across the web and in paper publications.
  • Promoting development of net new UI patterns. A clear classification taxonomy is likely to make the “holes” in the current crop of pattern libraries more apparent, which in turn hopefully will increase the pace of development of new UI patterns.
  • Providing a standard UI pattern interface. As the number of patterns increases, pattern search tools will become more important. A standard classification and documentation approach will enable developers to quickly display their UI options.
  • Promoting UI pattern adoption. A clear classification taxonomy is likely to have the effect of making patterns easier to find and in turn increase their use.

Problems with the solution: UI pattern Classification Approaches

The following is a high-level analysis and discussion on classification approaches of the previously mentioned UI pattern collections. Each collection is mapped and discussed from a classification and documentation perspective.

Martin Welie’s patterns

Classification Analysis

Patterns in Interaction Design

Cropped version of Welie's patterns

Figure 1. Classification Map (click image to enlarge)

Welie divides the patterns into three delivery methods: Web design patterns, GUI design patterns, and mobile design patterns. Within the web design patterns channel (the focus of this document), the patterns are categorized into ten groups based on a mix of content and functional subjects.

Documentation Approach

Cropped version of Welie's approach

Figure 2. Documentation Map (click image to enlarge)

Welie’s documentation approach is simple, with a focus on visual elements to explain the function of the pattern. It can be broken into three main parts:

  • Description: This area of the documentation provides the name and image to describe the pattern.
  • Rationale: This area provides a description of the problem that is solved by the pattern, how it works, and the scope of its use.
  • Associations: This area provides links to other patterns related to the current pattern.

Jennifer Tidwell’s patterns

The following is a map of Jennifer Tidwell’s UI Design Patterns. (Click image to enlarge.)

Cropped version of Tidwell's patterns

Unlike Welie, Tidwell does not take into account different delivery methods. The eight categories she does specify look to be based on functional subject areas only.

Sari Laakso’s patterns

The following is a map of Sari Laakso’s UI patterns. (Click image to enlarge.)

Cropped version of SL's patterns

Like Tidwell, Laakso does not differentiate between delivery methods; he bases all seven of his categories on functional subject areas.

The Design of Sites’ patterns

The following is a map the patterns presented in “The Design of Sites.” (Click image to enlarge.)

Cropped version of Design of Sites' patterns

The most extensive pattern collection of the four sampled, Design of Sites does not specify delivery methods, and, in some cases, the items presented could be regarded as design guidelines or principals rather than patterns. Twelve categories are presented with a mix of content and functional subjects.

Summarizing the classification types

From this analysis three main types of classification are present — content subject, functional subject, and delivery platform.

Content subject classifications normally specify an application genre (for example, ecommerce and supply chain management). Examples of content subject based classifications can be found in the Design of Sites collection under “Site Genres” and in Welie’s collection under “Site Types.”

Functional subject classifications are based on logical breakup of functionality (for example, shopping cart and two-panel selector). This is the most common prevalent classification type and is found in all the collections sampled.

Delivery method is used to describe the platform on which a pattern has been designed to operate. This classification type opens up the possibility for unique patterns to be developed for the same subject classifications across platforms. This classification type has the potential to provide more resolution for developers looking to offtake a pattern within a specific UI delivery platform such as mobile, desktop, or web.

Based on the publicly available pattern libraries available today, there is no clear indication as to whether “delivery method” is a valid classification type. An argument could be made that the process of binding a pattern to a specific technology is will reduce the life of the pattern as platforms develop. However, the timelessness of a pattern is of little consequence to developers whose primary goal is product delivery rather than pattern lifecycle.

Another Classification type – Level

This author would like to include an additional classification type: Level.

The level classification would further divide patterns into the following areas of concern:

  1. Navigation architecture: Patterns relating to the navigation of content within an application
  2. Screen architecture: Patterns which position functionality and content within a screen
  3. Site furniture: Patterns for formatting functionality and content

In the case of the collections previously reviewed, the great majority of patterns would be classified as falling under the “site furniture” level type. However, it is this author’s view that considerable potential remains to develop patterns within the proposed navigation architecture and screen architecture level types.

A proposed classification system

Cropped version of the classification system

The above diagram (click image to enlarge) describes a potential pattern library classification hierarchy. In this case, client classification nodes are presented at the top of the tree similar to that of the Welie collection; the proposed new level classification nodes are added above subject.

Content and functional subjects would be implemented as tags because these classifications would occur across levels.

Why have a classification hierarchy — aren’t filters or tags more useful?

In many cases, being able to filter by classification node as required is more flexible than drilling down through a preset hierarchy. However, a present classification tree is also useful to:

  • Automate the generation URLs to enable cross linkages within the UI pattern library.
  • Provide a simple drill experience for end users who have no specific problem to solve but rather just wish to browse to learn and or generate ideas.

UI pattern Documentation Proposal

The value of a standardized UI pattern documentation to developers is a single interface for search tools. Such tools hold the potential to streamline the off take of UI patterns by developers with specific problems to solve in a world with hundreds and potentially thousands of UI patterns to choose from.

UI patterns are by their nature visual. It must be noted that strong support for pictorial content would seem obvious and reduce the necessity for long verbal descriptions that add little value next to their visual equivalents.