Compete on Usability

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.