Latest Tweets

Notes from the Future of UX

| 11.13.2014

Last week I went to Rosenfeld Media’s UX Futures 2014 conference, a one-day remote conference with a star-studded (okay, star-studded in that dorky, fun UX way) lineup. I thought I’d share my notes from three of the conference sessions.

  • “User Experience: The First Fifty Years” by Jesse James Garrett. Jesse takes a look “back” at UX from the year 2048 and describes what’s happened to the field.
  • “Expanding our Expectations of Everybody” by Margot Bloomstein. Margot uses current events (nothing I hadn’t heard rehashed a million times) and historical examples (these got my attention! super interesting) to illustrate what designers can do to realize the promise of media everybody can participate in.
  • “What if Steve Jobs Wasn’t an Alien?” by Steve Krug. Steve goes through some of the greatest hits of historical UX and prognosticates about the future of usability.

The conference viewing was generously hosted by and organized by Julie Francis & Tony Santos.


“User Experience: The First Fifty Years” by Jesse James Garrett


“Expanding our Expectations of Everybody” by Margot Bloomstein



“What if Steve Jobs Wasn’t an Alien?” by Steve Krug


A Designer’s Quick-Start Guide to CSS Preprocessors

| 11.13.2014

CSS can be a hot mess to write and read. I am here to repair your relationship with it by introducing you to your new secret weapon.

I once hand-wrote over 300 lines of CSS to style one lousy navbar, and I know I’m not alone. Writing CSS by hand, as many designers do, is an exercise in repetition. Reading CSS is a real workout for your scrollbar and your patience. Nevertheless, we’re stuck with it. How else could we round those corners or drop those shadows?

Writing code to style a website does not have to be (quite) this tedious. Preprocessors are the missing ingredient in your HTML/CSS workflow.

Lots of articles about preprocessors target developers, but this one goes out to UX and UI designers. A lot of designers I know – good ones! – have a solid basic understanding of HTML and CSS, but are cautious and awkward around improving their workflow. No wonder – with all the frameworks and libraries available, it’s hard to know where to start. Many developer tools are overkill for designers, not to mention their documentation assumes a lot of prior knowledge and a high level of server access.

While they may look like developer tools, preprocessors are a fabulous addition to a designer’s workflow. Even if your HTML/CSS is pretty basic, there’s something for you here. I’ll tell you about my favorite features and how they help me as a designer.

(This article assumes that you’re somewhat familiar with CSS. If you’re not there yet, try a tutorial at,, or Codecademy.)

What’s a preprocessor?

A preprocessor lets you write CSS in a language that feels like a better, more sensible version of CSS. Then it creates, or compiles, a browser-readable CSS file. You don’t touch that compiled CSS file. You work on a nice tidy file with the extension “scss”. SCSS files are written in a preprocessing language.


Naming note: Many people call this language both SASS and SCSS, but that’s not quite accurate. The language, called SASS, actually has two syntax modes. SCSS, the newer syntax mode, uses brackets around chunks of code. SASS, the older syntax mode, has the same name as the language and uses indentation and whitespace instead of brackets. Of the two syntax modes, I prefer SCSS – the brackets are foolproof and don’t get screwed up in different text editors.

Which preprocessor should you use?

I use SCSS, but you might also want to use a preprocessor called LESS. If your coworkers use one or the other, just follow their lead – both SCSS and LESS are great. If you’re on the fence, here’s why I recommend SASS (Chris Coyier at Treehouse agrees):

  • It has more logic built into it. You can do for-each loops and if-then statements right in your CSS. As long as you’re using a preprocessor, why not pick the one with the most features?
  • Adding the Compass library to SCSS adds a ton of useful reusable patterns.

So what can you do with SCSS?

Nest Now, Thank Yourself Later

Have you ever written CSS that looks like this?

.navbar {
	// styles
.navbar ul li a {
	color: red;
.navbar ul li a:hover {
	// styles
.navbar ul li {
	// styles
.navbar ul {
	// styles
.navbar ul {
// styles

You have to cram selectors into your CSS in order to make sure your rules have the right scope; you don’t want to make every link red, only the links in the navigation bar. The only thing more annoying than writing this structureless, repetitive code is trying to read it later.

With a preprocessor, you can write this instead:

.navbar {
	// styles
    ul {
		// styles
        li {
        	// styles
        	a {
	        	color: red;
				&:hover {
						// styles

In SCSS, “&” refers to the current selector: the selector just outside the surrounding bracket. So, in the example above, &:hover compiles to a:hover.

The nested code is far less repetitive and easier to read. Just don’t nest hundreds of lines deep, or (if you’re anything like me) you risk misplacing a bracket or two. I try to keep nested chunks of code small enough to fit on my screen.

Use Variables as a Style Guide

We designers truly want to be open to feedback at every stage of the process. But it’s hard not to groan when responding to feedback means hunting through thousands of lines of CSS. Where’d you put that color? How wide was that column? Why is one button’s border radius refusing to change?

If you think ahead and define those properties in variables, making major visual changes is a breeze. You can define yourself a style guide that dynamically updates your entire site.

In SCSS, you define variables with $ signs. Once you’ve defined a variable, you can use it anywhere you’d use the text you’ve stored in it.

$orange: #f64212;
$subtle-light-gray: #efafef;

a {
	color: $orange;
	background-color: $subtle-light-gray;

Colors are only the most obvious way to use variables. These are all variables I’ve written in SCSS:

$orange: #f64212;
$help-text-size: .8em;
$total-width: 1024px;
$menu-width: 25px;
$main-content-width: $total-width - $menu-width;
$mobile-breakpoint-width: 468px;
$logo-height: 2em;

SCSS knows how to do math even with quantities that aren’t exactly numbers. It’s even smart about mixing units.

width: 11px + 2em + 50% + $menu-width;
color: $orange - rgb(25,14,14); // yes, you can do math with colors!

“Make the logo bigger”? No problem.

Mixins and Partials: Variables on Steroids

A mixin takes the idea of a variable one step further. It’s a collection of rules that you know you’ll want to reuse. I often use them for UI elements that appear frequently, like labels, tooltips, buttons, and dropdowns.

Define a mixin by using the word “mixin” and an @ symbol, followed by the name you want to call the mixin.

mixin @tooltip {
	border-radius: 5px;
	border: 1px solid $lightgray;
	background-color: #fff;
	box-shadow: 2px 2px 3px 0px rgba(20, 20, 20, 0.16);
	cursor: pointer;
	padding: 10px 19px;
	font-size: 90%;


Then include the mixin with the word @include , followed by the name of the mixin.

.onboard-tooltip {
	@include tooltip;
	color: $orange;
.premium-user-tooltip {
	@include tooltip;
	color: $darkgrey;

You could define these mixins at the beginning of your SCSS file. But if you have more than one SCSS file, copying and pasting variables into all your various files, you’re living dangerously.

Partials will help you keep your mixins and variables in one place. A partial is a snippet of SCSS that gets included before a file is compiled. To mark a SCSS file as a partial, give it a name starting with an underscore, such as _variables.scss . Then, to include it in your main file, write @import ‘variables’  at the beginning of the document. That partial will not get processed into CSS. Your file structure will look like this:

Partials are also great for chunking out well-defined bits of CSS, like my aforementioned 300-line navbar.

Are you processing locally or remotely?

The preprocessor can work its magic either on your local computer or on a server.

You’ll probably want to set it up on your computer, so that it creates an upload-ready CSS file right next to your SCSS file. If your processing is happening locally, keep the SCSS file and its compiled CSS together at all times. Upload them together, download them together, and if you delete one, delete the other. (And, if you’re using git, add the CSS files to .gitignore.)

You will also want to protect your computer by a VPN (virtual private network). I suggest looking up some VPN ratings and see what would be best for you.

If your workplace is technical, you may have a preprocessor already installed on the server, so that this conversion happens after you upload your files, not before. Ask around if you think this might be the case.

Setting up your text editor

If you’re working locally, you need to set something to “watch” your SCSS file and, when you hit save, turn the SCSS into matching CSS.

Coda 2:
Install this plugin, and any .scss files you create will be automatically compiled to a .css file of the same name in the same folder whenever you save the file.

Sublime Text:
This is a little trickier; there’s no one add-on that does it all. Here’s how to get Sublime Text supporting SCSS.

Text editor not supported?

If you’re using Dreamweaver, BBEdit, or another text editor that doesn’t have a SCSS plugin or add-on, no worries. You can either use the command line, or you can use a standalone app that watches your SCSS files for you. At Sliced Bread, a lot of us use Koala (free). Other popular options are CodeKit ($29) and LiveReload ($9.99).


That’s it! A preprocessor does take a little time to set up, but it’s eminently worth it. SCSS took me 30 minutes to figure out, but it saved me hours in the first month I was using it.

The one downside? I can’t live without it. On the rare occasion when I do need to write vanilla CSS, it feels like I’ve downgraded from a Tesla to a Buick LeSabre: slow, unattractive, and retro (not in a good way).

So, make your next CSS file a SCSS file, and join me in writing faster stylesheets – let’s make time for the fun part of design.

Job Opening: Senior UX Designer

| 09.8.2014

Sliced Bread Design is on the lookout for a Senior UX Designer, employee or contract. You’ll design for a variety of products and industries alongside a crew of seasoned, passionate colleagues (and three chickens).

We are a boutique user experience design agency working on interesting, complex human/tech interaction problems. Our philosophy is user-centered to the core: we’re constantly talking to users and testing our designs. Since we’re a small shop, many of us take on multiple roles (user research, client work, and creative direction).

Here’s what will make a good match:

  • Your portfolio shows examples of complex interaction design problems you’ve solved. We’re looking for detailed design work on rich applications (for example, searches, dashboards, or transactional flows).
  • You’re smart and motivated. You get up to speed quickly, and you like thinking through tough design problems.
  • You’re comfortable with all phases of the design process, from concept creation and quick sketches through detailed interactive wireframes and testing with users.
  • You have solid prototyping skills in HTML, CSS, and JavaScript.
  • You live in the greater Bay Area. Ideally, you live close enough to Mountain View, CA to join us in the office on Tuesdays and Thursdays.
  • This is not an entry-level design job; you need to have worked in this field for a few years.

If this describes you, we’re guessing you’ve got options. So what makes Sliced Bread special? We combine a single-minded passion for doing high-quality design with a uniquely flexible working environment. Our world headquarters is a sunny, friendly home office where we all work on Tuesdays and Thursdays; the rest of the week, we collaborate remotely from wherever we like. Katrina Alcorn, designer and author of Maxed Out: American Moms on the Brink, sums us up well: “Everyone is just focused on doing great work, and doing it efficiently so they can enjoy their lives.”

Sound like you? Email with a link to your portfolio, resume, your rate/salary requirements and availability.

Watch Out for Wearables: Google I/O Recap

| 07.21.2014

Since 2008, Google I/O has been a developer’s conference, a venue for launching APIs, toolkits, and operating systems. 2014 was different: Google announced I/O’s first ever “design track,” and they invited Sliced Bread to come take a look.

So Mia, Julie, and Molly spent two days fiddling with multi-device interactions, squinting at watches, debating colors, fonts, and animations, and talking shop at the Moscone Center in downtown San Francisco. Read on for their conference takeaways, their new favorite techniques, and one thing Google needs to do in order to keep attracting designers to I/O.

Mia O’Neill, Managing Design Director


Mia gets coaching on her putts from Google Glass. She almost makes Glass look cool…

What were your top takeaways from Google I/O?

  • I was initially disappointed to hear that I/O was focusing on wearables this year. I haven’t worn a watch in 10 years (isn’t that what my phone is for?). But, by the end of the conference, I couldn’t stop thinking about all the interesting possibilities for wearables. They’re not for everything: the really interesting use cases for smart watches have to do with specific activities like running (taking advantage of built-in motion sensors and heart rate monitors) or even cooking (I loved the AllTheCooks Recipes wearable app).
  • Learning about the motion patterns in Material Design renewed my excitement about the importance of animation. At Sliced Bread, we animate our prototypes using JavaScript, with help from libraries like jQuery and GSAP. Making motion and interaction a priority is certainly more challenging and time-consuming than building static pages, but it’s worth it; animation is integral to the product experience, not just the icing on the cake. It was gratifying to hear Google echo our convictions!

What did you add to your design toolkit?

  • Google designers demoed a few examples of how they use Adobe Edge Animate, After Effects, and Framer.js to prototype motion in their designs. Molly and I both heard a lot about Framer from designers outside Google. It’s not a Google tool, but it seems like a great way to prototype the complex motions and animations that the new Android platforms demand.
  • I’m going to subject all my mobile designs to a jiggle test. What’s a jiggle test? During the session on Designing for wearables, designer Hayes Raffle showed two watch screens side by side. Both interfaces looked tidy and clean to me. Then he jiggled the screens… and it became instantly clear that the UI on the right was much clearer.googleio-jiggle
    We all know that mobile apps need to deliver just enough information, but this is doubly true for wearables: extra information really gets in the way when the screen is small and possibly fast-moving. Interactions with tiny screens should be as short, simple, and streamlined as possible.  (I really wish Apple had performed this test when they redesigned their call waiting feature in the first version of iOS 7!)

Julie Stanford, Principal


Google Glass counts Julie’s squats – and keeps track of her form. Glass didn’t figure prominently in this year’s I/O, but it did make for the best photo ops.

What were your top takeaways from Google I/O?

  • I’m not the sort of person who likes sitting in a dark room discussing the philosophy of drop shadows, so the initial presentation of Material Design was a little too frou-frou for me. However, I’m impressed that Google finally got its act together around design. They gave both developers and designers a concrete, cohesive, and beautiful point of view about the look and feel of Android apps. I like the common sense approach behind their system: all background surfaces are made of “paper.” Each piece of “paper” is 1 dip thick, and it stacks, slides, and resizes. But paper on a screen can’t flip – it just doesn’t make visual sense. Consistently applying this logic is key to keeping the multi-screen experience from getting too crazy.
  • Everyone at Google thinks user research is just as important as we do. This was clear in session after session. Finally, we can get to the business of designing stuff that actually works and stop arguing about the right methodology!
  • If they’re done right, voice UIs can be so much more than phone trees. Companies like Tellme tried to implement voice UIs for consumers back in 2008, before the market was ready. Now, Google (and Apple) have a chance to pull off voice control – particularly in cars and on your watch. (Note that I’m only going to talk to my watch when I’m alone, thank you.)
  • I was not excited about watches before this conference. Now, I can’t get them out of my head – the possibilities seem boundless. The really interesting use cases are contextual and ambient. My watch can alert me when I am at the zoo and it’s penguin-feeding time! Now that’s importantBounce House Party!

What did you add to your design toolkit?

  • I love using How Might We (HMW) questions, but I never used them as a form of note-taking while listening to user interviews, like the Google Ventures team did during the design sprint we attended. I’m still not excited about writing HMW’s while listening to users, but I asked my clients to write HMWs while sharing user stories with them from a needfinding study. It really helped clients think creatively and was a great adaptation of the Google Ventures technique.googleio-hmw2
    How Might We questions transcribed during a user interview during the Google Ventures design sprint.

Molly Wilson, UX Designer


Molly tests out her new Samsung Gear Live watch. Her verdict: much more fun to design for than to wear.

What were your top takeaways from Google I/O?

  • In the geek classic The Hitchhiker’s Guide to the Galaxy, Douglas Adams describes human society as “so amazingly primitive that they still think digital watches are a pretty neat idea.” Digital watches were dorky in 1979 (the year Hitchhiker’s Guide hit the shelves), and they haven’t exactly gotten cooler. The I/O giveaway this year was a pair of smart watches that feel way too clunky and chunky for daily wear. However, despite the fashion drawbacks, I came away from I/O feeling that design for simultaneous screens is a tough, exciting problem I can’t wait to sink my teeth into. If you’re using the same navigation app on both your watch and your mobile, what information do you need to see where, and how does interacting with each device change the display on the other one?
  • Both Julie and I teach at the Stanford, so we’re not exactly rookies when it comes to design facilitation. Nevertheless, I learned some fabulous techniques from the Google Ventures design teams. I loved their two-phase heat map voting (I’d always done just one round of voting). And I’m absolutely going to use crazy eights with my colleagues at Sliced Bread when we need fresh insight into a tough interaction problem.googleio-howmightweThe small red dots create a “heat map” during the first round of voting on ideas; the larger circles (not colored) are from the second round.

What did you add to your design toolkit?

  • Jenny Gove did a huge (119 people!) qualitative usability study of mobile websites. She extracted a bunch of principles about mobile website design and published an easy-to-digest whitepaper. Many of these principles are things we intuitively know, but Gove backs it up with hard data; it’ll be great to have in my back pocket when defending best practices.


Since this is Google’s first year of the design track, here’s our one big request: remember that designers’ workflows are different from developers’, and create prototyping tools for designers, too. In order to prototype on the watches we received, we’d need to bust out the full SDK. That’s just too much overhead given the quick, iterative way we work. Looks like we’ll be taping phones to our wrists until wearables allow for the rapid, janky interactive prototyping that will let us get lightweight feedback.

Overall, we were impressed with what we saw. Given that this was only the first year of Google’s Design Track, we’re looking forward to seeing how Google will continue to expand and develop it further in the future.


Enjoying the afterparty at Yerba Buena. Not shown: Sliced Bread doing the silent disco really, really hard.

Meet our 2014 summer interns

| 07.2.2014

This summer, we’re welcoming two interns from the Learning, Design, and Technology (LDT) master’s program at Stanford. They’re joining design teams working on interaction design projects in the security and small business spaces. We couldn’t be more excited to have their creativity and expertise in the house!


Jesse Day is obsessed with clarity. He designs to strip away confusion, exposing meaning and purpose. As a teacher and an artist, Jesse spent the last decade in the pursuit of crystalline communication through writing, image, and music and is now working to bring this ideal to interaction design.

Before Sliced Bread Jesse was a lecturer at Parsons The New School for Design where he taught courses in communication design, and writing and public speaking for artists and designers. At Parsons, Jesse helped to reshape the undergraduate experience and received two Innovations in Education awards for his work on curriculum and designing pedagogical tools. He is the author of Line Color Form: The Language of Art and Design, a visual guide to the vocabulary of form and function. Jesse holds a BA in Modern Literature from the University of California Santa Cruz. His favorite bread is corn bread.

Visit his website at

Natasha Prats from american eagle loves designing intuitive products for users, bringing in her psychology, art, and engineering background into the process. She’s done smaller projects with Purina, Miele Appliances, and various start-ups, along with a longer-term stint at Google Shopping.

This year, she’s decided to pursue her passion for design and is working on extending it into educational toys and games through Stanford’s Learning, Design, and Technology program. She’s been exploring interaction design (and discovered JQuery, her new favorite language!), so she’s excited to join the team at Sliced Bread team for the summer and learn more about this area of design. She holds a BS in Engineering (Product Design) from Stanford University. Most importantly, her favorite bread is French Toast.

Visit her website at

The Learning, Design, and Technology program merges educational theory with design practice. As a part of the program, all students design, prototype, and test an original educational technology product. As well as interning with us this summer, Jesse and Natasha are finishing up work on their master’s projects. Come see what they and their classmates have been working on at the public LDT Expo, held at Stanford University on August 1, 2014.

Finding the User Testing Sweet Spot

| 04.10.2014

At Sliced Bread, we use a technique called Fast Insight Testing to get lightweight feedback as we prototype. Compared to a lot of user testing, it’s pretty unscripted and casual – not to mention quick. We’re happy to get a rant or a rave, even if it means we’re deviating a bit from our plan.

But we don’t just let people run their mouths about whatever they feel like talking about. That’s not a user test – that’s a bull session.

So here are 2 of my favorite techniques for striking that balance between “customer survey” and “psychotherapy session.”

1. Let them know what kind of feedback you want.

This sounds obvious, but it’s surprisingly easy to forget. Most people have filled out forms, surveys, and questionnaires, but less scripted research is probably unfamiliar territory. Participants are generally eager to please, but they do need to know what sort of responses you’re looking for.

We begin Fast Insight tests by telling people we are interested in their unvarnished, unfiltered personal opinion. We’ll often add “I didn’t design this, so don’t worry about hurting my feelings.”

Okay, from time to time that’s a little white lie. We’re a small group, and we all do both research and design, sometimes on the same project. But it gets our message across: don’t hold back. (And it reminds us that, even if we did design the prototype, we need to let go of our attachments to it.)

2. Ask open-ended questions about specific things.

If your interviewees seem confused or unfocused, it doesn’t mean they don’t have opinions – they just may not know where to start.

The combination of asking an open-ended question, but asking it about a very specific thing, can work wonders.

Here are a few examples:

• “See that text at the bottom of the page – what do you think of it?

• “What are your feelings about the sidebar?”

• “Tell me about the sliders on the left.”

As people are talking, we’ll frequently interject with follow-up questions. Asking “why?” over and over gets old (and can make you feel like an overly inquisitive toddler), so try one of these alternatives:

• “Tell me more about that.”

• “How does that make you feel?”

• “What makes you think/feel that?”

• “What’s going on with that?”

• “What is that like for you?”

• “I’d love to hear more about that.”

• “I’m curious about why that is.”

The reason this works so well is that it gives your users two important elements at the same time: a relevant starting point (the specific element you’re asking about) and a license to be honest and casual (the open-ended question).

Used together, these two techniques help me keep user tests focused but friendly. Give it a try, and let us know how it goes!

Passwords are Broken. What’s Next?

| 02.20.2014

A few weeks ago, I wrote about why we need to stop blaming users for choosing dumb passwords: we’ve designed a system that’s basically impossible to use “correctly.”

It’s not all doom and gloom for authentication design, though. I’m heartened to see some new authentication patterns taking hold. Some are entirely new, inspired by the constraints and affordances of new devices. Some are variations on patterns that have been standard in particular industries but are now hitting the consumer market. Plenty of security experts have weighed in on the technical aspects of new authentication patterns, so let’s explore the user experience implications.

How do these emerging patterns stack up? I’ll look at these three criteria:

Are they cognitively reasonable? This is where passwords fail: sign-in systems shouldn’t expect people to do things like remember long strings of random characters.

Do they feel like the right level of security for the situation? Nobody wants to use a thumbprint in order to comment on Facebook.

Are they practical in the expected context? It’s not sensible to use a voiceprint at a noisy DMV office.

The extra layer: Two-factor authentication

In two-factor authentication, users enter a code displayed on one device in addition to a password. This doesn’t replace passwords; it’s a second password, often on a different device.

You can secure your Google accounts with an extra code, displayed on your phone.

Cognitively reasonable? Sure. It’s an extra step, but nothing extra to remember.

Feels like the right level of security for the situation? An extra layer of security is fine, as long as protecting the info feels worthwhile. Right now, two-factor authentication is mostly reserved for email and financial and medical information – and that’s a good thing.

Practical in context? Sometimes. Often, when I’m checking my email at a public computer, I’m in a hurry, and the last thing I want to do is pull out my phone.


Also, sometimes I want to access email from my phone – and the security code is also on my phone. Using your mobile device to sign onto your mobile device is clunky and doesn’t offer much security benefit.

The bottom line: Save two-factor authentication for when it’s really and truly worth it.

The visual password: Gesture-based authentication

Why type when you can swipe? These techniques let you authenticate with gestures on touchscreens instead of poking at tiny, limited keyboards.



Unlocking an Android phone requires users to trace a pattern on a grid of 9 dots.


Source: Parity News

Windows 8 offers picture gesture authentication, where users choose a picture and then tap, drag, and “draw” a pattern on it; the picture and the pattern together serve as their password.

Cognitively reasonable? For many people, tapping into spatial memory and muscle memory is a welcome change from remembering passwords.

Feels like the right level of security for the situation? Images and patterns can be easier for a nosy onlooker to see and remember. Android’s 9-dot grid wouldn’t be appropriate at, say, an ATM.

Practical in context? It’s easier and faster than typing a password on a mobile device, since the touch targets are larger.

The bottom line: Best for frequently-repeated, on-the-go situations where people don’t feel they’re dealing with highly sensitive information directly.

The password within you: Biometric authentication

In biometric authentication, characteristics of your body serve as your credentials. On the one hand, it’s hard (though not impossible) to fake, and you’ll never forget it. On the other hand, it’s impossible to change.

Source: Apple

The iPhone 5S can unlock via a built-in fingerprint sensor.

Source: Coursera

Coursera offers an interesting spin on biometric identification by using typing speed and rhythm as an auxiliary identifier. On a site where users are expecting to type a lot of text, asking them to type a sample paragraph wouldn’t stand out as inappropriate.

Cognitively reasonable? Definitely. There’s absolutely nothing to remember; done right, biometrics can feel futuristically seamless.

Feels like the right level of security for the situation? Maybe. Biometric authentication can easily feel intrusive and overly permanent. People won’t want all accounts inextricably linked to their real identities, and that’s okay.

Practical in context? That depends. Designers need to be mindful of what it feels like to use biometric authentication in public, as well as whether the hardware is durable enough to filter out background noise, temperature, moisture, and other environmental factors. Also, biometrics’ permanence can backfire, as one blogger who cut his finger found out when his laptop would no longer recognize his fingerprint.


Bottom line: Every step of the way, make sure people feel in control. One false step and biometric authentication gets creepy and obnoxious.

When you’re choosing and designing an authentication system, of course the security of people’s data is top priority. (Or at least it should be – ahem, Snapchat.)

But don’t neglect design, and don’t forget about context. Keep in mind how, when, and why people are likely to need access. Don’t spend your time chasing seamless, space-age, and sexy. To keep people safe and sane, authentication needs to be, above all, appropriate.

Forgot Your Password?

| 01.16.2014

If your password is “password,” you’re not alone. Security analyst Mark Burnett recently harvested a list of publicly available passwords, and 4.7% of them are, yes, “password.”

The picture doesn’t get much better further down the list. 9.8% of the passwords Burnett found are either “123456,” “12345678,” or “password.” 40% of all passwords appear in the top 100 passwords, and 71% of all passwords appear in his list of the top 500.

The narrative most people take away from this is that we don’t understand passwords or security in general. “Most Common Password List Shows Shocking Lack of Imagination of Computer Users,” writes the Huffington Post. This massive population of tech-illiterate dim bulbs needs our help, goes the thinking; if they don’t choose better passwords, they’re all going to have their email hacked and their bank accounts drained – and, some might say, serves them right for using “password” as a password. They seriously need to get their act together.

From a designer’s point of view, though, the problem isn’t stupidity, laziness, or a lack of education about security. As user experience designers, we don’t treat users as the problem when a system doesn’t work. If 91% of students failed a test, wouldn’t you assume that the test was the problem?

Soon, we’ll be able to do better than passwords, both in terms of security and usability. The best emerging solution may be one that combines elements of passwords, images, gestures and biometrics, as a recent article by Eben Kaplan in Information Security Journal proposes. But right now, we’re stuck with passwords. It’s unlikely you’ll be able to authenticate yourself at the bank by tracing a custom pattern around an image with your eyes while your retina is scanned anytime in the next few years.

But even though we’re pretty much locked into the password paradigm, we can still improve the authentication experience. If you’re thinking through a site or an app, here are a few straightforward design practices you can use right now.

Don’t impose maximum lengths. People are used to minimum lengths. But there’s no design or security advantage to limiting their passwords to fewer than 10 characters. Charles Schwab is one of the worst offenders, limiting passwords to 8 characters.

Allow copying and pasting in password fields. When people use a password manager to create super-strong passwords like, say, “x@#nSA9*g$HsoPNW(qov,” don’t punish them by making them type that gibberish out by hand.

This one may be unpopular, but here goes: on small mobile devices, don’t obscure the letters that are already typed. It’s hard to get the letters right on a tiny keyboard, and leaves people confused about whether they’re misremembering or mistyping their passwords. As anybody who’s ridden a city bus knows, it’s much easier to visually eavesdrop on a large laptop screen than a tiny, hand-covered mobile screen.

Finally, be careful with content restrictions. Allowable passwords vary wildly across the internet.

Amazon has no restrictions at all.

Amazon password entry


Google requires 8 characters and disallows dictionary words.

Google password change


PayPal requires 8 characters, including 1 special character.

PayPal passwords


And the California DMV requires… well, see for yourself.

CA DMV passwords


You’d think websites with annoying password policies would feel the sting of user abandonment and shape up. Unfortunately, websites with frustrating, arcane password policies are likely to be the ones you can’t avoid. Researchers at Microsoft found that websites that need to attract and retain users (think Amazon or Paypal) are much less likely to enforce stringent password rules as websites where users don’t have a choice (think DMV).

We want users to pick different passwords for different sites, but we drive them crazy when we constantly switch up the rules. We want them to pick strong passwords, but they frequently don’t (and then we ridicule them).

Is it time to give up on passwords? Check out my next post, a designer’s eye view of some emerging authentication patterns.