Compete on Usability

Six techniques to fight addictive multitasking

The most important career skill -- possibly even the most important life skill -- of the new decade will be successfully managing distractions to get important stuff done.

If you think you're a great multitasker, you're wrong. For example, people's performance and safety drops while talking on cell phones, as if they were drunk. It's well known that using a mobile while driving is unsafe, but here's the key issue that much conventional wisdom on this topic misses: it's not about being hands-free. Multiple studies have shown, whether hands-free or not, the attention we spend on talking on the phone comes at the expense of safety. The effect includes tunnel vision and slowed reaction times.

Meanwhile email, instant messaging, meetings and voicemail are embedded into workplaces. New forms of communication, social networking, games, and mobile apps arrive constantly. It's up to you to police your time; no software will do this for you, and most employers take time management skills for granted.

Here are some techniques to minimize the deleterious effects of task switching:

1. Prioritize and work in sequence.  Whenever you can, attack your tasks in priority order, one at a time. You might have more control over this than you think.

2. Block out specific times to work on specific tasks. Studies suggest that people are most productive when they switch tasks on a schedule, rather than based on when one's email pings.

3. When you're interrupted, make a mental bookmark. Take a moment to jot a note, or just repeat to yourself where you were, before you answer the phone.

4. Change your setting when you need to focus. This is one of my favorite techniques. Most offices have a free conference room, lounge chairs, or other area where you can hide from your phone, turn off your IM client, and get some work done.

5. Ask about interruptions when interviewing for a job. Hiring managers can ask "How do you deal with interruptions at work when you need to get the job done?" or "How do you work when you need to juggle multiple projects that demand your attention?" If you're interviewing, ask about hot-button topics like putting out fires, or what communications technologies coworkers use.

6. Unplug regularly. Make reflective time for yourself at least a few times a week, when you turn off your smartphone and walk away from Twitter. Give yourself a chance to actually think about your projects and priorities, instead of reading and reacting 24/7.

Help wanted ... with your careers page

In searching for a new job recently, I've seen many companies disregard the users of their career website pages. Most clutter this section of their websites with mission and branding statements, meaningless photos of smug professional people, even slick video animations.

None of this matters to job applicants unless they know the company has a job opening for them. So why do so many companies put it first?

Qualcomm's careers page is typical of the user-unfriendly breed. Primary billing is reserved for a Flash animated tag cloud of corporate buzzwords, and promotions for the company's presence on Twitter and Facebook capture the rest of the content area. The tasks users actually come here to do -- look for job openings -- are squeezed into terse links at the left.

Another frustration arises when a careers page doesn't have a job search field, instead requiring users to select a hierarchy of the company's internal divisions. To outsiders, however, corporate business group names are cryptic and ambiguous. If I'm seeking experience designer openings, do I look under Consulting? Marketing and Communications? Technology Solutions Group?  These are real categories at EMC. Fortunately, EMC allows keyword search without selecting a business group first.

The Staples.com careers page does a much better job for me. Under the huge branding area, the page fits in two key calls to action. One is vaguely titled Own Your Own Success, but the other, Search Jobs, couldn't be clearer. I'd be happier if the page didn't play audio automatically, but you can't have everything!

Customer experience in healthcare: follow the money

Driven by the U.S. economic stimulus package, which earmarked billions of dollars to upgrade the nation's health information technology, user experience is in vogue across the American health industry.

I saw the results of this at the 2010 Boston Mini-UPA conference last week. Five of the speaker topics referenced healthcare. One session gave an overview of testing medical devices for FDA validation, and the other speakers talked about healthcare in the context of patient websites, pharmaceutical branding, mobile design, and general tips on what makes the domain unique.

When practitioners follow the money, they must be prepared for the special challenges in this field. Bureaucracy, paper records, and heavy regulation drastically slow the pace of healthcare innovation. I'm reminded of this every time I visit my doctor's small practice, composed of two full-time paper pushers, one nurse, and one physician.  Shelves sag under dusty files, and every year I have to fill out and sign the same paper forms.

Still, healthcare IT change is happening. My doctor now brings a laptop into the exam room and transmits prescriptions directly to the pharmacy. Now a chicken-scratched paper prescription cannot be misinterpreted at the pharmacy!

At the conference I found privacy and openness conflicts remain a huge source of tension in healthcare user experience. UX designer Kate Brigham presented the website patientslikeme.com, which makes all its user information public. During Q&A, followup questions about privacy showed attendees didn't quite grok this bold approach.

It reminded me of doubt about ecommerce safety ten to fifteen years ago, or distrust of ATM's even more years past. In both cases, careful customer experience research and design helped overcome reservations about a newer, more efficient way to accomplish things. Contrast the antiquated experience at many doctor's offices with the slick, computerized process at CVS MinuteClinics, where people browse appointments and services on a kiosk and a large display shows who's next. Healthcare is not immune to competition on usability.

Customer experience in healthcare: follow the money

Driven by the U.S. economic stimulus package, which earmarked billions of dollars to upgrade the nation's health information technology, user experience is in vogue across the American health industry.

I saw the results of this at the 2010 Boston Mini-UPA conference last week. Five of the speaker topics referenced healthcare. One session gave an overview of testing medical devices for FDA validation, and the other speakers talked about healthcare in the context of patient websites, pharmaceutical branding, mobile design, and general tips on what makes the domain unique.

When practitioners follow the money, they must be prepared for the special challenges in this field. Bureaucracy, paper records, and heavy regulation drastically slow the pace of healthcare innovation. I'm reminded of this every time I visit my doctor's small practice, composed of two full-time paper pushers, one nurse, and one physician.  Shelves sag under dusty files, and every year I have to fill out and sign the same paper forms.

Still, healthcare IT change is happening. My doctor now brings a laptop into the exam room and transmits prescriptions directly to the pharmacy. Now a chicken-scratched paper prescription cannot be misinterpreted at the pharmacy!

At the conference I found privacy and openness conflicts remain a huge source of tension in healthcare user experience. UX designer Kate Brigham presented the website patientslikeme.com, which makes all its user information public. During Q&A, followup questions about privacy showed attendees didn't quite grok this bold approach.

It reminded me of doubt about ecommerce safety ten to fifteen years ago, or distrust of ATM's even more years past. In both cases, careful customer experience research and design helped overcome reservations about a newer, more efficient way to accomplish things. Contrast the antiquated experience at many doctor's offices with the slick, computerized process at CVS MinuteClinics, where people browse appointments and services on a kiosk and a large display shows who's next. Healthcare is not immune to competition on usability.

Recruiting for a usability evaluation of Boston.com

On Saturday March 27 and Saturday April 3rd, 2010, I'm looking for people in MA to provide feedback on the Boston.com website for my class project. We are hosting one-hour evaluations at Bentley University in Waltham, but we also need at least one person to participate online from home. We're seeking 25-34 year olds and 45-54 year olds.

My student team will ask participants to use a computer and perform some basic tasks using Boston.com. It's easy and fun, and we're offering a $25 amazon gift card to participants.

Please comment if you might be interested, and I can tell you more. Thanks!

It's a defect … it's a feature … it's an experience bug

On the software and web projects for which I've done user experience design, I've been fortunate to work with thorough and thoughtful quality assurance (QA) engineers. Frequently these folks will enter tickets for uncertain issues, such as "I expected something to happen, but instead something else did. Is that expected behavior?" In other words, is that a bug or a feature?

There are three typical characteristics of what I call experience bugs. First is the uncertainty in whether an issue must be fixed. Frequently the behavior is as designed, but it just doesn't make sense to the quality assurance engineer. It could be nothing, or it could be a problem that no one noticed before now.

Second is uncertainty in what the fix ought to be. With other software defects, frequently the nature of the fix is self-evident. In a complex system, however, gaps in the user experience many be unanticipated until late in the development process. There might be no fix possible, but often some lateral thinking can save the day.

Third, the call on how to fix something starts with you, the user experience lead. That's because experience bugs require a design solution. The big gotcha here is making the first, quick recommendation that comes to mind, because you're feeling launch deadline pressure. Watch out, because a small fix to one part of the experience can ramify. Instead, test your first idea by returning to your design documentation, talking it through with a coworker, or just walking through the new experience on paper. Think back to a past situation that applies, and run a mental reality check to make sure the solution won't cause problems in other parts of the experience.

It's great to have QA involved and have experience tickets in the bug tracking database. You can, and should, enter them yourself whenever you discover an inconsistency or when a stakeholder has a question about the UI that makes you doubt. But your responsibility doesn't end there. If it's a significant issue, it's critical to get the attention of the development manager, product manger, or whoever's in charge of prioritizing fixes. Experience bug descriptions can be difficult to follow, and likely there are many bugs competing for priority. You may need to telephone or sit down with decisionmakers and help them understand a bug's importance.

You can forestall false experience bugs by supplying QA with all possible information about the final design. A QA engineer's background knowledge about the experience is mostly up to you. If you have access to your engineers before the QA phase of the project, you can walk them through your prototype, specifications, or wireframes to impart that background knowledge. If not, you may be able to capitalize on their first false experience bug as a teachable moment.

What have you learned from trying to fix UX problems in a project's QA phase?

Months after launch, Google Wave is missing key features

I had an opportunity to try and use Google Wave "for real" on a project, but what a disappointing experience! It might have been tough for any product to live up to their revolutionary pre-launch buzz, but Wave appear to lack very basic features that any collaborative online tool must have.

First and most obvious, it's stunning that Wave offered no alert feature. Collaboration software is of little value if you have to click a bookmark and pull it back to your browser to see if there are updates. Clearly Wave was not optimized for asynchronous communication, which is the strength of email. Now it appears Wave finally will get email notification.

The features that did make it for launch are sometimes questionable. Seeing others type in real time seems of narrow utility, and even though I'm a reasonably good typist, I feel self-conscious knowing I'm being observed. It's also difficult to find the latest updates in a multithreaded Wave. It requires much scrolling … and by the way, what's up with that wacky scroll widget? Do users need a new way to scroll as much as they need email alerts of new messages?

It's possible some of these doubtful feature decisions result from the product development process. A team in Australia built Wave, isolated from the Google mothership. This startup-in-a-bottle model is popular in large companies that want to remain entrepreneurial. When launching a new Google product, though, it's natural to expect it will work well with one's Google account. Whether it's the development team's isolation or some other factors at play, Google Wave has no integration with Google Accounts or any other of the company's online services.

Bloggers and journalists bitten by the promise of revolution pushed back against Wave in the early days. Now, however, the Web hype machine has moved on and Wave has no buzz at all. Time will tell if Google can add enough features to make the product useful and usable.

Wave's poor feature set, along with recent privacy missteps in the launch of Buzz, make Google suddenly seem vulnerable for the first time in years. Whether they mine their massive store of user data to assemble a product like Buzz, or they build a new system separate from everything as in Wave, Google need solid information on user behavior and needs to guide their decisionmaking. Without it, the giant company risks becoming inscrutable and remote from consumer end users -- just like Microsoft, in other words.

Passwords: How to align usability and security

Last month a hacker posted 32 million user passwords stolen from RockYou, an online entertainment company with apps and widgets for Facebook and MySpace. The huge dataset was clear confirmation of something security experts have known for years: most users choose weak, easily crackable passwords. The most frequently used were "123456," "password," "rockyou," and common first names, all easily guessable or hackable with a dictionary attack.

Yes, this is a big problem, and yes, we all ought to choose more complex passwords. Unfortunately, pundits have wagged their fingers about this issue for at least 20 years, and users' password habits have not changed. IDs and passwords put security at odds with usability. Most users will always resent authentication as an annoying barrier between them and the content they want.

Currently, password security almost always comes at the expense of usability. You've likely heard the frequently cited guidelines: don't use dictionary words; use different passwords for every system; mix in non-letter characters. Your system can enforce all these rules, but you may end up with greater user abandonment. Even users who succeed in registering may need to write the password on a sticky note or forget it immediately. 

Passwords and passphrases

About nine years ago, I wrote an article with some password UI tips, but I didn't touch on the issue of password strength. Today many systems use an interactive meter to indicate how difficult a password would be to crack. This is a nice feature for promoting more secure passwords, but it doesn't promote memorability.

If UI designers would universally replace password with the term passphrase, that label alone might prompt users to generate longer, more memorable codes. Even with just a few short dictionary words, phrases are much more difficult to guess than a typical password.

There are now common-ID systems like OpenID and Facebook connect that can log you into multiple sites with the same password. Of course, if that password is compromised, so are all the sites it unlocks. So the incremental enhancements of the past several years often still pit password security against usability.

Multiple factor authentication

More advanced and expensive systems use two-factor authentication. The factors in this case refer to the proverbial authentication triad "what you know, what you have, and what you are." This matches a password you know with a physical token you have (a piece of hardware like a smart card or USB thumb drive). Just like using an ATM, if you have a token, you can match it with an easy-to-remember PIN and be both usable and fairly secure.

Two-factor authentication is on the rise for corporate IT authentication and high-end software, but there's no way mass-market websites like Facebook could afford to send ATM cards to all its members. A snail-mail turnaround time would be unacceptable too. Though if you assume that all your users have mobile phones, you can implement a quick two-factor system on the cheap.

The third factor above, "what you are," falls into the domain of biometrics. Retina or fingerprint scans may seem like science fiction, but my last two HP laptops have come with fingerprint scanners. Unfortunately, their software was buggy, and I would accidentally launch it by resting my hands in a normal typing position. Clever use of laptop webcams with facial recognition sofware soon may allow seamless authentication by just looking at your laptop. It doesn't get much more usable than that!

Do you have best practices or examples to share?  Please post them in comments. It should be easy enough to log in ...

Stop showing your wireframes

Christina Wodtke explains in a new blog post what's wrong with wireframes. She contends wireframes are a holdover from when information architects and graphic designers were still learning the Web. Now, they're constricting the design and development process for today's  visual and UX designers.

I'm not willing to throw this tool away for myself, but Wodkte's article catalyzed my thoughts on a different problem with using wireframes. First, I wonder, are your project sponsors and stakeholders like mine? Do they have you lay out pages with only  a vague notion of the functionality? Do they "sign off," but frequently change their minds after the design is applied? And do the graphics and copy arrive only at the very end of the project?

So stop showing them your wireframes. Think of yourself like an architect (construction, not information). Architects don't show their blueprints or CAD drawings to their customers; instead, they create nice scale models and spiffy computer graphics. For you, interactive prototypes are the way to go.

I know this advice flies in the face of the foundational, iterative process many UX designers have been trained in, but then I step back from the orthodoxy and think about it. Wireframes are a specific stage in the design process, meant to elicit specific feedback. But rarely have I received the stakeholder feedback I needed from them. Instead I get some combination of glassy eyes, requests for flows and mockups, and tentative decisions too often reversed when final mockups are available.

I have another reason too: your portfolio. Wireframes don't look good in it. Showing them communicates that an incomplete, vague site outline is what you're capable of. Hiring managers may care about your process, but you're best off loading a working site for them and letting them play with it while you talk briefly to the process. If you're talking about a print or online portfolio, show final mockups that look great.

If you disagree, let me know your thoughts. Are wireframes a useful communications tool for you?

Agent Google versus the semantic web

This week I reread the futuristic Berners-Lee article on the Semantic Web (pdf). It describes smart desktop software agents that can arrange appointments, delegate tasks to trusted family members, and even negotiate prices on behalf of their users. These agents depend on semantically tagged Web information -- open data that's been described in a standard way so machines can use it.

Nine years later, and depending on your perspective, this compelling vision still seems like mission impossible. Some major websites, such as ibm.com, are now built with validated, standards-driven code and tagged with semantic metadata for machines to repurpose at will. But, in a familiar chicken-and-egg adoption cycle, most organizations with useful online data are still waiting for applications to come along and justify the effort of recoding for the semantic web.

Information architects get the value of semantic data applications, but end users like you and me don't seem to miss it much. I believe we put up with it because we already have an secret agent of our own: Agent Google. No one's better at pulling the meaning out of disparate web documents and making information findable. Google doesn't need the semantic web -- they've already semanticized it for their own search results and ad serving.

Of course, there's a big difference between desktop software drawing on open data formats, and Agent Google's secret data factories. Perhaps the most significant change in the Web since Berners-Lee wrote his article is the mass migration of personal data into the cloud. Many people now routinely write all their documents, share their schedules, post their photos and video, save all their email, and map their social lives online. Meanwhile, Facebook Connect and OpenID are bridging your data islands under identifiable accounts.

Agent Google's near-omniscience is no news flash to many of us, but it's worth staying alert for alternatives. The White House's recent adoption of the semantic RDF and OWL standards may lead other organizations to publish their data in agent-friendly formats. Someday soon, you may finally have your own trustworthy semantic agent, with a license to gather data that's for your eyes only.