Latest Tweets

Ditch the Rainbows

| 10.1.2014

Color is becoming more important than ever. With the increasing popularity of flat design, designers are less able to rely on 3D buttons, drop shadows, and other crutches that used to make functionality apparent.

Of all the formal elements of design, color hits the fastest and hardest. Color communicates the mood of a website or application in a fraction of a second, long before we grasp the semantic content. Color has the power to clarify or confuse how a user is meant to interact with a digital environment and with great power comes great responsibility.

I see a lot of websites and apps where the designers just went overboard with color, either splashing it all over the place like Jackson Pollock, or pulling an Ellsworth Kelly and filling the entire page with a garish monochrome. Using just the right amount of color is harder than it might seem. Here, I’ll share some examples of effective and ineffective color use to help you make wise chromatic choices in your own designs.

Why Less is More

We’ll get to websites in a moment, but first let’s think about information design more broadly. Information design is the art of foregrounding what’s essential, while backgrounding or removing what isn’t. Take maps for example. Like websites, maps present a lot of information in a small space, and cartographers must make very shrewd color choices to maximize signal, and minimize noise. But, like web designers, they don’t always get it right. Here’s a map that visual information guru Edward Tufte singled out for its egregious abuse of color in his book Envisioning Information (Graphics Press, 1990):

What’s wrong with this map, aside from locating Alaska just to the left of Juárez? Whoever did the inking took the “more-is-more” approach. All colors are equally saturated, and the background blue is the dominant hue, pulling the eye away from the central information at every opportunity. Within the landmass itself, every swatch is bright and loud, and, aside from the inherent attraction of red, no single element stands out from the others. This map has failed to foreground anything.

Tufte, the visual information expert, advocates a sparing use of color, ideally against a muted background. See how the structure and function of the buildings and fields in this city plan leap out to announce themselves to the viewer:
good-map

When color is used with precision and purpose it brings focus to pertinent information, while leaving enough breathing room to temper the distraction of background noise.

Using Color in Interaction Design

Judicious use of color is even more important when it comes to designing screens a user is meant to interact with. When we are looking at a web page, typically we are not just soaking in its aesthetic beauty; we are looking for something. The job of a designer is to figure out what things the user is most likely looking for and make those things as apparent as possible, or in the case of marketing sites, to direct the user where you want them to look.

Let’s look at an example from Target’s homepage.

Now this is not really fair because Target’s branding is all red, which presents considerable challenges. I’d like to pause for a moment and point out that all colors are not created equal. From the bright arterial blood coursing from a wounded centurion’s neck to the vermillion glow of fires in the night, the color red is permanently imprinted in our collective psyche as a sign of urgency and danger.

The UI designers at Target do not appear to have gotten that memo.
target

See how the search bar and side nav are superimposed over the header bar in shades of crimson and burgundy that are only slightly off from the carmine red of the top navigation bar. This red abuse is exacerbated by the excessive prevalence of highlighted text, “free shipping”, “free returns”, “15% off”, “TV sale.” There are fires everywhere! The eye is drawn hither and thither with nowhere to land. I have no idea where to click. I’m paralyzed.

Old Navy, bless their hearts, does a much better job.
old-navy

Like the city plan we looked at before, this site avoids clutter with plenty of whitespace. Best of all, they use highlights in a meaningful way. The exact same shade of red, an unsaturated scarlet, is consistent throughout the design, creating a harmonious visual relationship between elements that are actually related. In this case the large color block explains the details of the sale “5 Must-Haves to fall for”, which are then referenced with the red numbers to the right of the model. The subtle highlight of “BOYS” on the main nav stands out in sharp relief from the surrounding elements and reiterates the relationship between the selected item and the displayed content. Good job team!

The Perils of Flatland

A flatter design aesthetic can be a beautiful thing. When done well, it accentuates the expansive space afforded by the widescreen display and offers a distinctly modern functionalism to web design. But the impulse to overuse color presents real danger to a site’s legibility.

When thinking about how to use color in your interface designs, I urge you to consider how you are drawing the eye around the page. Like a well-designed workflow, good use of color whisks a user through an interface so smoothly that they barely even notice it is there.

Jesse Day is an intern at Sliced Bread and the author of Line Color Form: The Language of Art and Design.

cover41

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.

image05/

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.

 

Source: cnet.com

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.

How Apple Broke Call Waiting in iOS 7

| 02.5.2014

I recently upgraded my iPhone to the new 5S and downloaded iOS7. I’m enjoying some of the changes (finally, automatic app updates!). But the other day, while driving to work, I experienced one design change that wasn’t just disappointing – it was downright panic-inducing.

I got a phone call while I was on another call. I glanced down at my phone and was confronted with this screen:

Huh? Quick – which button do I press to answer the call?

I felt the pressure begin to build. I tried to keep my eyes on the road while reading the small print on both the “Answer” buttons. By the time I’d finally made sense of my choices, my call waiting had already gone to voicemail.

Had Apple even tested this new design at all?

My initial confusion with this screen hasn’t improved over time. These buttons trip me up every time I see them. Answering my call waiting – a common task I’ve never had problems with – now causes me to panic, especially if I’m driving.

Let’s look more closely at the old screen and its wordy, flattened replacement.

Why was the old design so much better?

Here’s what Apple did wrong in their new design:

  • The options look too similar. The top two buttons are both titled “Answer.” They look identical at first glance, requiring users to read the small text in order to distinguish between them.
  • There’s too much text! The old design used fewer than half the words to present the same three options.
  • It’s too easy to accidentally end my current call. The “End current call” option is listed first, is no longer red, and could easily be mistaken for the “Hold current call” button. Apple’s designers seem to have changed their minds about which option they think people will use the most. I can’t speak for everyone, and I haven’t seen their research, but personally I’d rather ignore call waiting rather than accidentally hang up on the call I’m already on.

What Apple got right:

  • The grouping makes much more sense. I do like that that the new design groups the two “answer” buttons and separates them from the “decline” button.

Here’s how I’d improve the new design:

Here, I’ve emphasized the differences, not the similarities, between buttons. I’ve kept the text large and readable. And I’ve kept the words to a minimum.

My advice to fellow designers: Imagine people using your product while they’re distracted, multi-tasking, or in a hurry. How can you use color and text to make all the options clear in a single glance?

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.

Flipboard: A tale of tough choices

| 06.20.2011

I recently had a discussion with Mike McCue, the CEO of Flipboard, on how he and his team managed to get things so right with the Flipboard design. In particular, I was interested in how they were able to balance functionality with delightful, polished, user experience features.  Mike’s answer was very simple  — they had to make some very tough choices and a lot of cuts. Their goal with Flipboard was to communicate to first time customers the potential of the product and have them yearning for more. Mike explained that when people used Flipboard for the first time, he wanted them to think, “Yes, I get it! And it would be even better if…” Consequently, they cut all but the most important functionality for their v1. For example, Flipboard was a news reader but didn’t have full RSS on first launch; it only supported some predetermined feeds. Also, it had a Twitter reader but didn’t let you post tweets. These types of painful functionality decisions allowed time to implement the polish to the interaction that Flipboard is known for – gorgeous visuals, subtle animations and a magical, contextual user experience.  Flipbooard’s goal was that people would become so enchanted by the experience on first use, that they would be willing to wait for more complete functionality in v2.

This approach clearly paid off for Flipboard, but it’s a difficult one for many companies to embrace. We frequently have conversations with clients who try to cut user experience features and polish in order to put in more functionality.  Many of our clients ask us why they can’t have a product that works like an iPhone. If you remember when iPhone first launched, it also had all the polish and a limited set of features that were far less than current market leaders like RIM or Palm. However, by capturing people’s imaginations with amazing user experience, they were able to buy some time to round out their feature set in subsequent releases.

The lesson? Creating a beautiful, compelling, polished user experience for v1 takes guts. You have to be ruthless with your feature set and treat the user experience features as equal to the core functionality when planning your roadmap. We’ve often seen companies who have great design ideas cut those ideas at the last minute to squeeze in one more feature so it’s not a lack of ideas that’s at play here. It’s a matter of priorities.

Tips for Improving Greenbox’s Energy Portal

| 12.9.2009

A recent SmartGridNews.com article praised Greenbox Technology for “deliver[ing] understanding to utility customers.” While Greenbox does provide useful functionality that differentiates it from its competitors, key improvements to its interaction design would go a long way to provide a better overall user experience.

1_greenbox_original

The Good

To be fair, Greenbox does deserve a gold star for displaying energy data specifically in dollars ($).  As I mentioned in an earlier post, consumers don’t understand energy units, such as kWh, and are motivated to change their behavior by saving money.

costs_dollars

The Not So Good

But, what about the rest of the Greenbox design?   Greenbox gets caught up in the same usability pitfalls I’ve seen in other consumer energy portals as well –too much information and not enough direct reference to the things that matter most to users.  Here are my top three suggestions to help Greenbox, or any consumer energy portal, deliver an excellent user experience:

1) Simplify, simplify, simplify!

My foremost suggestion is simplicity. At first glance, the Greenbox interface looks very busy. There are many controls and buttons, and it tries to accomplish too much on a single page. Do users really need to be able to adjust their thermostat controls right on the main landing page, and also view their overview and data details at the same time? Instead, the home page could show only the most important information at first glance, and use color to further highlight and differentiate content on the page. The user can always drill-in to inside pages to access the less urgent information or access info on mouseover.

2) Engage users immediately with compelling content and proactive recommendations

My first response to the Greenbox dashboard is, “So what?”  I’m missing context to understand the significance of my data. For example, is my overall usage good or bad? Am I using more or less energy than I did last month? Am I on track so far this month? Also, the portal doesn’t offer any suggestions for changing my behavior so it’s unclear what my next step should be.

To engage its users, Greenbox should focus on delivering insightful content that immediately provides context and motivation. Delight users by anticipating their questions and displaying answers at-a-glance. Provide simple charts and visuals on the dashboard to compare energy usage to different time periods and to others in the community so that people understand why this information matters.

3) Adhere to basic design principles

In addition to overall experience enhancements, here are some basic user interface guidelines to help GreenBox or any other site be more usable:

  • Use clear titles Is the bar chart below showing data for all energy resource usage, just the electricity usage, or only heating and cooling (because that’s what is selected in green)? It’s hard to know for sure without a clear title for the chart.

title

  • Use visual cues to help users appropriately group related itemsThe content relationships on GreenBox are a little hard to parse.  For example, in the screenshot below, the “Heating/Cooling” button selected on the left side of the dashboard, actually updates the content shown on the right side, which is not immediately obvious.

similarity_before

Instead, GreenBox could make these two items more visually related to connect them. For example, put the same  green border around the box on the right and give both elements the same background color (see update below). Then, I would be much more likely to quickly understand their relationship.

Updated design with green box:similarity_after
  • Visually identify hyperlinks & interactive featuresTo help users understand what’s clickable, it’s important to differentiate hyperlinks and interactive features from other static elements on the page. For example, on the GreenBox site buttons and links currently use the same dark text color as other static elements, which makes them difficult to identify.

buttons_and_links

A Minimal Redesign Idea

If we take the recommendations above and do a very minimal redesign of Greenbox limiting ourselves to only minor changes to content and layout, we already begin to see large improvements in terms of usability.

updated_design

For example, in this minimal redesign, the relationships between content is clearer due to stronger visual cues and use of titles, the interactive elements more readily “pop” from the page, and inclusion of arrow icons begin to tell an interesting story about the user’s energy consumption.

But we’re not done yet…

Of course, it would take GreenBox more than just a simple redesign with no change in functionality to address all of our recommendations.  As a next step, I think Greenbox would benefit to take a more critical look at its overall structure and content to ensure they lend themselves to a good user experience – in particular thinking about the best items to put on the home page and trying to answer the question “So what?”

Will we see a new and improved Greenbox site in the near future?  We hope so.  In the meantime, let’s learn both from the things that Greenbox does well and from the areas that Greenbox falls short so that we can continue to focus our energy on creating intuitive, meaningful, and persuasive user experiences.

 

Related post: Watts all the buzz about smart grid energy?

6 Reasons Users Hate Your New Feature

| 11.13.2009

You spend months on a new feature for your existing product: researching it, designing and building it, launching it. Finally, it’s out in the world, and you sit back and wait for all those glowing comments to come in about how happy your users are that you’ve finally solved their biggest problems. Except, when the emails, forum posts, and adoption data actually come in, you realize that they hate it.

There is, sadly, no single reason why your new feature failed, but there are a number of possibilities. The failure of brand new products is its own complicated subject. To keep the scope narrow, I’m just going to concentrate on failed feature additions to current products with existing users.

Your Existing Product Needs Too Much Work

Ah, the allure of the shiny new feature! It’s so much more exciting to work on the next big thing than to fix bugs or improve the user experience of a boring old existing feature.

While working with one company, I spoke with and read forum posts written by thousands of users. I also used the product extensively myself. One of the recurring themes of the complaints I heard was that the main product was extremely buggy and slow. The problem was, fixing the bugs and the lagging was really, really hard. It involved a significant investment in infrastructure change and a serious rewrite of some very tricky code.

Instead of buckling down and making the necessary improvements, management spent a long time trying to build new features on top of the old, buggy product. Unfortunately, the response to each new, exciting feature tended to be, “Your product still crashes my computer.  Why didn’t you make it stop doing that instead of adding this worthless thing that I can’t use?”

Now, you obviously don’t need to fix every last bug in your existing offering before you move on and add something new. You do, however, need to be sensitive to the actual quality of your product and the current experience of your users before adding something new. You wouldn’t build a second story on a house with a shaky foundation. Don’t tack brand new features onto a product that has an unacceptably high crash rate, severe usability problems, or that runs too slowly for a significant percentage of your users.

Before you add a new feature to a product, ask yourself, “Have I fixed the major bugs, crashes, and UX issues that are currently preventing my users from taking advantage of core features?”

Your Product Interface Is a Giant Mess

Remember the old Saturday Night Live spoof commercial that advertised, “It’s a floor wax! It’s a dessert topping!”? It’s not as funny when it’s true. Products cannot do everything, and when they try, they end up with interfaces far too complicated for the average user to navigate.

I see this happen all the time, especially with startups looking for a way to make their product appeal to more people. Instead of improving their core product and adding features that enhance that experience, they add unrelated feature after unrelated feature, often stolen directly from more successful companies with larger user bases. Their goal is to find something that makes them blow up huge, but they just end up with an overly complicated product that tries to do too many things and doesn’t do any of them well.

It’s not just startups that suffer from this. Products that have been around for many years often get bogged down with feature after feature, all of which have to be supported because some fraction of the user base still uses it. These products then become vulnerable to new challengers with more focused, easy to use interfaces and smaller feature sets.

Of course, there are times when companies have to take their products in a new direction. For example, Flickr started as a set of tools for an MMORPG called Game Neverending. The game has ended, but Flickr lives on as an entirely different business.  PayPal began as a way to make PDA to PDA mobile payments, but that feature got killed years ago when they realized that web payments were a far better business model.

When you do find that killer feature that’s going to change your whole business model, commit to it and make it a serious focus rather than burying it under dozens of less popular features. Don’t try to be all things to all people, or you will end up with nothing but a giant, unusable mess.

Before adding a new feature, ask yourself, “Does this enhance my current product experience or just add to an already confusing and cluttered interface?” And, if it doesn’t fit with your current product offering but you still want to do it, ask, “Am I prepared to cut other features to make this part of my core offering and simplify my experience?”

You Didn’t Build What They Asked For

Let’s face it, sometimes your priorities are different from your users’. For whatever reason, be it a new business partnership, a need for a new revenue stream, or the desire to attract a different group of users, sometimes you’re going to build something that your current users don’t want and didn’t ask for.

This isn’t always a bad thing. For example, something that annoys your current non-paying users but attracts a whole slew of new, paying users is worth a few nasty emails to your customer service department. Just make sure that the new feature is really going to do what you think it will. It sucks to piss off your current, paying customers to build a feature that never really fulfills its initial promise. Trust me on this.

Before building a feature that potentially has more benefits to your company than your current users, ask yourself, “Am I prepared to deal with the fact that this is going to annoy some of my customers, and what is the real likelihood that I will get more out of this than I will lose?”

You Built EXACTLY What They Asked For

I know. It doesn’t seem fair. They’re angry if you don’t do what they want, and they’re angry if you do what they want.

The truth is that users will often ask you for a solution when it would really be more helpful to tell you that they have a problem. I’ve written more extensively about when you shouldn’t be listening to your users, but the upshot is that users aren’t great predictors of which brand new features will be big hits. Sometimes users will tell you that they want a toaster in their car, when what they really mean is that they don’t have time to make breakfast in the morning.

Before building a new feature that your customers are demanding, ask yourself, “What known user problems is this solving, and is this the best way to solve it for everybody?”

The Feature’s Not Finished

Now, I’m all for building the minimum viable product, getting it out in front of users, and then iterating on it to improve it, but some features just aren’t ready for prime time. By launching a half baked feature without key functionality, you’re running the risk of turning a lot of people off on the idea before they ever get a chance to really try it out.

Remember, your customers aren’t in the conference room with you when you come up with your grand vision. They don’t know where you’re going with this neat new idea. They’re judging the feature based on their first experience with it. Make sure that the first version is at least usable and hopefully that it’s far enough along that users can see the same promise that you do.

Also, good enough to ship doesn’t necessarily mean good enough to remain in your product long term. A big part of shipping early is continuing to improve the feature once it’s been out for awhile. One company I worked with had the tendency to ship early versions of features and then let them just sit there gathering dust, rather than iterating on them until they were truly high quality. What they ended up with was an enormous product that all seemed about half finished and a lot of unhappy customers who didn’t believe features would ever improve past version 1.0.

Before shipping a new feature, ask, “Is this good enough that users will get why they should care about it? And, if they do care about it, am I committed to improving it?”

The Feature’s Not Finishable

At many of the companies I’ve worked with, features have tended to evolve before they even get built. What generally happens is this: you have an idea based on something you’ve heard from users; that idea gets brainstormed and grows based on internal input; UX and visual designers spec out the whole idea, often expanding on the original idea; then engineering gets involved and gives a time estimate of how long the feature will take to build; finally the whole thing gets cut back by about 80% based on the estimates.

Unfortunately, the 20% you end up implementing may not solve the original problem. That means, when you finally announce your great new feature, users who originally asked to have that particular problem solved are justifiably upset.

Before drastically cutting your new feature back, ask yourself, “Does this still solve the original problem I was trying to solve?” If it doesn’t, ask, “Can this problem be solved with a reasonable level of investment?” There’s no shame in answering no to either or both of these questions, as long as you decide not to go forward with the new feature.

The Secret to Making Everybody Love Everything You Make

I’m joking. There’s no secret. The truth is that it’s almost certainly impossible. But by asking yourself the right questions during your feature development phase, you can dramatically cut back on time spent creating things your users hate.

And never forget, when you do build something they hate, acknowledge it, apologize for it, and fix it. It will go a long way toward making your users happy again, and it might even get them to like that neat new feature you just shipped.

Interested? You should follow me on Twitter.

For more information on the user experience, check out:

Watts all the buzz about smart grid energy?

| 11.11.2009

We recently worked on a new energy tracking site to help consumers monitor their energy use and find ways to save money. With President Obama’s recent announcement awarding a few billion dollars in smart grid grants, we expect to see an even larger effort devoted to creating new energy tracking systems and devices.  So, let’s save all of us some energy by sharing our top tips for creating a consumer energy portal.

1) Simplicity is key
We’re noticing that far too many of the new energy portals on the market are delivering complicated interfaces and busy dashboard-style pages with dense data charts and lots of buttons. Although heavy data, analysis tools, and controls might be interesting to data geeks, most consumers will find this information overwhelming or just plain boring. Consumers don’t want it to be rocket science just to learn to set their thermostat, and they don’t want to spend hours reviewing their usage details just to determine how they can save money.

A few examples of interfaces with too much data for consumers:

Greenbox
greenbox

Fat Spaniel
fat_spaniel_1

fat_spaniel_0

Tendril
tendril

So, we encourage you to simplify, simplify, simplify!  Anticipate user’s most common questions, then make it easy to find these answers. Highlight key information in an easily scannable format, and engage consumers with friendly language, like “How much energy am I using?” and “Is my electric bill on track this month?” If you have more data, you can always offer it on drill down for people who want to learn more.


2)
Present energy data in meaningful unit equivalents, specifically dollars
Which in-home energy device would you want to use in your home?

Option 1
HAN_1

Option 2
HAN_2

I bet you chose Option 2.

To engage consumers, phrase information in a way that makes sense to them. What we say has to be both measurable and meaningful. Consumers do not understand the electricity unit of ”kwH”, unless they’ve had considerable experience with it. And the words “tons of carbon” are just as meaningless even to those who are in the industry. Instead, all energy data should be presented in terms of dollars ($), with kwH and other meaningful equivalents shown as alternative views that can be visualized. For example, “You’ve saved $53.44, or enough energy to watch 362 hours of TV.”   Check out Chevron’s “Energy Generator” as another great example of how to present meaningful unit equivalents that consumers understand.

chevron


3)
Consider a “new user” experience
Most consumers have not had a lot of experience seeing detailed analysis of their energy data, so there is going to be a 3-6 month period of active learning for new users. During this time, users are going to be interested in identifying some basics about their energy usage. For example,

  • How much energy do I typically consume during a single day?
  • What is the impact of different items and behaviors in my home?

After this initial learning period, consumers will have a good sense of the basics that will remain fairly static over time, and will start shifting their focus to a different type of monitoring. For example:

  • Is my energy usage on track?
  • How does my usage now compare to my usage in the past?

We suggest that you recognize this consumer learning curve by considering a “new user” experience for your consumer portal.  The purpose is to educate users on their energy basics and to appropriately highlight information that is most relevant while they’re still learning, but might remain static overtime or become less interesting after initial use. Then, after this initial ramp-up period, keep users engaged by presenting an ongoing use experience that highlights the dynamic information they want to continue monitoring overtime.


4)
Deliver proactive recommendations with bottom-line savings
Consumers want to know what concrete steps they can take to reduce their energy consumption, and they want to know what impact those steps will have on their bottom-line savings. Our research has shown that people are highly concerned and knowledgeable about environmental issues, but their primary motivation is still saving money.  We recommend creating a predictive savings calculator based on actual energy usage that would allow users to see how various changes would affect their consumption and bill. Users could even use this calculator to help convince other household members to make the behavioral changes that matter most for their bottom dollar. Will the calculator show you which trade-off is right for you?  Probably not, but at the very least, it will provide you with your top options for having the biggest impact on your bottom dollar. You can take it from there.


5)
Offer a highly-visible, integrated in-home solution
In addition to creating a web portal for access to consumer’s historical data, we suggest also providing a highly visible point-in-time meter for integrated placement within the home. Consumers are looking for visible, real-time meters that can become an effortless part of their daily routines – much like their thermostats – because they know that everyone in their house has to be able to stay on track with one simple glance. Otherwise, it will be “one day up then one day down” instead of a forward-moving effort by everyone involved.

Also, remember what we’ve learned– keep the device simple, and present energy data in dollars and other meaningful equivalents, such as the following example from Energy Aware.
in_home

We hope you found these tips in creating consumer energy portals helpful. Think about it… talk about it… try it… and get out there and create your own green power designs so that others can give it a try, too.

Is Continuous Deployment Good for Users?

| 11.4.2009

The recent release of Windows 7 got me thinking about development cycles. For those of us who suffered through the last 2+ years of Vista, Windows 7 has been a welcome relief from the lagging, bugs, and constant hassle of a failed operating system. Overall, as a customer, I’m pretty happy with Windows 7. But, at least on my part, there is still some latent anger – if Windows 7 hadn’t been quite as good as it seems to be, they would have lost me to Apple. They still might.

A big part of my unhappiness is the fact that I had to wait for more than two years before they fixed my problems. That’s a lot of crashes and frustration to forget about.

One approach that many software companies have been adopting to combat the huge lag time built into traditional software releases is something called continuous deployment. This sort of deployment means that, instead of having large, planned releases that go through a strict process and may take months or years, engineers release new code directly to users constantly, sometimes multiple times a day. A “release” could include almost anything: a whole new feature, a bug fix, or a text change on the landing page.

I worked with a software development organization that practiced continuous deployment on a very large, complicated code base, and I can definitely say, the engineers loved it. From the point of view of the employees, continuous deployment was a giant win.

But how was it for the users? The fact is, some decisions that seem like they only affect engineering (or marketing, business, PR, etc.) can actually have a huge impact on end users. So, whenever organizations make decisions, they should always be asking, “how might this affect my customers, and how can I make it work best for them?”

Is Continuous Deployment Good For Users?

As with so many decisions, the answer is yes and no. Continuous deployment has some natural pros and cons for the customer experience, but knowing about them can help you fix the cons and benefit even more from the pros.

Big Customer Wins

Fast Bug Fixes

Perhaps the biggest win for users is that bugs can get addressed immediately. Currently, even Microsoft releases patches for some of its worst security holes, but there is certainly a class of non-critical, but still important bugs that have to wait until the next major release to get addressed. That means weeks, months, or even years of your users dealing with something broken, even if the fix is simple. In continuous deployment, a fix can be shipped as soon as it’s done.

Fast Things vs. Slow Things

Similar to the first point, continuous deployment lets you get everything, not just bug fixes, to users as soon as they’re ready to go. Small features, easy changes, and UI tweaks don’t have to wait for larger, unrelated features to be released to customers. After all, should a new design for the splash screen really have to wait on the implementation of a whole new payment system?

More Opportunities for Community Involvement

If you’re having a constant dialog with your customers (you are, right?), they’re probably making some pretty good suggestions about problems they’re having or ways to improve the product. A by-product of the first two benefits is that those users are going to feel even more involved in the development process when their suggestions or concerns are dealt with quickly, rather than if they have to wait months or even years for the next major release.

(Mostly) Avoidable Customer Problems

As with anything, continuous deployment can also cause some problems for users. Of course, some of these problems can exist in big, staged deployments as well, but these are a few things in particular to watch for.

Constant Change

Imagine if every day, the layout on your car changed, sometimes slightly, other times drastically. You want to drive to the store, but the steering wheel is on the other side and you’ve suddenly got an extra pedal. It would make it a lot harder to get where you were going, wouldn’t it?

Well, presumably your users are using your product to get something done, and they’ve got a certain way that they’ve learned to do it. Continuous deployment can mean that the interface for your product can change at any moment, even several times a day. If features constantly appear and disappear, it can be very disruptive to your users’ process.

There are a few things you can do to minimize the disruption. First, make sure that you’re testing your biggest changes on small cohorts of people. Iterate on a subset of your user base, rather than hitting every single user with every single change. This will limit the change that any individual sees while still giving you the benefit of constantly pushing code to customers.  In fact, use this as an opportunity to do the A/B testing you should be doing anyway.

Also, and this should be obvious, try to limit your truly disruptive user interface changes so that things don’t feel like they’re in constant flux. You can still change things, but be aware of how frequently you’re making major changes and stay in contact with your users to make sure they’re not feeling dizzy.

Inconsistent UIs

When a big new release is planned, often there is a comprehensive design phase where all the new changes are mapped out and discussed. This means that any inconsistencies in the UI can be found and addressed.

In continuous deployment, different pieces of the product are getting built and shipped to customers all the time, and there is rarely a time when the entire UI is reevaluated as a single entity. This means that sometimes UI standards can tend to…oh, let’s say evolve.

This problem can be controlled by having a UX team member embedded in the development team and constantly working with the engineers to enforce standards before things ship to customers. It can also be improved by providing wireframes, visual designs, and tools like templates to developers so that the look and feel of the product doesn’t shift too dramatically over time.

Avoiding QA

I’m certainly not claiming that every single thing in a traditional release process gets a full QA pass, but I do find that continuous deployment makes it easier for code to slip out to users without any human testing at all. Any time you give engineers the ability to ship code directly into production, you’re tempting fate. Somebody’s going to say, “oh, it’s just a tiny change,” and it’s going to get out without any testing. I’m not naming any names, but you only have to have a tiny change break the entire product once before you realize that there’s no such thing as a tiny change.

Also, continuous deployment can make certain types of testing much less likely to happen. While large release cycles tend to have a code freeze and weeks or months devoted to testing, hopefully including regression, unit tests, and end to end testing, continuous deployment doesn’t necessarily have that baked into the process.

You can always add periodic end to end testing of the product to your own process, of course, and it can be quite helpful in improving code quality, especially when your engineers occasionally slip through a “tiny change.”

Communication Issues

When you’re constantly releasing new features and bug fixes, communication with your users can be a challenge. You don’t have one big release with new help docs, a big roll out plan, and an advertising campaign. Instead, stuff is coming out all the time, and users can get overwhelmed by keeping up with the changes.

Context sensitive help and inline information for each feature can help users get quickly oriented.  Also, clearly marking new features as alpha or beta can let users know when a feature is still being developed so they can set their expectations accordingly.

Documentation can also easily get out of date when things are getting released constantly. Big, staged development cycles often have a built-in time for creating documents. Typically, manuals or help documentation and FAQs go through QA sometime after code freeze and before release. But since you’re not necessarily doing a big, monolithic release with continuous deployment, you can end up with this material never getting any sort of end to end editing to make sure they stay current. Make time for this. It’s good for both your customer experience and your customer support team.

Frequent Downloads and Updates

While continuous deployment is quite natural with web applications, even downloaded products can be constantly updated. However, you should always be aware of the burden you’re placing on your user base. If you’re forcing people to download a large file and go through an installation process too often, you’re going to annoy people.  As a personal example, iTunes appears to have a new version every week, and I’ve started to flinch every time I open it.

There are a few things you can do to make downloads easier on your users. First, you can ask the user to allow the update to download in the background and install automatically the next time the product opens. This means that the updating happens with very little user annoyance. Also, it’s best to keep the update quick by making the downloads incremental. For example, your virus protection software probably updates its virus information daily without asking you to reinstall the entire product every time.

So, Is It Good for Users or Not?

Continuous deployment can be done in a way that’s good for both engineering teams and users, but you do need to take some precautions. By taking care when you introduce changes that your users will really notice and making sure that you make time for important processes like QA, you can get features out faster and constantly improve your product. And that is very good for users.

Interested? You should follow me on Twitter.

For more information on the user experience, check out:

Why I Hate Paper Prototypes

| 09.16.2009

Ok, maybe hate is a little strong. Paper prototypes and sketches have their place in interaction design. For example, they’re great for helping to quickly brainstorm various different approaches to a problem at the beginning of a design process. They’re also a very fast and cheap way to illustrate a new idea, since most people can draw boxes faster than they can build interactive prototypes. But, in my opinion, they have several serious drawbacks.

Before I get too far into this, let me define what I mean by a paper prototype, since I’ve heard people use the term to refer to everything from sketches on actual pieces of paper (or cocktail napkins in a couple of cases) to full color printed mockups with a polished visual design. In this instance, I’m referring to a totally non-interactive screen, mockup, or sketch of any sort of application that is meant to be shared with customers, test participants, or team members. It can be printed on actual paper or shown on a computer screen, but whatever the viewer does to it, a paper prototype is not interactive.

So, what don’t I like about them?

Screen vs. Paper

This first couple of peeves apply to screens that are actually printed out or drawn directly on paper. With a few exceptions that I’ve listed below, I’ve found this approach to be really counterproductive.

Iterating On a Design

One of the biggest problems with hand drawn sketches on paper has less to do with user interactions and more to do with my work flow as a designer. Sure, sketching something quickly on a piece of paper can be quick, but what happens when I realize that I want to swap two sections of the screen? I can draw arrows and lines all over it, but that gets messy pretty fast. Whenever I want to make any changes to my design, I need to create a whole new sketch. This can mean redrawing the entire screen quite a few times.

If I’m creating a design in HTML or any other prototyping tool, the very first version might take a little longer than a quick sketch, but the second through nth iterations are a whole lot faster. And, as a bonus, I can check them into source control, which means I’m a lot less likely to lose my work than if I have dozens of pieces of paper scattered all over my office.

Interacting With Paper

Whether they’re sketched out by hand or printed out on paper, people interact with paper screens differently than they do with computer screens. They view them at a different angle. They focus on different parts of the screen. They use their hands to interact with them rather than a mouse and keyboard. Any feedback that you get on a printed design will be colored by the fact that people are fundamentally interacting with it differently than they would if it were on a computer screen.

Given all of these drawbacks, there are a few situations when designs printed on paper can be used effectively:

  • You are at the very beginning of the design process, and you want to explore a bunch of different possible directions with other team members very quickly before committing yourself to fleshing out one or two specific options.
  • You’re designing material that is meant to be printed, like brochures, user manuals, books, etc. In this case, you want to know how people will interact with the printed media.
  • Your product is an interface for some sort of embedded or small screen device that would be very difficult to replicate in a quick interactive prototype. For example, a screen for certain mobile devices or the heads-up display for a car dashboard might be hard to show interactively in the appropriate context.
  • You have several different visual designs, and you’d like to show them all to users at the same time in order to see which one is the most attention-getting. You’ll still need to show the designs on screen, of course, since colors can vary so much between screen and print, but it can be helpful to lay out several pieces of paper so that the various options can easily be compared.
  • You need to share screens with people in an environment with absolutely no access to a computer whatsoever. You know, maybe you’re in the middle of a meeting and need to sketch something quickly, or the rest of your design team is Amish, or you are designing in a post-apocalyptic wasteland where the computers are trying destroy humanity.

On the other hand, if you’re designing desktop or web applications for standard computers, at the very least, show your prototypes on a computer, even if they are not interactive!

A few reasons why it’s especially important to show interactive designs on a screen:

Animations and interactions

I am an interaction designer. A big part of my job is to determine what happens when a user interacts with a product. Sometimes that’s obvious. For example, if I click on a link with some text that reads, “Contact Us,” I expect to be able to communicate in some way with the people who have created the product.

But is it so obvious? Back in the day when links could only take you to another static web page, sure it was. But now, all sorts of things could happen. I might have different behavior on hover vs. on click. I could be given the option to have a live chat with a rep. I might be presented with an inline contact form so that I don’t have to leave the page I’m visiting. The contact form could have some information already prefilled for me based on my present location or account type. There could be animation involved in displaying the contact information. There could be some sort of contact wizard that would change later screens depending on choices the user makes initially.

All these interactions are much harder to convey with paper prototypes than with interactive wireframes. Sure, you can make a different screen showing each stage of the interaction, but with anything more complicated than a few steps, your observers can get lost pretty fast shuffling through papers. Having it all working in an interactive prototype allows users to click through and explore naturally. They can also discover things like hover interactions or animations on their own, which are particularly unsuited to paper.

Testing

What? You don’t need to test your designs with users? Your designs spring from your brain fully formed and perfect? Well, good for you. The rest of us mortals actually like to show our designs to test participants and get feedback from people who aren’t familiar with the product.

Now, I’ve run a lot of user tests. I’ve run them with working products, interactive prototypes, pictures of screens displayed on computers, pure paper prototypes, and physical mockups of products. I’ve used prototypes built with everything from HTML to Visio to cardboard. The one constant was that the closer the prototype mimicked the final product interaction, the fewer problems we found once the product was built. And since we recommend iterative testing during development rather than waiting  to test until the product is 100% built (you know, just in case your design wasn’t entirely perfect the first time around), an interactive wireframe is the best trade off of speed for functionality.

Communicating the design

You can have the best design in the world, but if you don’t communicate it effectively to the engineers who have to build the thing, it doesn’t matter one bit. Of course, once you’ve designed all of your static screens, you could paste them into a big spec with extensive documentation about what each button on each screen does and how many seconds an animation is supposed to take and blah blah blah. I’ve done it when it’s been specifically requested by a client. I’ve also never met an engineer who was particularly happy to read through one of those three hundred page documents. Besides, just the thought of making changes to every screen in that document every time there’s a change makes me tired.

An interactive prototype, when built intelligently, is a different story. It allows engineers to see exactly how every element of the design is supposed to work. What happens when you click on a link? Click on it to find out! Is the animation supposed to sweep horizontally or vertically? Take a look! Of course, you’re free to add notes to screens as necessary to fully communicate absolutely everything, but the difference between using this lightweight approach and a full design document for reference is night and day.

What’s the alternative?

So, what should you use other than paper prototypes? I’ve mentioned it throughout the post, but I’ll be perfectly clear. Your best bet is an interactive wireframe that mimics the behavior of the actual product as closely as possible. It doesn’t have to be hooked up to a database on the back end or use real data. It doesn’t even have to be fully functional if you’re only testing parts of it or if you’re annotating it with notes. But it should make the user, whether they’re a test participant, an engineer, or your design manager, feel like they’re actually performing tasks with the product.

Luckily, you’ll find plenty of products out there that will help you build interactive wireframes with very little technical expertise. You don’t need to be an engineer or a Flash expert to make your screens clickable. My favorite tool is Dreamweaver for creating quick HTML prototypes with basic animations and interactions, but other people have had good luck with applications like Axure and or even PowerPoint (although, that has some serious limitations).

There is, of course, one quick caveat. I know I’ve been harping on how closely your prototype should match your eventual product. However, you do not need, and probably shouldn’t have until quite late in the design process, a full visual design for your interactive prototypes. Why is that? Well, I’ve found that making the visuals look too polished can actually focus the user on the aesthetics rather than on whether they can accomplish a task. A lovely or flashy visual design can distract the user from interaction problems that you’d rather find early in the process.

For best results, focus on creating a simple, clean wireframe with as much interactivity as you can possibly give it. Your users will thank you for it.