[ 20 ]

Choose the Right Interface Model: Wireframes, Comps, or Prototypes?

Until now, we’ve used sketches to make interface models. You make a model, so you can Check it. Another way to say that is: you make interface models to answer a question. And since sketching helps teams think about three visible parts of the interface—the content, functionality, and layout—another way to say this is: you make sketches to answer questions about content, functionality, and layout.

A sketch is one type of interface model that lets you ask certain questions, but it isn’t the only way. You can model interfaces five ways. To answer the right questions, choose the model that offers the right fidelity to answer the right question.

Five Types of Interface Models (and the Actual Product)

Whenever you talk about an interface, you talk about either an actual interface, like the actual product, or an interface model, like a wireframe. The actual product is always the actual product. However, you can model an interface in other ways. In all, you have six ways to Check an interface:

• Text descriptions
• Sketches
• Wireframes
• Mockups (or visual comps/compositions)
• Prototypes
• The actual product

Each interface model offers a different level of fidelity. Knowing how the five types of interface models compare to the actual product helps you choose what model to Think-Make-Check when you collaborate with your client and team.

Text Descriptions

Text descriptions are the fastest way to describe an interface.

Think about the best developer you’ve ever worked with. Now imagine you both want to build a Product Detail screen for your ecommerce site. Imagine you bump into your favorite developer in the hallway and talk about the new Product Detail screen. You talk about having the product name, a description, and a product image. And of course, you talk about an “Add to cart” button.

With only that information, you know everything you need to design the interface, and the developer has everything they need to start coding. For any interface, talking about the content and the functionality is the quickest, easiest way to describe the interface. In the case of the Product Detail screen, you and your developer friend walk away with two lists.

For content, you identified three items:

• Product name
• Product description
• Product image

For functionality, you identified one item:

• “Add to cart” button

Although a text description lets you describe the content and functionality, you and your favorite developer each make assumptions about the visual design and the layout.

Sketches

With a text description, you can describe content and functionality. Sketches expand a text description’s content and functionality to include layout (Figure 20-1).

Imagine the Product Detail screen you talked about with your favorite developer. Step up to a gleaming whiteboard and draw the screen in blue marker. Squiggles for text, a box with an X for the product image, and a rectangle for the “Add to cart” button. By sketching the screen, you’ve now discussed the content, functionality, and the layout.

Although a sketch offers more information, it’s only a general idea about the layout, and you still have to imagine the visual design.

Wireframes

Wireframes add more detail than when you describe the interface (Figure 20-2). In addition to content, functionality, and general layout, you start to replace unspoken assumptions about format with real specifics.

Figure 20-2

A wireframe adds content format and quantity to the functionality and layout

The additional detail in a wireframe reveals how much content can appear, the length and format of content strings, the size of images, and other details. Wireframes also include more accurate information about the layout and clearer detail about affordances for functionality. Is “Add to cart” a big button or a small button?

Mockups

Mockups, or visual comps, show what the actual product would look like to the user (Figure 20-3). The mockup isn’t the actual product, but it looks like the actual product. Mockups show a “comprehensive layout”1 that includes exact color, spacing, typography, and photo and illustration styles.

Figure 20-3

A mockup shows what the product could look like

Usually, a mockup shows how the wireframe will appear in its final state. However, like the wireframe, the mockup only suggests screen behavior. You can’t see actually what happens when the user clicks on the “Add to cart” button.

Screenshots

Unlike the other types of interface models, a screenshot is an image of the actual product, not a model of the interface. However, because it’s just an image, it provides the same kinds of information you see in a mockup. Screenshots show actual content, its format, fonts, color, and layout.

Although screenshots seem exactly like mockups, there’s one important difference. A mockup is a model of an interface. A screenshot is a picture of the actual interface.2

Prototypes

Prototypes add real functionality. In addition to knowing the content, functionality, layout, and design for the screen, the prototype can show what happens when the user clicks the “Add to cart” button (Figure 20-4). Does the user stay on the Product Detail screen and see a message that says the product was added to the cart? Does the user click through to another screen where they see their shopping cart?

Figure 20-4

A prototype allows you to show what happens when users interact with the screen

The Actual Product

The actual product isn’t a model of the interface. It’s the actual interface. For the Product Detail screen, you see real content and the functionality really works. You see the Product Detail’s actual visual design, and you can look at the screen in a real web browser.

Each of these ways for discussing interfaces illustrates the interface at a different level of fidelity. These different fidelities let your team answer different questions.

How do you know what interface model to use? You choose the model that provides the right fidelity.

Five Kinds of Interface Fidelity

When you design interfaces with your team and clients, you want to have the right kinds of conversations about the right things. The right fidelity maintains your team’s shared vision. The more fidelity, the more you ensure the shared vision, but the longer it takes to Make something before you can Check it. Less fidelity and you iterate faster, but the team shares less vision.

Adjust the fidelity of your model in five ways:

• Content fidelity
• Functional fidelity
• Layout fidelity
• Visual fidelity
• Contextual fidelity

Content Fidelity

When you create an interface model, content fidelity describes how accurate the content is. When you show a Product Detail sketch, do you have a squiggle for the Product Name? Did you write, “Product Name,” or did you write the name of a real product?

Visual designers often use “greeked text,” like “Lorem ipsum...,” in mockups. Greeked text has less content fidelity than real, sample content (Figure 20-5). When visual designers use greeked text, they want to see how well a typeface works in a visual design, and any letters will do.

What if you wanted to Check that your labels were clear? Can you evaluate labels in an interface with greeked text? Probably not.

Content fidelity exists at three levels:

• Content type
• Content format
• Actual or sample content

Let’s say you sketch a Product Detail screen with your team. If you scrawl “Product Name” at the top of the sketch, then you’ve identified the type of content that will appear.

If you note the Product Name will be “text” that is no longer than 150 characters, then you have defined the content format.

If instead you wrote, “Guatemalan French Roast,” then you’ve used actual or sample content.

The fidelity lets you Check different questions about the content. Do you want to ask about what content? The content format? Or make sure the interface works with real content?

Functional Fidelity

Functional fidelity describes how well functionality works in your interface model (Figure 20-6). Do links work? Or are they just blue text with underlines? You can gesticulate wildly to describe how something moves, or you can just show an animation.

Figure 20-6

Functional fidelity refers to how accurately functionality appears in your interface model

Like content, functional fidelity works at three levels:

• Functionality type
• Functionality format
• Actual or sample functionality

Let’s say you sketch a Product Detail screen with your team. If you scrawl “Add to cart,” then you’ve identified the type of functionality you want available.

If instead you make a wireframe and include a button that says, “Add to cart,” then you have defined the functionality’s format as a button. (You could have used a link instead.)

If you create a prototype that shows a lightbox appears when you click the “Add to cart” button, then you’ve illustrated the actual or sample functionality.

Layout Fidelity

Layout fidelity describes how well your model demonstrates the interface’s layout (Figure 20-7). Do you have a sketch with a general layout? Or are you looking at a mockup with exact spacing and positioning?

Figure 20-7

Layout fidelity refers to how accurately the layout appears in your interface model

Layout fidelity also works at three levels:

• Prominence or priority
• Relative position
• Actual position

When you use 4-corners to prioritize a list of the Product Detail’s content, you identify the importance of each element, or how prominently it should appear in the interface.

When you sketch the Product Detail screen with your team, you placed the content on the screen. Your layout describes how each piece of content will appear relative to other content.

If instead you create a pixel-perfect mockup, you illustrate the actual position of each piece of content.

Visual Fidelity

Visual fidelity describes how closely the interface model resembles the actual product (Figure 20-8). Like all fidelity, the higher the visual fidelity, the easier it is for someone to understand. You can see this in action in your career: some clients just don’t “get it” when they see a wireframe. They have to see a mockup.

Figure 20-8

Visual fidelity describes how closely the interface model resembles the actual product

Like content, functionality, and layout, visual fidelity also works at three levels:

• Suggested visual design
• Relative visual design
• Actual visual design

If you describe the Product Detail screen in an email and mention it will include your logo, then you suggest the visual design.

If you make a wireframe and use the company logo and brand colors, you use the relative visual design.

If you create a mockup and use the company typeface, colors, logo, and spacing, then you show the actual visual design.

Each of these visual fidelities provides answers to different questions about the visual design.

Contextual Fidelity

Contextual fidelity refers to the context where people will see and use the interface (Figure 20-9).

Let’s say you want to test the usability of a web application. Do you show users paper printouts of each screen? Or do you have them click through screens in a web browser?

If you show your interface model in the context where end users will actually interact with it, your interface model has more contextual fidelity than if you showed a bunch of printouts.

Figure 20-9

When you show an interface model to someone, how accurate is the context? Are they looking at a mobile app on paper or on their smartphone?

You can describe contextual fidelity in three levels:

• Suggested context
• Relative context
• Actual context

If you say customers will use the Product Detail screen in their web browser, then you have suggested the screen’s context. If you make a wireframe the same size of a web browser, then you illustrate the relative context. If you show the Product Detail screen in an actual web browser, then you show the screen’s actual context. If you install a hardware prototype in a place similar to where it will live in the real world, then you’re displaying the device’s context.

Contextual fidelity affects the types of questions you can ask about how an interface will be used.

Three Ways to Make Interface Models

The tools you use to make the model also control the fidelity of your interface model.

Text descriptions and sketches can be made by hand. You use software to create wireframes and mockups. Prototypes and actual products require operable code that receives and responds to user interaction.

That doesn’t mean you can’t use software to write a text description or sketch an interface. You can, but you can’t create a wireframe or mockup without software, and you can’t build a prototype or product without code.

Different Models Support Different Interface Fidelity

To Think-Make-Check an interface with your team or your client, you work through two steps:

1. Know what question you want the audience to answer.
2. Show a model or actual interface that includes the information your audience needs to answer that question.

Different types of interface models support different types of fidelity at different levels (Table 20-1).

Table 20-1. Five types of interface fidelity at three levels

Fidelity of Prototypes and the Actual Product

Of all the ways you can Check an interface, prototypes and products display the highest possible fidelity and take the longest to produce. Prototypes and products also provide the greatest flexibility since they can also display fidelity at any range from low to high (Table 20-2).

Table 20-2. Prototypes and products provide the maximum amount of fidelity (area shaded in orange) and take longer to produce

Fidelity of Sketches and Text Descriptions

Prototypes and products take much longer to create than other interface models. In contrast, you can create interface models like text descriptions and sketches by hand much more quickly than you can create prototypes or products. In exchange for that speed, your model has much less fidelity and you can answer a more limited set of questions (Table 20-3).

Table 20-3. Text descriptions and sketches provide low levels of fidelity (area shaded in green) in a short amount of time

Fidelity of Wireframes and Mockups

Wireframes and mockups live in a sweet spot between how long they take to create and how much fidelity they provide. Wireframes and mockups let you answer more questions and evaluate more assumptions in less time. This flexibility and usefulness explain why wireframes and mockups continue to be used despite periodic trends for prototypes or sketches (Table 20-4).

Table 20-4. Wireframes and mockups provide almost as much fidelity (area shaded in blue) as prototypes and products in a fraction of the time

Use the Lowest Fidelity Possible to Reduce Iteration Time

With each type of model, trade how long it takes to create with what kind of question you can answer. To help the experience machine learn as quickly as possible, choose the model you can make in the least amount of time that answers your team’s specific question.

The interface model you choose must include the information you need to Think-Make-Check. If you want to check content and functionality, don’t spend a bunch of time creating a mockup. If you want to see if an animation makes sense, then a wireframe won’t do. You have to use a prototype.

When you choose how much fidelity to include, use the highest fidelity for the question you want to check. At the same time, use the lowest fidelity possible for everything else. Optimizing fidelity makes the model quick to produce, so you can iterate quickly.

Also, if you show too much fidelity too soon, you can trigger disagreements that distract from the question at hand. If you want to check functionality, and someone gets hung up on color, you lose what they might have had to say about functionality.

So, it all comes down to the question you want to answer.

Questions Different Interface Models Can Answer

The question you want to answer drives the fidelity you need and the interface model you can use. Your team can evaluate an almost infinite number of questions about any given interface.

The following table of common questions (Table 20-5) can help you decide what interface model to choose. Although a list of questions is never complete, the table includes many common questions that face product teams. Select the question you want answered, and the color of the cell indicates the model that supports the fastest iteration time for that question: green for sketches and text descriptions, blue for wireframes and mockups, and orange for prototypes and products.

Table 20-5. Different interface models can answer different types of product questions. Sketches and text answer many questions (area shaded in green) while other questions require wireframes or mockups (area in blue) or prototypes and products (area in orange)

Adjust Fidelity for Your Audience

Way back in Chapter 2, we talked about how your audience and channel affect the fidelity of the models you make. Generally, the farther away the audience, the more fidelity you need to include in your model (Figure 20-10).

Figure 20-10

The farther away your audience, the more fidelity you need to include in your interface model

Audiences that are farther away need more fidelity because they share less of the team’s vision. Your team shares more vision with itself than with the CEO because you and your team talk every day, while you communicate with the CEO less frequently.

Tacit, Implicit, and Explicit Information

As a rule of thumb, you can share interface models at low fidelity with yourself and your team. When you share with your organization, the models need to be at medium fidelity, and when you share with users, you should aim for high fidelity (Table 20-6).

Table 20-6. Audience and minimum fidelity to use when you Check interface models

In practice, you can reduce the amount of fidelity you show a given audience if the audience already has the information they need to answer the question you want to ask.

Let’s say you want to ask if someone agrees with the content on the Product Detail screen. If that person is on your team, and you’ve worked through the 4-corners together, then they know what content you want to include. Let’s say you ask the CEO about the content. How would they know what content you wanted to include? When you adjust the fidelity for your audience, you make sure the CEO knows enough about the content on the Product Detail screen to agree or disagree with your design.

There are three kinds of information your audience may or may not have:

Tacit information

Information that is understood without being suggested

Implicit information

Information that is implied, though not stated

Explicit information

Information that is specifically stated

Explicit information

Explicit information is the easiest to understand because it’s anything that is specifically stated. If you see text on a screen that says, “View my profile page,” the text is telling you exactly what happens when you click it (Figure 20-11).

Implicit information

Implicit information refers to anything your audience can figure out from looking at your interface model. If you have a wireframe with a drop-down, most people will know that when they select the drop-down, they’ll see a list of options to choose from.

Tacit information

Teams live off of tacit information. This is all of the things you and your team members know because you’ve been working together. Tacit understanding is about your team culture. When you see a magnifying glass next to a text input, you probably know that’s a search field. Nothing in the interface model tells you it’s a search field, and a magnifying glass by itself doesn’t say “search.”

You can check the content in your sketch with the CEO if they understand that the squiggle at the top is the product name and the lines are the product description. However, if they might not understand the squiggle and lines, then you need to make the interface more clear.

Clarify Fidelity to Set Expectations

For an ecommerce website, I presented a wireframe to a room full of C-level executives. The room got quiet, and then the CTO spoke. “This is terrible. The website can’t be all gray.” I wanted to check content, functionality, and layout, and my audience wanted to check visual design.

Either spend more time to create interface models with more fidelity, or set expectations about what the model includes and—just as importantly—what it doesn’t (Figure 20-12). For the CTO, I should have clarified that I wanted him to Check the content, functionality, and layout and that the wireframe would not show the final visual design.

Figure 20-12

Set expectations to share tacit information with your audience so they can answer the question you want

When you set expectations, it creates a tacit understanding about the model that gives your audience the additional information they need to answer your question.

Use Annotation to Offset Low Fidelity

You can provide more information about an interface without improving fidelity. Annotations provide explicit information without any changes to a model. If you want to ask the CEO about the content on your Product Detail sketch, and you’re worried she won’t know what the squiggle is, you can add an annotation that says, “Product Name.”

Annotations can add explicit information to any part of a model. Annotate content, functionality, layout, visual design, or context. Designers pack wireframe specifications with annotations to describe information you’d only otherwise see in a prototype or actual product (Figure 20-13).

Figure 20-13

Wireframe specs use annotation to describe functionality that would not otherwise be clear without a prototype or the actual product

Set Expectations and Use Annotations to Conquer Distance, Time, and Reach

Set expectations and add annotation to counter the effects of distance, time, and reach. Team members separated by distance and time will never have the same tacit understanding as colocated team members, so set expectations and add annotations to collaborate better.

Add clarifying notes to your interface model to reduce misunderstandings and unnecessary churn that slows iteration. Ultimately, it’s your responsibility to make sure your audience understands what they’re looking at and has the information they need to answer your question.

As always, balance your need for speed with your need to communicate clearly. Get the balance right,3 and you’ll help your team learn more and faster,4 and your experience machine will release better products.