While the set of ten include some good common sense ones, I particularly liked tip #2 and #3 for their expert knowledge:

Tip 2: Test in a crowded public place. Once you have a handful of screen concepts, you need to get them in front of people. By testing “in the field” you’ll find issues with noise, light and social situations that you wouldn’t otherwise uncover, which can have a big impact on the final design. We’ve had the most success testing in places with good foot traffic such as food courts, malls, cinemas and busy pedestrian streets. Before you begin you may need to ring the venue to find out what their requirements are and to get the proper clearance. For example, Westfield required that we set up a table rather than wander around their mall.

Tip 3: Use chocolate as a lure. We’ve found that a simple, universally loved treat is a good way to encourage people to help out. We generally use large blocks of chocolate, but must admit that testing during Wellington’s first snowfall in 30 years made us think that a hot chocolate voucher would have been smarter.

For the rest of the tips check out the email article. (Note: as far as I know, the monthly newsletters — which usually contain gems like this — are never published on blogs. Sign up on their site.)

[Edit: article is now available on the Optimal Usability blog]

—-
Featured image NC-BY-CC by djlein

In-person user research used to be the only game in town, and as with most industry practices, its procedures were developed, refined, standardized, and then became entrenched in the corporate R&D product development cycle. Practically everything gets tested in a lab, hallway, or conference room nowadays: commercial web sites, professional and consumer software, even video games. But nowadays we’ve got remote usability testing.

This is a revised chapter from Rosenfeld Media's 'Remote Research'

Part of the appeal of formal lab research was that it provided a scientific-seeming basis for making decisions by using observational data, instead of someone’s error-prone gut instincts. Stakeholders appreciated the firm protocol and apparent reliability of properly managed lab research. But for all of us who have sat through formal studies with two-way mirrors, we know that there is a lot of bullshit that goes on—participants pretending to care, moderators pretending to understand, and stakeholders pretending to be open-minded. The appeal of what the kids call “guerilla testing”—informal testing, where you simply grab someone within shouting distance and ask them to use your interface—is clear. It’s easy, fast, and can produce great results. Lots of user research practitioners continue to use in-person methods because it’s what people have been doing for a long time.

There’s nothing specifically wrong with in-person research. But there is that whole Internet thing that’s been happening. It does have some unique properties we can take advantage of to do things that weren’t possible with old-school research. Like these things:

Insane Cost Savings
Usertesting.com is $39 per user. Compare that to flying to Chicago for three days to watch twelve people talk behind a two-way mirror, and that’s thousands of dollars in savings. Rolf Molich has been organizing the Comparative Usability Evaluation study (CUE) for eight years, where different usability methods and teams independently evaluate the same site. He knows something about comparing different research techniques, and makes the point that while there are advantages and disadvantages to a remote method like UserTesting.com, the “price/performance ratio was amazing” (that was before a price increase, but the cost is still quite low). Beyond travel expenses, other costs associated with in-person testing may be reduced or eliminated when you test remotely. Unless you’re doing guerrilla testing. With tools like Silverback, guerrilla in-person methods don’t have to cost much more than remote, but you are usually more limited by the audience. So in terms of cost comparison, let’s just say that remote testing will usually offer a big cost savings.

Time-aware research
Catching people in the middle of a task with a web or software intercept like ethnio (note: this is a product of ourselves) and calling them within a few seconds to share their screen and watch them use a tool remotely on their own timeline. It’s a degree of accuracy that never existed before. You could argue that it’s ethnographic in a way that is not possible with physical observation, but you could also spend your whole life arguing about that. Let’s not. Tools like Revelation and the Track Your Happiness project at Harvard use native timelines to gain insight. That’s a really big deal.

By now UX researchers are familiar with the importance of understanding the usage context of an interface—the physical environment where people are normally using an interface. Remote research opens the door to conducting research that also happens at the moment in people’s real lives when they’re performing a task of interest. This is possible because of live recruiting (the subject of Chapter 3 of the book), a method that allows you to instantly recruit people who are right in the middle of performing the task you’re interested in, using anything from the Web to text messages. Time-awareness in research makes all the difference in user motivation: it means that users are personally invested in what they’re doing because they’re doing it for their own reasons, not because you’re directing them to; they would have done it whether or not they were in your study.

Consider the difference between these two scenarios:

1. You’ve been recruited for some sort of computer study. The moderator shows you this online map Web app you’ve never heard of and asks you to use it to find some random place you’ve never heard of. This task is a little tricky, but since you’re sitting in this quiet lab and focusing—and you can’t collect your incentive check and leave until you finish—you figure it out eventually. Not so bad.
2. You’ve been planning a family vacation for months, but you’ve been busy at work so you procrastinated a bit on the planning, and now it’s the morning of the trip and you’re trying to quickly print out directions between finishing your packing and getting your kids packed. Your coworker told you about this MapTool Web site you’ve never used before, so you decide to give it a shot, and it’s not so bad—that is, until you get stuck because you can’t find the freaking button to print out the directions, and you’re supposed to leave in an hour, but you can’t until you print these damn directions, but your kids are jumping up and down on their suitcases and asking you where everything is. Why can’t they just make this stupid crap easy to use? Isn’t it obvious what’s wrong with it? Haven’t they ever seen a real person use it before?

Circumstances matter a lot in user research, and someone who’s using an interface in real life, for real purposes, is going to behave a lot differently—and give more accurate feedback—than someone who’s just being told to accomplish some little task to be able to collect an incentive check. Time-awareness is an important concept, so we’ll bring it up again throughout this book to demonstrate how the concept relates to different aspects of the remote research process (recruiting, moderating, and so on).

Circumstances matter a lot in user research, and someone who’s using an interface in real life, for real purposes, is going to behave a lot differently—and give more accurate feedback—than someone who’s just being told to accomplish some little task to be able to collect an incentive check.

Technological ecosystem
Some interfaces just don’t make any sense to test outside their intended usage environment. If you need the users to have their own photos and videos to use in a video editing tool, having them bring their laptop or media to a lab is an amazing hassle. Or, let’s say you’re testing a recipe Web site that guides users step-by-step through preparing a meal; it wouldn’t make much sense to take people out of their kitchen, where they’re unable to perform the task of interest. When this is the case, remote research is usually the most practical solution, unless the users also lack the necessary equipment. We also call this the participant’s “technological ecosystem” because it implies that their devices and computing environment have an impact on how they interact.

Democratization of user testing
That’s right, I said it. Democracy. As in, anyone in the world no matter how far removed from their potential audience can conduct user testing with less obstacles than before. After ten years of user research, 260 studies, and 3,000 participants at bolt | peters, we’ve noticed a trend lately that more people are doing their own research than ever before. And it’s great. There’s no reason to hire a specialist to observe real-world technology behavior. And that’s coming from a specialist.

Geographic Diversity
Even if you do have a lab, the users you want to talk to may not be able to get to it. This is actually the most common scenario: your interface, like most, is designed to be accessed and used all around the world, and you want to talk to users from around the world to get a range of perspectives. Will Chinese players like my video game? Is my online map widget intuitive even for users outside Silicon Valley? Big companies like Nokia and Microsoft are often able to conduct huge, ambitious research projects to address these questions, coordinating research projects in different labs around the world, flying researchers around in first class. If you don’t have the cash for an international longitudinal Gorillas-in-the-Mist project, then remote research is a no-brainer solution. If you can’t get to where your users are, test them remotely.

And Why Not?

Both in-person and remote UX research share the same broad purpose: to understand how people interact and behave with the interface you’ve made. There’s no need to set up a false opposition between the two approaches—one isn’t inherently better than the other. Despite the versatility of remote research, there are lots of reasons you might want to conduct an in-person study instead, most of which have to do with timing, security, equipment, or the type of interaction you want to have with participants.

Both in-person and remote UX research share the same broad purpose: to understand how people interact and behave with the interface you’ve made. There’s no need to set up a false opposition between the two approaches—one isn’t inherently better than the other.

Security
Security is often a concern for institutions like banks and hospitals, which deal in sensitive information, or companies concerned with guarding certain types of intellectual property. If you’re testing a top-secret prototype, you obviously don’t want to let people access something from their home computer, where it could be saved or screen-captured. On the other hand, you might also be doing a study on users who would be secretive about sharing what’s on their screen—government employees, doctors, or lab technicians, for instance. Either way, you’ll want to test users in a controlled lab environment to keep things confidential, especially if what you’re testing is so hush-hush that you’ve got to have your users sign a nondisclosure form.

Inability to use screen-sharing
You might also want to use a lab if your users are unable to share their screen over the Internet, for whatever reason. Some studies (of rural users, cybercafe patrons, etc.) may require you to talk to users who don’t have reliable high-speed Internet connections, who own computers too slow or unstable to use screen sharing services effectively, or who have operating systems incompatible with the screen sharing tools you’re using. These restrictions only apply to moderated studies, for which you need to see what’s on your users’ screens.

The need for special equipment
Depending on the interface you’re testing, you may require certain special software or physical equipment to run the study properly; this is most often the case with software that’s still under development. Getting users to install and configure tools to run elaborate software can be a pain (though that’s not unheard of), and requiring users to have certain equipment can make recruiting needlessly difficult.

The importance of seeing the user’s body
Some kinds of research will require you to study certain things about the user that are difficult to gather remotely. UX research has recently begun using eye-tracking studies, and for that kind of study, you’d need to bring the users to the eye-tracking device. Other studies might require you to attend to the participants’ physical movements, which may be difficult to capture with a stationary webcam.

Conclusion

You don’t necessarily have to choose between lab and remote methods. You can even conduct multiple studies on the same interface, using the findings from one study to add nuance to another. Probably excessive for the average study, but for really large-scale projects where you just want to gather every bit of information you can (a new version of a complex software program, an overhauled IA, etc.), being comprehensive can’t hurt.

You should have a good idea of whether or not remote research suits you. Give it a try—if it’s not your thing, you can always go back to lab testing. We won’t tell anyone.

The conclusion of the Nielsen Norman Group’s April 2010 study of iPad usability is that it has problems and more standards are the solution. Yes, the iPad is imperfect, but resorting to standards as the solution is an antiquated reaction that fails to consider how interactive systems have evolved. We’re not Usability Engineers anymore (not most of us, anyway); we’re User Experience Designers. Experience is more than just usability.

I’ve covered this ground on Johnny Holland before. Just after I got my iPhone I came to many of the same conclusions Nielsen did about the how the iPhone is difficult to learn. But here’s the thing; I didn’t stop there. I talked about how some of the factors that made the iPhone difficult to use also made it fun to use, which is why it has flown off shelves since it was introduced. As I got used to it I began to think more about how playfulness was more delightful than pure usability in some contexts and vice versa. Something I use occasionally for very specific tasks delights me if it is simple and usable. But something I use often or for more amorphous tasks that is simply usable will either provoke no emotional response or, at worst, will become tedious. In that context, a more playful interaction style will keep me engaged and might even lift my mood a little.

This is the perspective from which I’ll look at what Nielsen found, identify where it’s valuable, and point out where it’s a little myopic.

“Wacky Interfaces”

Wacky. Yes, “wacky.” As in, “Isn’t it cute how kids these days are trying to create beautiful experiences.” Beauty does not require an unusable interface, but a beautiful experience might ask you to engage with it a little more deeply through a lack of obvious affordances.

For more than a decade, when we ask users for their first impression of (desktop) websites, the most frequently-used word has been “busy.” In contrast, the first impression of many iPad apps is “beautiful.” The change to a more soothing user experience is certainly welcome, especially for a device that may turn out to be more of a leisure computer than a business computer. Still, beauty shouldn’t come at the cost of being able to actually use the apps to derive real benefits from their features and content.

He almost gets it. No, the iPad is no business computer, and that’s exactly why beauty is an asset. People will, much of the time, interact with this device in order to have an experience rather than complete a task. Nielsen’s wholesale discounting of beauty fails to take into account that some apps will be experiential and content based while some will be functional and task based. Engaging with a system is not what people want to do when they have a task to complete. That’s when basic usability is more delightful.

Long-standing GUI design guidelines for desktop user designs dictate that buttons look raised (and thus pressable) and that scrollbars and other interactive elements are visually distinct from the content.

The iPad does not have a Graphical User Interface but a gestural one. GUI design guidelines do not necessarily apply when users can interact directly with the content.

For the last 15 years of Web usability research, the main problems have been that users don’t know where to go or which option to choose — not that they don’t even know which options exist. With iPad UIs, we’re back to this square one.

The iPad is also not the Web. Interacting with apps is completely different from interacting with websites. Most apps have far fewer options than the average website, lessening the potential for confusion. On top of that, people use apps in a much more focused way than they use a website. Users can access the entire Web when they open their browser, but when they open an app they choose to focus on that app’s content and functionality only. In that context, a more deeply engaging, exploratory design can enhance the user’s experience.

“Inconsistent Interaction Design”

I take issue with this finding because Nielsen evaluated multiple applications. That’s like saying it’s bad that Microsoft Word and Adobe Photoshop are inconsistent. They allow completely different audiences to accomplish completely different tasks. He considers it confusing that the same gesture affects the same type of content differently in different apps. When there’s a limited gestural vocabulary (and there has to be) and a diversity of contexts, it’s easy and usually risk-free to experiment with figuring out the correct gesture if you get it wrong the first time. And because it’s gestural, it’s inherently playful and fun. It’s not a chore like trying to parse Word’s menus or toolbars.

Nielsen says that iPad UIs suffer from the “triple threat” of low discoverability (non-obvious controls), low memorability (difficult to remember inconsistently applied gestures), and accidental activation. I agree with the first and the last, mostly. Non-obvious controls can encourage exploration and playfulness in some contexts, but they can be frustrating in others. Accidental activation is certainly annoying, but it’s usually easy to deactivate whatever was activated. That problem in particular I think is due to the absolute newness of the apps and the platform. At least two iPad developers I’ve heard from indicated that they changed the design of their apps once the iPad was released.

The second problem he identifies, low memorability, I completely disagree with. My pre-literate two-year-old daughter knows how to unlock my iPhone & iPad, navigate to her favorite drawing app, launch it, draw with it, and change the various options. It took very few demonstrations before she learned this. If you look on YouTube there are videos of small children expertly navigating iPhones and iPads. You show them how to do it once, they do it, and they remember it.

The link between physical motion and cognitive development (especially in children) is well established in cognitive research, making gestural UIs much more easy to remember than your typical desktop GUI. On top of that, the number of gestures that are possible is pretty limited. Even if you don’t perform the correct gesture first, it won’t take long to figure out what the right one is.

“Crushing Print Metaphor”

Nielsen again complains that iPad apps are not like the Web.

The current design strategy of iPad apps definitely aims to create more immersive experiences, in the hope of inspiring deeper attachments to individual information sources. This cuts against the lesson of the Web, where diversity is strength and no site can hope to capture users’ sole attention.

My friend Pete Barry likes to talk about the value of experience. The reason people choose to consume content through these “limited” apps is because the experience they provide is valuable to them in some way. That experience is a benefit rather than a drawback. Besides, the open Web is just two taps away.

“Card Sharks vs. Holy Scrollers”

Nielsen references Jef Raskin’s differentiation between “two fundamentally different hypertext models,” Cards and Scrolls, indicating that iPad apps mostly fall into the Card model. On a Card, all the interaction occurs on a fixed size canvas that is swapped out to provide access to more content or functionality. And I’m sure I don’t have to tell you what a Scroll is.

Nielsen said:

There’s no real reason we can’t have both design models: cards on the iPad and scrolls on the desktop (and phones somewhere in the middle). But it’s also possible that we’ll see more convergence and that the Web’s interaction style will prove so powerful that users will demand it on the iPad as well.

If I read that right, I actually agree with him. The iPad doesn’t have to force all apps to subscribe to one model; each app can use whichever model is most appropriate for its context of use. I’ve even seen some apps that mix the models, like Early Edition. This newsreader arranges RSS feed articles like a newspaper, with a home page and different pages for each individual feed. Wherever an article appears on any of these pages, you can actually scroll in place to get a sense of what it’s about! Granted, this is something users are likely to discover accidentally, but it’s a pleasing, delightful interaction nonetheless.

Nielsen’s Recommendations

This is what really gets me going. And not in a good way. He has four, but they really roll up into three:

• Make iPad UIs look more like GUIs
• Make iPad interaction design more like the Web
• “Abandon the hope of value-add through weirdness.”

And yes, that third is a direct quote. In 2010. Beauty isn’t weird. Compelling interactions aren’t weird. Both of these are critical components of modern interaction design, where designers seek to go beyond simple usability and create positive emotional experiences that build loyalty and emotional attachment. What is perhaps most confusing about these recommendations, though, are the first two. Jakob Nielsen is a smart guy, and clearly the iPad exists within entirely different contexts of use than a desktop GUI or a website.

What I really want to know is this: why does Nielsen feel that iPad apps should be designed for contexts they won’t be used in?

—–

Header image by nDevil /CC 2.0

I love the TV show Myth Busters because it challenges what I think is true. In the show, popularly held myths are tested in an entertaining and somewhat scientific way. My favorite part of the show, other than the explosions of course, is when my beliefs turn out not to be true. This always keeps me open minded, and focused on reality. I also enjoy being on the other end – exposing myths as unfounded. This is the perspective I am taking for this article. Specifically, I will be highlighting five common myths related to online (unmoderated) usability testing, and explaining why I think these myths are not true.

The motivation for this article is to help UX researchers keep an open mind about online usability testing. There are some researchers who have been using this approach for years and find it useful (in certain situations). Others are new to it, and wanting to learn more about its strength and limitations. Finally, some UX researchers have already formed an opinion about online usability testing, and deemed it not useful for a variety of (unfounded) reasons. I hope by exposing these myths, we (as a UX community) can evaluate this tool based on its actual merits.

1.    There is too much noise in the data to be trustworthy

Perhaps the most common myth about online usability testing is that the data are not very reliable. Some people will say that the participants don’t try very hard, get distracted in the middle of the study, go through the study as fast as they can to get the incentive, or even misrepresent themselves to qualify for the study (in order to get the incentive). This is certainly true, and generally occurs in 5% – 10% of all cases. But, there is good news!

There are some very useful techniques to clean up the data. Identifying (and removing) “mental cheaters” is not very hard. These folks behave in highly predictable ways. “Flat lining” is when someone answers all 1’s or 5’s on a 5-point rating scale.  “Speed traps” are one way to identify these folks (see question 6 in the figure below) by checking to make sure they are actually reading each question. Consistency checks can be used by re-wording questions, and analyzing the consistency of responses. Removing unrealistic task times is also very easy to do, and can help deal with the participants who went home for the weekend in the middle of a task. Also, screening questions can be written to minimize the number of fraudulent participants (those that misrepresent themselves) who take part in the study.

Bottom line, the data from an online usability test can be just as reliable as a traditional lab test. The only difference is that a little cleaning up needs to happen before jumping into the analysis phase.

2.    You can only collect quantitative data

I am always surprised when people tell me that online usability testing is only useful for collecting basic metrics such as task success, completion times, or satisfaction. For some reason, people assume that just because you have a large sample size, you can only collect quantitative data. Online usability studies just don’t make sense if you want to collect qualitative data about the user experience. This cannot be farther from the truth.

One of the beauties of online usability testing is that the researchers can collect a rich set of both quantitative and qualitative data about the overall user experience. For example, if a user has difficulty with a specific task, they can provide comments as to why they had difficulty with that task, or what they were expecting to happen at different points along a transaction. Qualitative data, usually in the form of verbatim comments, can be collected at any point in their experience. The user can even be prompted to provide verbatim comments when they exhibit certain behavior, such as abandoning a transaction or deviating away a desired navigational behavior.

Verbatim comments are not only easy to collect, but they are becoming much easier to analyze. There are many tools available now to pick out patterns in verbatim responses. Word clouds (see below) are one example to way to get a quick sense of the key patterns in verbatim responses.

3.    Online usability testing does not work well during the design phase

Most people think of running an online usability study only after the product has been built. It only makes sense to run an online usability study as part of a summative evaluation, and doesn’t really fit in during the actual design phase. Online usability testing can’t inform the design, takes too much time, or is too expensive to conduct during the design phase. These are all untrue.

Online usability studies can be set up within a few hours, and data collected in a matter of hours. We have set up, launched, and analyzed data from an online study within the same day. Not only can a study be set up quickly, but it can help answer questions that typically come up in the design phase. For example, if there is a question about preferences around navigation method, labeling, or look and feel. These and many other design preference questions cannot be reliably answered with a small sample size. Sometimes, we need to gather data quickly from hundreds or thousands of users in order to validate significant design decisions.

4.    It only works with websites

One of the things that researchers quickly point out is that online usability testing can only be used for evaluating websites. It simply doesn’t work for software, voice response systems, mobile, consumer electronics, and toaster ovens. While a vast majority of online usability testing does focus on websites, it doesn’t have to.

Over the years, we have used an online usability testing approach to evaluate non-web interfaces. Conceptually, it is still the same method. The participant is asked some questions, given some tasks, and provides feedback about their actual experience. The only real difference is that the participant’s behavior is not being tracked. But, a lot of useful data can be collected about their experience, such as whether they were successful in completing their tasks, how long it took them, what they felt about their experience, and where they had difficulty. So, even though you might be giving up a little behavioral data, there is still a lot to be learned about their experience.

5.    Online usability testing costs too much

Some people say that they would love to do more online usability testing but it is simply too expensive to use on a regular basis. It certainly can be pricy, but fortunately, in the last few years there are a variety of tools that allow you to run online usability studies for not a lot of money. There are various self-service providers to allow you to set up and run your own online usability study. You only need to pay to access their technology. Visit www.measuringux.com to see a complete listing of vendors.

If budgets are really tight, there is a way to run your own “discounted” flavor of an online usability testing for free, or practically free. By taking advantage of some online survey tools (such as Survey Gizmo or SurveyMonkey), and a little html and java script, you can literally create your own online usability study for close to free (see the figure below as an example of the “homegrown” approach). While you will give up a little data and functionality, it can be useful in those situations when you have no budget to run an online usability study. Visit www.measuringux.com to see more details about how to create a discounted online usability study.

Try it for yourself

I may or may not have convinced you that these myths are untrue. Regardless, I would encourage you to consider online usability testing as part of your user experience design and research efforts. In doing so, you will discover its’ strengths and limitations. After all, every user research method has its own strengths and limitations. Online usability testing is no exception.

Editorial note: Interested in learning more about this subject? Bill recently co-authored Beyond the Usability Lab: Conducting Large-Scale Online User Experience Studies.

Top image: Brad Montgomery / cc

A few months ago we set up five Flickr groups around several UX topics. Every month we will try and make some sense of the uploaded material. This month we selected the UX Errors group and will look at examples of issues that arise when proper attention isn’t paid to two very important components of successful user interface design: Perceived Affordances and Designing for Task Flow.

Perceived Affordances

In The Design of Everyday Things Don Norman introduced many designers to the concept of affordances, which he would later clarify as “perceived affordances”, or the actions the user perceives as being possible based on how an object is presented. For example, if your design includes a “button” make that button look pushable.

Posted by Adam Connor

Push me. Wait… you can’t

The ATM example suffers from some misrepresentation. The labels for the physical buttons are styled with bevels, commonly used to represent buttons in GUIs. As a result, many users try to press them, only to realize after a few attempts that the buttons are actually to the right and left of each label. In this case, objects give off an inaccurate perceived affordance.

It’s not uncommon for ATMs to have physical buttons and digital label displays. In this situation, it looks like someone thought that adding a little visual “excitement” to the labels would be an improvement. If simple, plain text labels had been used, people would most likely have experienced less confusion.

Posted by Olivier Lorrain

Where’s the Button?

In the gas pump example people tended to press the octane number, as evidenced by the fingerprints around the “87″, when choosing a fuel. This happened despite the “Push to start” label on the actual button and the arrows pointing to them. In this case, there isn’t enough emphasis given to the real button in comparison to the large yellow square label. Which begs the question, why not just make the yellow square the button to begin with?

Posted by Andreas Popp

Which way is up?

In our last perceived affordances example, we have three components, all with a triangle/arrow pointing up, all beveled from the panel on which they are presented. Which one do you push to direct the elevator up?

The two arrows on the top are lights, which indicate the direction the elevator is traveling, while the lower button is the actual call button. Many users pressed the lights in order to call the elevator. Why? Most likely because the bevel caused people to perceive them as buttons. Also, the lights have a higher visual significance than the smaller triangle on the actual button. Had there simply been no bevel around the two lights, it’s likely there would be less confusion and more people would find the real button first. That’s not to say that the button itself couldn’t use a bit more visual prominence in it’s display too.

Designing for Task Flow

When I was in grade school there was an exercise we did where each student had to write instructions on how to construct a peanut butter and jelly sandwich. The teacher then attempted to construct the sandwich according to those instructions verbatim. If an instruction left something out, small details like removing a slice of bread from the bag containing the loaf, the teacher would stand there and act stumped until the student modified their instructions to be more specific.

The purpose of the exercise was to give students an appreciation of the fact that even simple tasks are comprised of a multitude of steps, and that finding the right level of detail and sequencing for those steps is critical to user’s success and satisfaction.

Posted by Eugenia Ortiz

Follow the Arrows

In the example to the right, there appears to be some attempt at sequencing in the digital display as well as from the large “2″ at the bottom of the device. In this case however, some considerate and/or frustrated individual(s) has taken it upon themselves to try to make up for the devices inadequacies by adding additional instructions and labels.

Posted by Frank Farm

Easy as 1, 2, 3

Our second example also uses numbers, in addition to a list of instructions, to provide guidance. Yet the arrangement of components and labels gives a perception of chaos that even a well written set of instructions can’t overcome.

Both of these interfaces exemplify that in user interface design, identifying a sequence of actions is not enough. Numbers and lists, while somewhat helpful, should be used in conjunction with a logical and sequential arrangement of controls and inputs.

Johnny Holland’s Flickr Groups

Observations are a critical tool in any designer’s tool set. They provide us with in-site on things we should do, shouldn’t do and could do better. Many of us photograph our observations to preserve them, to keep them as reminders, learning tools that won’t be lost in the background when our next big breakthrough comes along. We also share our observations so that we can learn from and educate others. So that we can build a stronger dialog and further conversation.

To that extent, Johnny Holland has established five Flickr groups, so that we can share, discuss and learn from eachother’s observations.

In addition to the UX Errors group, where we collect examples of design decisions that have a negative impact on individual’s interactions with a product and overall user experience, and from which this month’s examples were taken, we have:

• Daily UX: collecting pictures of everyday user experiences, good or bad.
• UX Sketches: collecting sketches of products, interfaces and ideas
• UX Patterns: collecting examples of interface and interaction patterns.
• UX Events: collecting photos from UX conferences and meet-ups around the world.

Like any collaborative effort, these groups are what we make of them. So please join, share your photos, comment and discuss. And if you have any ideas on how we can improve the groups or better utilize them, please let us know.

Style guides are a great way to ensure user experience consistency when developing an application and a way to communicate user experience standards across an organization. They can be application specific, platform specific, and may encompass enterprise-wide standards. A style guide can help make the development of user interfaces more efficient and help ensure good user interface design practices.

Types of Style Guides

Style guides for applications usually contain specific instructions on how to design and develop an application’s UI. In some instances, code snippets may also be provided to simplify development of the application.

Example of an application style guide specifying a web page template grid

Enterprise-wide style guides may include standards specific to an organization. These style guides may overlap with company branding style guides that are often defined by marketing departments. They can outline a variety of company-wide items such as standard colors, typography, logos and language.

Example of branding color definitions found in a corporate style guide

Platform specific guidelines are often tailored to a specific platform, such as desktop, web, or mobile. These style guides often give particular guidance on how to design for that platform, such as control and content guidelines.

Example of a link control definitions in a website style guide

The style guide you choose to create can be any combination of these three types. It’s up to you to figure out what makes the most sense for you.

Style Guides Are Not UI Specifications

Style guides are different from user interface specifications:

• A specification document details the functionality of a UI design for developers building an application. It is usually more descriptive and is often accompanied by wireframes that act as blueprints for the design. In contrast, a style guide is often a general outline of the elements of a UI design.
• Style guides have a longer shelf-life than specifications documents that are often tied to a project life-cycle. When an application is first created, some elements of the initial specification document might turn into the application style guide for long-term reference.
• Elements of a style guide may be referred to from a specification. For example, the functionality of a web application enhancement would be captured in a specifications document; but the operation of standard UI controls found throughout the website would be outlined in the website style guide and referred to by the specifications document.

How to be Successful

Over the years, I have had a chance to create a variety of style guides. The format and purpose of these style guides were variable and were suited to the task at hand: such as details of the grid layout, colors and typography used in a website and a general guidebook providing guidance on the use of website user interface controls and how to write web-based content. From these experiences, I’ve learned a lot about what makes a style guide a success and I’d like to share some of these tips with you.

1. Keep the audience in mind

Style guides can be written for numerous audiences (e.g. other user experience practitioners, developers, graphic designers, business analysts, etc.) and the content should be structured to match the audience. Graphic designers would benefit from knowing the colors used in a website elements and programmers may desire knowing the code used to create a control.

2. Plan for success

When planning a style guide, seriously consider what would make your style guide successful in your organization. Would it be ensuring your company understands how to better design usable applications? Or would it be ensuring the large-scale website you are creating has a consistent user experience? Or would it be something else?

3. Keep it alive

Documents produced in traditional document formats can become stale and quickly become outdated. Successful style guides are produced in a manner that supports easy maintenance and supports a living document.

4. Define a review process

Create a process that supports modification and review of the style guide to actively ensure style guide maintenance and buy-in. You may want to have a person or group of people responsible for periodically updating a style guide.

5. Think of the platform differences

Style guides can be platform specific or neutral. Design guidelines can be different depending on the platform (i.e. Windows vs. Mac, iPhone vs. Blackberry). Consider how you want to support communicating any platform differences when creating your style guide.

6. Socialize the document in your organization

The use of your style guide should be communicated throughout all levels of your organization to ensure everyone knows the existence of the guide, understands how to use the guide, and actively works to use and maintain the guide. The more people about your style guide, the more successful you and your style guide will be.

7. Clearly define mandatory and flexible standards

User interface design is part art and part science and user interface paradigms shift quickly. Ensure that your style guides support new platforms and creative ideas by specifying what standards are mandatory and what are flexible. For example, you may want to ensure certain usability rules are strictly adhered to throughout your applications (i.e. “Sans serif fonts must be used for text that will be read on a screen”), but be more flexible in other areas (i.e. “Radio buttons should be used when a user is asked to select one item from a list of items.”)

8. Make the style guide as scannable and searchable as possible

Style guides can be very dense and contain a lot of detailed information. Search and browsing capabilities will make it easier for people to find what they are looking for in your style guide. In addition, use as many visual examples as possible to support quick scanning of style guide elements.

9. Provide real world examples

Successful styles guides often show one or more examples from real applications for illustration. If you are writing a style guide for a specific application, use examples from that application to demonstrate your point. If you are writing a style guide for a large organization with many applications, ensure that your examples encompass all of the applications you are describing.

I hope you find these tips helpful when you are creating your own style guides. Do you have any additional tips you would like to share?

—–
Header image by nathanborror / /CC by 2.0

On physicalinterface.com there is an interesting article about the designproces of the new user interface for the Wells Fargo ATMs. These new designs make use of a touchscreen. An important improvement is the clear and fresh interface, and how the information is structured within the screens. It’s a combination of good information architecture and simple but clean design.To achieve this the designer and information architect had to work closely together to come up with a visual language which should not only be clear and informative, but should also feel very friendly.

Weither they fully succeeded in accomplishing their goals within this design, that is something which can be questioned. Especially when you start looking at the context in which these machines are used. As you already might have noticed from the image left, these ATMs have a lot of functionality. Next to checking your balance and and withdrawing cash you can make transfers, deposit money (also in the form of checks), buy stamps and even customize the user interface.

Now imagine an ATM like this in a big bank in the centre of Amsterdam or London where even now there’s almost always a queue of at least 3 people. Research of the designers of these ATMs has shown that the most common functions are checking your balance and withdrawing cash (which take a relatively short amount of time compaired to the other available functions). They also mentioned that the reason why other functions are used less, is because users are less comfortable with them. So they focussed on this in their designprocess.

So if they succeeded in letting the user feel more comfortable in using all of the functionality, this might result in a longer average time which users spend operating the ATM. As a consequence it’s most likely that there will be longer queues in front of the machine. Maybe splitting up functionality amongst different machines?

We all know the feeling. You’re trying to install an application or scan in a picture and slow but steady the progress-bar keeps progressing… and then the moment of truth arrives. The bar approaches 99% and suddenly time seems to stop. Time after time you’ll end up frustrated. Well now they may have find a solution to that.

A few people from the Carnegie Mellon University have done some research on the effect of the progress-bar. The results can be found in this relatively short and easy to read paper. For people who don’t have the time to read 4 pages, here is a short summary

The proces
The researchers came up with nine functions to monitor the progress:

• Linear (constant progression)
• Early pause (almost linear, very slow around 25%)
• Late pause (almost linear, very slow around 75%)
• Slow wavy (three big steps separated by pauses)
• Fast wavy (increments in small, quick steps)
• Power (accelerates)
• Inverse power (decelerates)
• Fast power (rapidly accelerates)
• Inverse fast power (rapidly decelerates)

They animated every progression in the form of a real progress-bar which they then used for testing. In total around 22 people have tested all the progressions. They where shown two bars at the same time and then had to pick the one which appeared to be progressing the fasted. (they all took 5.5 seconds). They results of this where processed and conclusions where drawn.

Conclusions
The nine functions can be divided into three groups. Three functions where perceived to progress slower than linear, which are: late pause, slow wavy and fast wavy. Inverse fast power, inverse power, early pause and linear where perceived as ‘normal’ progression. Power and fast power where perceived as being the fastest.

The researchers had some interesting findings, these are the two most important ones: Participants perceive progression with pauses slower than linear progression. Progressions which accelerate are perceived as being the fastest.

They do add that a system which has a stable progression should also show a linear progress-bar. However it’s very interesting for systems to fake accelerating progression to improve the user experience. When the progression can’t be monitored accurately, then a progress-bar often isn’t the best choice. In that case you’re better of using a repetitive animation. In this case a proper maximum speed should be defined else it might result in a nauseating experience.

Three weeks ago I attended a usability test at a big Dutch museum, testing a new mobile application we developed. The company performing the test needed three people for guidance. One person was guiding and doing the interviews. Another carried a complex construction, with a Macbook Pro on top, to observe and collect data throughout the museum. And the last person was just needed for making video footage. It was complex and caused a lot of attention in the museum.

This is propably one of many examples which shows that mobile usability testing is still very unpractical. And since mobility is getting more important it’s good to look for solutions. And today one such solution happened to pass through my mailbox: the FieldCREW.

Since some time a design team at Bresslergroup has been working on ‘a concept user research technology platform,’ the FieldCREW. It is a tablet computer with several wireless data gathering components for the collection of data. This unit is primarily focused ‘at improving data collection efficiency [in] multi-dimensional work situations such as surgery in an operating room.’ But when you look at the specs it’s also really interesting for usability testing mobile applications with users.

It consists of the following hardware:

• Tablet with touchscreen and integrated video camera
• Remotely controlled wireless video cameras
• Handheld wireless taggers to tag key events for later review
• Subvocalization sensor to silently dictate notes

‘The tablet manages and receives data from these wireless components and provides features including:

• Video notation (i.e. telestrator) for annotation of events as they happen
• Speech-to-text translation of recorded audio (and subvocalizations)
• Access to stored and online project and research reference materials
• Built-in storage and recharging for wireless components
• Synchronization of all input sources (video, tagging, notes) for streamlined analysis’

With this tablet and wireless components a researcher could easily control a user test. In case of the usability test in the museum (at the beginning of the article) we could have used one less researcher. But besides a lower budget there is another even bigger advantage… this unit looks a lot subtler then a Macbook Pro on a construction and an extra camera. Which is really positive, since it doesn’t claim attention and provides for a more realistic situation.

I have to say the graphical user interface looks a bit complex, but it appears to be based on a situation with a lot of external components. I personally would prefer a user interface where my actions are minimal, the content is focussed and my attention can remain on the real situation. But of course it’s still a prototype.

This project is really interesting. It’s good to see people are thinking of solutions to improve the collection of data in order to improve interactions in their natural environment.

Thanks to the IxDA mailinglist for the tip