by Leah Buley
FIGURE 7.25
A Web page that has been assembled through design collage. The next step would be to turn this into a wireframe.
• If you work remotely... Design can be a tricky part of the process for remote workers. Some points require total heads-down focus (great for being remote). However, some points require quick iterations, lots of subtle feedback, and an astute reading of body language to understand how people really feel about it (better in person). There’s also a lot of talking and explaining that happens during this time, and doing it over the phone is definitely harder than doing it in person. There’s often a point somewhere about halfway through the design work ... when things finally seem to be taking shape and—surprise!—suddenly it all seems to go off the rails, and your colleagues start to express big concerns about the design direction. This is when it can be most difficult to be far from the rest of the team.
Often, this moment coincides with the point at which designs have moved out of the comfortably ambiguous sketching phase and are starting to take a definite (and definitely digital) form. It may be that finally seeing something definitive and tangible causes people to get worried about all the things that aren’t right yet. Fearing that they’re being locked into a direction that’s not all there yet, people sometimes freak out. I call this the design triage period. This is definitely a time to be with your team in a high-touch, face-to-face way, if you can. If possible, plan ahead and expect that there will be a design triage during the wireframe period, and expect to be onsite and in person with your team for a few days in the middle of it.
If You Only Do One Thing...
The methods in this chapter show the range of considerations that you have to think about when doing user experience design, from the core positioning of the product, to what different forms the user experience could take, to the tactical nuts and bolts of how the design will ultimately function. The underlying spirit of it all is that design should be an exploratory and inclusive process that you help shepherd other people through.
So if you really want to get bang for your buck, focus on “Sketchboards.” They are your secret weapon for getting people involved, excited, and engaged. “Sketchboards” will not only help other people see how the user experience design process works, but they’ll also help you improve upon your designs with the help of others.
CHAPTER 8
Testing and Validation Methods
METHOD 19
Paper and Interactive Prototypes
METHOD 20
Black Hat Session
METHOD 21
Quick-and-Dirty Usability Test
METHOD 22
Five-Second Test
METHOD 23
UX Health Check
If You Only Do One Thing...
Testing and validation methods help you figure out if your design will actually work. Will people be able to use the product or service as intended? Does it trigger positive emotional responses? How fluid and seamless does the user experience feel overall? Sometimes this kind of work is referred to as “usability” or “usability testing”—where the emphasis is clearly on whether you can use the product without error. Usability is part of it, but it’s not the whole story. You’ll also want to validate the emotional impact created by the experience, the fluidity of the product or service, and how well the overall product paradigm matches the mental models that people bring to it.
There’s a popular misconception that this kind of research has to take a lot of time and effort to be done right. That’s not the case. Whatever enables you to validate designs quickly with real people and gain confidence that the design is moving in the right direction is fair game. The testing and validation methods in this chapter can be done on the quick and on the cheap. In this chapter, we’ll cover:
• Paper and Interactive Prototypes. Does it work and feel as intended?
• Black Hat Session. What areas of the design could be improved?
• Quick-and-Dirty Usability Test. Can people use this product as intended?
• Five-Second Test. What impression is created by a specific screen, step, or moment within the product?
• UX Health Check. Can you measure the baseline quality of a user experience and assess changes in quality over time?
METHOD 19
Paper and Interactive Prototypes
Does it work and feel as intended?
Prototypes are semi-functional models of a product that help you test how it will work and feel. Prototypes can vary widely from the crudest paper-based explorations to highly realistic, functional models. This basic approach—idea first, then prototype, and then further improvement based on what you learn—is a powerful and time-endorsed method for any type of new product development. And it’s an excellent practice for you to get into as a team of one because people expect UX practitioners to drastically improve the product design. Some skilled UX practitioners just naturally know how to do that, but if you’re (like me) not always exactly sure of what needs to happen to make a killer design, prototyping and iterating give you a method where you can comfortably trust your gut and still give yourself space to learn and improve as you go.
Average Time
Varies based on format of prototype. You can turn wireframes into a paper prototype in just a few hours or less. Building a more functional prototype with working code can take multiple days.
Use When
You want to validate the direction prior to investing the time and resources to make it fully real. Often, you’ll discover that an idea doesn’t work quite as well as you originally imagined. Discovering this information early on enables you to modify your design in a relatively cheap and efficient way, and to evolve the design with real-time feedback.
Try It Out
1. Think about the purpose of the prototype.
Different points in the process argue for different types of prototypes. Ask yourself what type of validation you are trying to do and select the appropriate tool. Here are some different forms a prototype might take, depending on your goal:
• To validate early concepts, a paper prototype (just static pictures or sketches representing a few select screens or moments in the product) should be enough.
• To get a sense of how a sequence of screens or moments flow together, a dummy clickable prototype usually suffices to illustrate how a discrete experience will unfold. A “dummy” clickable prototype includes the bare minimum of interactivity. These types of prototypes are often created by putting static pictures together in some software that enables you to create simple hyperlinks or hotspots to simulate the sense of interactivity. Fireworks does this well, but you can also use simple tools like PowerPoint, Keynote, or Adobe Acrobat to create a dummy clickable prototype.
• To simulate intended interactions as realistically as possible more robust prototyping tools may be needed. You may need prototyping tools that enable you to integrate basic conditional logic. Popular tools for this include Balsamiq, Axure, iRise, Flash Catalyst (from Adobe), and good old-fashioned HTML. If you have technical knowledge, you can also prototype directly in whatever the target technology is, which is arguably the most efficient because you may be able to repurpose the prototype into production code. This type of prototype can be useful when you want to do rigorous usability testing before actually building the product, or when you want your colleagues or potential clients to get a realistic sense of what it will be like to use the product.
2. Make your prototype.
This is the fun part. Depending on your prototype fidelity and tool, this may be as simple as cleaning up some wireframes and printing them out, like the paper prototype in Figure 8.1, or it may require more time for writing code or setting up software to behave as you intend.
FIGURE 8.1
Here, wireframes have been repurposed as a quick-and-dirty paper prototype.
A couple of things to think about as you work on your prototype:
• Typically, a prototype shows a se
quential experience. There is a beginning, middle, and end that correspond to how somebody would (ideally) move through the product. To structure your prototype, plan out your beginning, middle, and end on paper, and think about the states or screens that make up this sequence. Think about how minutely you want to illustrate the subtle transitions that take someone from one moment to the next in your product. For example, do you want to show how a user might move from field to field in an online form and what validation messages might appear, or is it enough to just show an empty form, followed by whatever screen people would see after they filled it out? The answer depends on what you’re trying to validate. If the purpose of the prototype is to show how form errors should be handled, then field-by-field is probably the way to go. If it’s to show how someone can create a profile and then get started using an app, maybe form-level interactivity is overkill. The main thing is to think carefully about which states you will need.
• A design is the content and information within it, so it’s great if you can test the comprehensibility and usefulness of the information—the content, the data, and so on—just as much as you’re assessing the flow and functionality. Put a little thought into the placeholder content you’ll be including in your prototype. While people are remarkably flexible in looking at and responding to in-progress designs, it turns out that with more realistic content, you can more easily make sense of what you’re seeing. If possible, seed the prototype with reasonably realistic data to enable observers to see how information will unfold as they progress through the experience.
3. Validate the prototype with yourself and others.
Use the prototype to observe how someone would really interact with the design if unaided and left to his own devices. To do this, put the prototype in front of a volunteer or a representative user and give him a task. Start at the beginning of the experience that you’ve prototyped and ask him to show you what he would do in order to complete the task. What would he interact with? What would he touch or click on to complete his task? Remind him that his only goal is to complete the task you’ve given him. Ask him to explain what he thinks he is seeing at each step along the way. Undoubtedly, you will see things that surprise you once you see people interacting with the design. From this, either one of two wonderful things happens. Either you learn that the design works as intended, which is great. Or you learn what’s not working well yet, and you get some ideas for how to improve it—and that’s great, too.
Tips and Tricks for Paper and Interactive Prototypes
• Know when to prototype and when not to. Not everything you design has to be prototyped. Prototyping can save you time, but making a prototype takes time, too. You want to be sure that you’re investing the time to validate something that really needs to be validated. In general, prototypes are ideal for validating new or nonstandard interactions or products, or for testing parts of the product that are simply too important to get wrong. To figure out what parts of the product are good candidates for prototypes, you can plot features and functions on a Critical/Complex graph like the one shown in Figure 8.2.
FIGURE 8.2
A Critical/Complex graph helps you identify which parts of the product are most important to prototype.
• If you work remotely... Prototypes are almost by definition incomplete. (If they were fully complete, they’d be the finished product.) That means that with any prototype, there’s always a certain degree of imagination required to envision how the rest of the product functions beyond what has been prototyped in detail. If the viewer isn’t familiar with how the prototype is meant to work, confusion can ensue. For that reason, unless the prototype is very functional and self-explanatory, schedule time to review it with the team—by phone, if not in person. Don’t just release the prototypes into the wild and ask people to send feedback. If you are doing usability testing with the prototype, invite the team to observe remotely using video conferencing or screen-sharing software.
METHOD 20
Black Hat Session
What areas of the design could be improved?
Black Hat sessions are inspired by Edward DeBono’s Six Thinking Hats. “Six thinking hats” is a facilitative framework where teams adopt deliberate mental attitudes in order to make group work more dynamic and directed. With a group discussion using six thinking hats, each individual figuratively puts on a hat of a certain color. Each color signifies a particular point of view. For example, there’s a hat for optimism (the yellow hat), one for emotion (the red hat), one for creativity (the green hat), etc. There’s also a hat for judgment, negativity, and skepticism, and that is the black hat. A person wearing the black hat is obliged to point out weaknesses or risks, and to be frank about what’s confusing or seems like it could be further improved.
All of the hats are interesting, but for the purposes of design critique, the black hat is especially powerful. It’s a quick framework that can put your teammates in a state of mind that enables candid and productive feedback on designs. This is valuable for several reasons:
• People don’t necessarily know how to give critical design feedback. This can be even truer for your non-UX partners. When presented with a set of wireframes, it can often be hard to know where to start in evaluating them. For someone who is unaccustomed to the experience design process, it may be difficult to know if what you’re looking at has issues or not. A Black Hat session gives a group of people permission to call things as they see them, which can release them from any worry about whether their feedback is relevant or even correct. Black Hat sessions provoke honest and constructive conversations.
• Because a Black Hat session is all about pointing out the hard things, it does a few very important things. First, it gives anyone who is unhappy with certain aspects of the design a constructive forum for sharing his concerns and instills confidence that he is being heard. Second, it creates a safe place where people who are less comfortable giving negative feedback can express their concerns as well. Third, it puts all of these data points into a format that you can see, track, manage, and take charge of.
• By running a Black Hat session, you show that you are not protective and defensive about the designs that you are creating, and that you are serious about doing what needs to be done to make a great product. It also shows that you are the driver of a process where designs get better and better through continuous input and iterative improvement. Figure 8.3 shows what a typical Black Hat session looks like.
FIGURE 8.3
A cross-functional team conducting a Black Hat session.
Average Time
30–60 minutes
Use When
• You’re very close to the designs, and you need honest feedback on what’s working and what isn’t.
• You sense that the team is holding back or not fully engaging in design reviews.
• You want to do targeted reviews with subject matter experts (for example, technical feasibility reviews with the engineering team).
Try It Out
1. Make time for a group work session.
Once you have designs in a shareable form, schedule a Black Hat session. Block off an hour on the calendar, find a room or area with large, usable wall space, and assemble a group of people to help you critique the designs. It’s ideal if this group is actually the cross-functional team that works on the product together, but barring that, even a group of friends or uninvolved colleagues should be able to provide feedback on potential stumbling blocks from an end-user perspective.
2. Explain the rules.
With the group assembled, tape to the wall any designs you want to critique. Explain the rules of the Black Hat session. Everyone has one job and one job only: to assume the most critical, judgmental perspective they can muster, and look at the designs from that point of view. Ask participants to write down every problem or issue they see on a sticky note (one issue per sticky note) and place the note on the designs near where they spotted the problem. One easy way to “put on” the b
lack hat is to pretend that you are a grumpy and skeptical user who is short on time and trying to do four different things simultaneously. Or pretend that you’re a tough and very senior leader who will be approving these designs before they are considered final.
3. Start the clock.
Give the group 15 to 20 minutes to walk through all of the designs, reflect on what they notice, and write their sticky notes. You can have participants do this as a silent exercise, or you can invite them to discuss what they’re seeing as a group. You can participate as well, writing your own sticky notes. Either way, make sure that everyone is writing lots of sticky notes. If they seem hesitant, you can give them some guidance as they go. Ask them things like:
• When you look at each screen or step, do you understand its fundamental purpose?
• What jumps out at you? Is it what should jump out at you?
• Do you know what you would click on or touch to advance to the next step?