Jakob Nielsen explains why saying “but it’s cheap!” is not a good excuse for the Kindle Fire’s bad user interface design:

The difference between user interface design and hardware specs is that better usability is derived from one-time expenses for user studies, design iterations, and coding – whereas beefier hardware (say, adding a camera) is a repeated expense for each additional unit manufactured.

This means that even cheap devices can have great usability because the cost of better research and design is amortized across millions of devices. This is why usability has stupendously high ROI for any big project.

I also like John Gruber’s take on the hardware/software distinction:

[T]hat’s the advantage of software over hardware. You can omit an essential feature and then hustle to get it into your first major update. Good luck adding volume buttons to your Kindle Fire.

Does this mean it’s ok for the first version of the Kindle Fire to have a low-quality UX? Here’s Nielsen again:

I understand why Amazon might want to ship a poor product in late November rather than a good product in February: they want to catch the holiday shopping season. Whether the extra sales are worth the brand damage from a low-quality user experience is difficult to judge.

Amazon has a history of doing this kind of thing. The first Kindle eReader was not a great product, and it didn’t get good reviews. But they kept at it and turned it into something truly great.

This points to one of the main differences between Apple and Amazon. Apple waits until an experience is as close to perfect as possible before they ship. Amazon gets something out there as soon as possible, but then – and this is important – they don’t just move on. They keep working at the product until it reaches an experience they’re happy with.

Both companies are very successful despite their different philosophies on when to ship a product. It proves that we should get over this idea that everyone should just copy everything Apple does. There’s more than one successful business strategy.

I’m sure the Kindle Fire will follow the same trajectory as the original Kindle eReader and become a great device. Eventually. Still, let’s not kid ourselves – the current one isn’t great.

I completely agree with Gabe Weatherhead’s views on apps made for kids in The Value Of App Reviews:

My number one reason to give a bad rating and review is when an app made for kids has both up-sell and review requests plastered all over the screen. They are trying to prey on small children tapping anything that pops on the screen. If you make a kids app, do not put links to your other apps in the game. Put them in the preferences. Put them in the app description. Hell, put them in some kind of app documentation. But when they are in the game, you are telling me that you’re shady and unscrupulous and I can’t trust your app.

This is a dark pattern, and I simply delete the app if I come across this kind of design. For some better patterns to follow when designing apps for kids, see Luke Wroblewski’s Touch-based App Design for Toddlers.

∞ Permalink

Alex Faaborg for UX Magazine in Debating the Fundamentals: The geographic, temporal and political nature of usability heuristics:

On the surface, usability heuristics provide a simple checklist for making any interface perfect. But what is fascinating about them is the extent to which all of the heuristics are actually in direct opposition to each other, the extent to which they are geographic and temporal, and the extent to which they expose the designer’s underlying political views (at least in the domain of things digital). Usability heuristics present a zero-sum game with inherent tradeoffs, and it is simply impossible to achieve all of the heuristics simultaneously.

This is the best UX article I’ve read in a while. Like most UX designers I live and breathe the usability heuristics, and have always been reasonably comfortable with the tradeoffs, but this article perfectly articulates the complex interplay at work.

But it’s not just a theoretical exploration, I really appreciate the thought put into the practical approach to managing these complexities:

Novice designers memorize the list of usability heuristics and try to employ them in their work. As a more experienced designer, you may have already seen a deeper dynamic at play here. Instead of using heuristics as a simple checklist, try placing pairs of the heuristics against one another in a spider graph.  Achieving every ideal isn’t possible because the pairs exist in direct opposition. Realizing this, the challenge shifts to shaping a design that captures as much surface area as it can, given all the opposing forces.

This is one of those “I wish I wrote that” articles.

∞ Permalink

“DStv: so much more user-friendly,” says the ad in the background as I try in vain to press the button on the remote control just right so I can pause my show and go get another cup of coffee. It probably has something to do with last straws and camels and stuff, but that ad finally put me over the edge and onto the computer to write about the user experience of DStv’s remote control for their HD PVRs.

It is often much easier to figure out which companies practice user-centered design and which don’t when they produce physical products as opposed to online interactions. Think about Target’s redesign of the prescription drug bottle as an example of deliberate design, and America’s 1040 Tax form as an example of what happens when there is little to no design input on a product.

In the past I’ve had the pleasure of using the Logitech Harmony 880 universal remote, pictured below beside the DStv remote, and that showed me that it is, in fact, possible to design a remote that even my mom can use. So I’d like to write about the differences between DStv’s remote for the HD PVR’s, and the Logitech Harmony 880 universal remote. Both are shown below:

DStv HD PVR remote	Logitech Harmony 880 remote

The DStv remote – Why it’s bad

The DStv remote control breaks many principles of user interface design, but mainly this one: Recognition rather than recall. To quote Jakob Nielsen:

Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

The principle applies mainly to online design, but it can be applied to the DStv remote in the following ways:

• Several buttons have no proper affordance and mean nothing to the user. There are 5 different-colored buttons with no mapping to the real world, and some labels are confusing. As examples of interactions that are not obvious to the user without either reading the manual or extensive trial-and-error:
  • To view your recorded shows, you have to press the red button.  How am I supposed to know that?
  • To make matters worse, once you see a list of your shows, this same red button is used to delete the show.  And that’s how we lost the latest episode of 30 Rock.
  • To edit certain (but not all) settings, you have to press the white button within the menu system.
  • At other times, the white button is used to edit your favourite channels.
  • When you pause or rewind a show, you go back to live TV by pressing the “TV” button.
  • The “up” button brings up your favorite channels, while the other direction buttons bring up all available channels.
• Several buttons don’t do anything at all. I haven’t seen the blue, yellow, and green buttons used for anything. It’s not uncommon for remote control buttons to be “reserved for future use,” but I maintain that this is a bad idea because it just introduces unnecessary user complexity.

In addition to that, the play/pause/forward/rewind interaction is awkward. To pause live TV, you have to press the button exactly in the middle, otherwise you might actually start rewinding or forwarding.

Making the fast forward action a pull action instead of a button you press might sound like a good idea, but doing that limits its function. Now you can only fast forward on one speed. If this becomes a push-button, or something other than “hold to fast forward”, you’d be able to fast forward at different speeds.

And this is only the remote… once you get to the on-screen experience the interaction reaches a whole new level of “what the…!?” Maybe we can dig into that at another time. But first, here’s how it should be done:

The Logitech Harmony 880 remote – Why it’s good

• Beautiful, ergonomic design that makes you actually want to use it and not hide it under a pillow.
• Progressive disclosure of features — depending on your activity the “soft keys” at the top of the remote perform different functions, with clear language on the display to indicate which button does what.
• Online programming of the device — no need to remember device codes to set up the features for each component.
• Thoughtful key layout with no ambiguity about which button does what.
• Several smart features, like starting the backlight when you lift the remote off the table.
• User language incorporated throughout — simple commands such as “Activities” and “Watch a DVD” instead of technical references.

It’s clear that Logitech did some user research to find out what the underlying user needs were before they developed this product. A lot of the features can be directly linked backed to complaints I’m sure we all have about remote controls. A couple of examples:

• “I can never see the buttons on the remote when it’s dark in the room, but I also don’t want the light from the remote to disturb my viewing.” Solution: motion sensors that turn on the backlight when you pick up the remote, and turns it off after it’s been sitting still for a while.
• “I don’t want to have to struggle with device numbers and complex remote programming”. Solution: build an online interface where the user can program the remote, and then send the commands to the remote through a USB connection.

There’s probably more to say, and yes a lot of arguments to be made for why DStv’s remote isn’t that good. But in today’s user-centered world, there shouldn’t be excuses any more. Companies need to make products that are useful and usable so that people can enjoy them without frustration. Good user experience = good business.

I do want to end on a positive note and say that I think the DStv iPhone app is a solid piece of user-centered design.  It doesn’t go overboard on features, and it keeps focused on the one thing users need it for — checking TV schedules.  I just think the app designer needs to take a look at the remotes, that’s all.

As designers and user experience practitioners, most of us can look at web interfaces and immediately tell the good ones from the bad ones.  The good ones are usually an indication of execution built on a collaborative and equal effort between different groups and stakeholders.  The bad ones usually point to one of two things:

• The site was chopped up and different teams owned different parts of the same pages without a clear plan for holistic design; or
• Somewhere along the line relationships turned sour, decisions got escalated, and one of the groups/stakeholders won a contentious argument about the design of the product.

I came across one such example of poor execution today while browsing the MSN Mobile web site on my iPhone.  Here is what I saw:

Notice that there are (or appears to be) four editable form fields on this screen:

1. The Safari address bar
2. The Safari Google search bar
3. The small MSN search box
4. The big Bing search box

There should be little confusion with the first two fields — they are part of the Safari browser and clearly not part of the mobile web content.  However, the other two search bars present several problems.  Notice how both have the little magnifying glass search icon, indicating that you should be able to use both to search.  The questions users will ask themselves are, which search box should I use?  Do I want to search MSN or Bing?  What’s the difference between these two search boxes?

I’m sure most of you have also figured out what’s actually going on here — the Bing search box is not a search box at all, it is a clickable advertisement (pre-filled with “Miley Cyrus” for some reason, but let’s leave that out of the discussion for now).  It’s also clear from what we know about affordance that the user is encouraged to use the Bing search box due to its prominence, size, and iconography that’s consistent with search behavior across the web.  I think we can all agree that this is just bad usability, plain and simple, but I also started thinking about how something like this could happen.  I can think of two scenarios:

• Informational content and advertising are owned by different groups. It is very likely that the advertising team were given the top banner placement on this page, with not much oversight about what they put in there.  They likely have their own designers who design for the advertising team, with no need or desire to think about the context of the entire page.
• Revenue goals trump good usability.  Another possibility is that the designers are fully aware of this issue, but that Bing, possibly a different business unit than MSN Mobile, has strong revenue goals that they have to meet for their advertising campaigns.

Or it could, of course, be a combination of these two scenarios.  I think we can learn some very important design lessons from this seemingly innocuous usability flaw:

• Never design in isolation.  This is such a simple principle, but it is still so remarkably easy to guess a company’s organizational structure just by looking at their web site.  Siloed design is one of the easiest design problems to fix, but it does take some courage: strong product management, a sincere desire to collaborate across business units, and an executive mandate to make it happen. All the MSN team had to do was get the designers/PMs together and design a Bing ad that fits with the page structure and doesn’t cannibalize search queries that should go through the MSN search box.
• Aggressive revenue goals are not an excuse for bad design. As a user experience product manager, I am a realist and completely in favor of feature prioritization and pushing for meeting aggressive revenue goals.  But revenue-generating features should never be implemented at the expense of the usability of your web site. Too often we see examples of poor implementation of an interface because the team couldn’t find a way to reconcile the business goals with proper user-centered design.  I believe the MSN Mobile example is such an occasion.

But wait, there’s more!  Unfortunately, the MSN Mobile example then goes from bad to worse.  Clicking anywhere in the Bing ad brings up this page:

There’s just not much you can say about that.  At this point you’ve lost customers who could have done their searches through MSN Mobile.  Game over, everybody loses…