Netflix Listened

This just in:

Wow. This is, unfortunately, a rare event. Netflix was adamant that the Profiles feature was going away, but they heard their users and reversed course.

"Because of an ongoing desire to make our website easier to use, we believed taking a feature away that is only used by a very small minority would help us improve the site for everyone. Listening to our members, we realized that users of this feature often describe it as an essential part of their Netflix experience. Simplicity is only one virtue and it can certainly be outweighed by utility." (from the Netflix blog: Profiles feature NOT going away)

My kids, who told me that the Netflix explanation made "absolutely no sense," will be quite happy. I still don't buy their explanation, but I guess it doesn't matter anymore. Now I can start thinking about that Roku box again. Bravo!

Extreme Makeover: Web Edition

I'm talking tonight at StartPad at 6PM. The topic is the Sampa redesign, which was an "extreme makeover" -- a complete redesign of the entire user experience. I'll be talking about the whole process, from end to end, including what decisions we made, why we made them, and how users have benefited from them. Plus, you'll be able to ask questions (be nice!).

There is still some space available.

Sign up here: http://www.startpad.org/wiki/startpad-countdown-7-extreme-makeover-web-edition

Users Don't Know What They Want

Years ago, I was called in to redesign the user interface for a very large system that a very large multinational company was building for a very large government agency in a very large state. Yeah, that's a lot of very large in one sentence, but I'm trying to give you an idea of scale. The company had developers in four states working on the project. They had some of the best and brightest architects working on the project, some relocated just to be able to work on the project. And the overall manager for the project was a stellar up-and-coming executive.

Yet, on this entire project, they had not one user interface designer. Not a single person with actual user experience expertise. The closest thing they had was a tester who, to his credit, had identified a number of the flaws. But, the flaws didn't really matter much. They were picky details on an interface that was fundamentally flawed -- because they had committed the cardinal sin of exposing their schema. The system they had built had an interface which was barely better than a raw database viewer. Every complexity and oddity of the underlying schema (usually necessary for good data design reasons) were plopped down right in front of the users. The client (the state) was very unhappy and on the verge of canceling the project.

Someone on the project had worked with me in the past and he suggested that they call me in to help out. Of course, I was stunned to learn everything I described above. But the real stunner came later.

You see, in addition to the hundreds of company employees, there were also four state employees working on the project. The very first thing that I did was to interview one of those people, who had been working on the project every day for two years. And I asked her questions that nobody had ever asked her!

For two years, she had been helping define what the system did. She had been spent thousands of hours answering questions and just as much time working on data relationships. They'd taken this government employee, this subject matter expert who knew nothing about computers, and made her into a schema designer! And nobody had ever asked her about her job.

Instead, they had, in essence, asked her what she wanted. She didn't know what she wanted. But, worse, she didn't know that she didn't know what she wanted. So, she answered their questions with information about the data of her job -- the details of her job. This was certainly useful information, but they could have gotten it from anybody. But the true expertise that she and her three state co-workers had not even been tapped.

In contextual inquiry, you are supposed to observe users in their "natural environment." It's sort of like going to a zoo and watching the animals. But your observation changes things and you frequently don't learn what you want to. Beyond that, you will miss things, even if you're lucky enough that the time you observe is a representative sample. And, for a typical product, there are many different target users and observing all of them is an arduous task. I think that contextual inquiry works best when you already have a product and are trying to improve it.

Fortunately, most people know a lot about not only their own work but the work of their co-workers. In the case of the state worker I interviewed, she had a pretty good idea of what everybody did, from top to bottom. The trick was in asking her about her work and the work of the agency, not her data, and certainly not how she thought the software should function.

It's Best to Iterate

Although I recently wrote that there is no best process for designing user interfaces (or, probably, anything), there are some best practices. Here's one best practice that I've boiled down to four words:

Define. Design. Refine. Iterate.

The iteration is the part that's most often missed. Far too often, designers think that they defined the whole problem at the beginning so all they need to do after that is to design it. But thinking doesn't make it so -- it's usually the case that the original definition missed some key elements. Sometimes it's just plain wrong.

It's much, much cheaper to iterate on the definition and the design before you ship something than afterwards, when your users tell you that you built the wrong thing.

NetFlix is a Service, Not a Web Site

Just got this email from NetFlix:


The "helpful" FAQ page says nothing that isn't said or implied in the email. In short: Profiles are going away, yes, they're going away, yes, all the features of Profiles will be gone, yes, you're screwed if you rely on Profiles. Of course, they took a little longer to say that, but you get the idea.

I don't know about the average NetFlix customer, but Profiles (multiple queues) are an essential part of the way I use NetFlix. I have four queues -- the "family" queue, which has movies for my wife and I and the family, my "workout" queue which contains movies that I think are good for workouts (and that nobody else in my family wants to see -- alternated with MacGyver), plus each of my kids have their own queue. They're responsible for their queues, including returning movies after they've watched them.

But, NetFlix has decided to kill the feature in order to "improve the NetFlix website for all our customers." How exactly does that work? You take away a feature that I rely upon and somehow that makes the website better? And I love that amorphous "better" -- trust us, it will be "better" in some unspecified way. What feature will they give me to replace it?

Will they provide a quick way to reorder my movies, because it sure seems to me that, without queues, I'm going to be constantly reordering movies in order to make sure I get an appropriate replacement movie whenever one gets returned.

Are they going to provide a feature that allows me to give my kids access to the queue, without letting them remove movies I've added or view R-rated movies? Or am I just screwed?

Or have they just decided that I'm not their target customer and I don't matter enough? Is it a tiny percentage of customers who were using queues? That won't make me happy, but, if that's the case, at least they could be honest about it.

Underneath all this, I'm really annoyed by the statement that they're improving the "NetFlix website." It makes me think that, after all this time, they don't really understand their own product. I could care less about the NetFlix web site and I bet that's true of 99% of their customers. I use the NetFlix service. The web site is just the way to get to the service and that's true whether the service is DVDs by mail or movies delivered over the Internet. To me, an important part of the service is a slightly better version of what we had at the video store -- the person who returns a video gets to pick a new one. For people like me, the removal of multiple queues makes the NetFlix service worse than the video store. I don't think that's what they want.

I've really been quite happy with NetFlix. I was just about to buy a NetFlix box for my TV, despite the limited number of available movies. Now I'm going to rethink that.

Final thought: It's possible that NetFlix has some amazing new design that will give me all of the benefits of Profiles in a different way. And that's what I care about -- the benefits, not the feature. But, given their messaging, I doubt that's the case.

NetFlix, care to enlighten us?

Update: Here's a post about this on the NetFlix blog, with almost a 1,000 responses already:
http://blog.netflix.com/2008/06/profiles-feature-going-away.html

Don't Fix Problems by Documenting Them

There's an old saw that says there's no such thing as a bug -- only obscure features.* Apparently, Yahoo! has taken this to heart. I have a Yahoo! email account I use, like, never. Sorry, Yahoo! (and my DoS** just asked me why I'm apologizing to an Internet service.)

In any event, in order to test an email configuration change, I needed to send an email from an account other than my own and other than GMail. So I logged into my Yahoo! email account and I accidentally agreed to upgrade to the new UI, whereupon I was presented with this alert:


I'll ignore the unnecessary cuteness of the figure on the left because there's a bigger faux pas. There's no way out! Surely, Yahoo! must really think it's important for me to see whatever it is they want to tell me. And what is it?


The thing labeled "Contacts" is my Address Book. Well, duh. That's what almost every other program calls it. If it's wrong, why don't they call it Address Book? Maybe they could use a larger icon that's a little more visible and a little clearer than a rolodex card ("what's a rolodex card?" says my daughter).


Use the thing labeled Options to set your Options. Gee, thanks! Is there a problem with discoverability? Maybe they should make it more obvious.


Use Check Mail to check your mail. Wow! Don't forget to tell me to use the pull down menu even though I don't have a pull down menu (because I only have one account).


To get help, use Help. Yeah, it's a tiny blue button. If people are having problems finding the help, give it a big icon. And, maybe, if it's a big issue, your software isn't quite as easy to use as you want it to be.

Fix the problems, don't document them. And even my daughter thinks the illustrations are just annoying.


*One of the first debuggers I used was actually named after this fact -- BOFF, the B Obscure Feature Finder was the B language debugger on Honeywell mainframes.

**DoS, apparently, means Daughter over Shoulder. PoS is much more common webspeak. And here I thought it meant Denial of Service.

Processes and Patterns

I don't know how many times I've heard arguments about the best process for designing user interfaces, particularly at large companies. What's particularly funny is that many proponents of different processes claim that their process is the best. But, if there are so many processes, how can there really be a best one? It's crazy -- there can't possibly be a single best process for designing user interfaces any more than there is a single best computer programming language for all purposes.

Design Patterns

If you're experienced at all in software, you've certainly heard about design patterns. I've previously discussed the Gang of Four's seminal Design Patterns book and Jennifer Tidwell's Designing Interfaces is an excellent book on UI design patterns. To me, these books are most effective sitting on your shelf.

I'm sure that sounds odd, but I don't think that these are reference books. The point of pattern-oriented design of any sort is to recognize patterns that you have used before (or, perhaps, others have used before) and not re-invent the wheel. If you use the pattern book as a reference book -- if you browse through it looking for a pattern that matches what you are doing, then you haven't really internalized the principles and you are just as likely to pick the wrong pattern as the right one. The fact that there are growing pattern libraries of thousands of design patterns is some indication that much of what we do isn't going to be in the book.

So, by all means, pick up these books and read them. But I really mean read them. Learn from them and then put them away. I will add the caveat that this is much more relevant in the case of UI patterns than in algorithmic patterns -- in the latter case, you could know you need a certain pattern but want a refresher on implementation details.

Back to Processes

By now you're probably wondering what design patterns have to do with UI design processes. Well, it's the same thing. The truth is that there are many different processes for designing user interfaces and the way to produce the best result is to pick the right process for the task at hand.

Don't worry, I'm not going to write a book on design processes and suggest that you buy it. But, next time you start a design project, think about how you start. Should you start by ...

• ... drawing pictures of what users will see?
• ... interviewing users and find out what they do without your product?
• ... observing users during the course of their day?
• ... making a list of every potential feature or sub-feature you can think of?
• ... drawing flowcharts of how users will interact with your system?
• ... creating a "road map" of future generations of your product?
• ... making a list of scenarios describing what your target users will do?
• ... defining a persona (or several) that describes your target users?

I'll add that I think those last two are two of the most overused starting points. That doesn't mean they're wrong, just that they get picked a lot more often than they should because they've been well publicized.

The most important part of the process is thinking about the process and picking the one that fits the problem at hand. And, certainly, don't refer to the list above, as it's woefully incomplete. If you've read this, I'll be quite happy if you put this blog post on the shelf.

Extreme Makeover, Web Edition

Regular readers of this blog have heard about the Sampa redesign. First, I wrote about the array of confusing options in the original Sampa UI and that the solution to the confusion was, essentially, to start over. Next, I wrote about making the case for the redesign and what it took to sell the design and make it happen. Last, I promised to write about the new design itself. But, as often happens, I never got around to that third post. I've been busy, and not just at work -- see thisTangent for a few of the other reasons.

And now ... sorry, but this isn't the third blog post either.

I still plan to write that blog post, but I've got something better for you. On June 24th, I'm going to give a talk at StartPad about the whole process. I'll touch on those first two topics, but I plan to spend most of the time on the actual redesign -- what decisions we made, why we made them, and how users have benefited from them. Plus, you'll be able to ask questions (be nice!).

You can get more info and to sign up on the StartPad site.

Reality isn't Reality TV

A couple of days ago, I wrote a post on thisTangent about teamwork and Learning from Reality TV's Top Chef. There's something that Richard Blaise said in that episode that I've been thinking about:

"Tough lesson to learn on Top Chef, you know, is that the goal is to bend each challenge to your strength, not to totally change your style to the challenge."

I think that Richard is spot on -- for reality TV. And I have to say I'm surprised that many contestants, and not just on Top Chef, don't seem to know that. A lot seem to operate at the two extremes -- either trying to be perfect for the challenge itself, as if they have no style of their own, or ignoring parts of the challenge to suit their own style. Quite a few contestants have been sent home for one or the other of these offenses.

But, reality isn't reality TV, and this advice doesn't work so well when thinking about user interface challenges. Too often, we see the sin of user interface designs that are bent to the strength or knowledge of the designer, not the needs of the challenge. Windows UI foisted on the web. Web UI stuck in a Macintosh application. Computer UI foisted on phones and cars and remote controls. Unlike reality shows, UI designs last a lot longer than the end of the episode and you and your customers will be living with your mistakes for a long time.

Interviews are the closest that most UI designers will come to being on a reality show. I remember when I interviewed at Microsoft, one of the questions that I got was the "universal remote control" question. It's a classic question and, for all I know, there are still people at Microsoft asking it. And, just like on Top Chef, you've got 30 minutes to "wow" the judge and whatever you come up will be tossed. But I hate questions like this -- the candidates jump to conclusions and try to impress the judges by naming lots of potential features, rather than digging in and thinking about what challenge really means.

For the record, the closest I came to asking the "remote control" question when I was at Microsoft was the "better coke machine" question. In short: improve the coke machine -- tell me what you will do to make it better, how it will be better, and who will be better served by it. Notice the what, how, and who, which allows the candidate to define and focus on a smaller set of improvements, without thinking they need to come up with as many ideas as possible to impress me. I'm not interested in tricking the candidate -- I want to learn how they think and how they go about the design process.

If I were trying to paraphrase Richard, I would say that a UI designer needs to bend their strength to the challenge, not the other way around. If you're not sure what the challenge actually is, you need to figure it out. Usually, figuring out the challenge is the biggest task (and the most neglected task, too). And if the challenge requires an expertise that you don't have, learn it, rather than trying to redefine the challenge.

Why is Blogger Hiding Things?

Blogger just introduced a new Dashboard in Blogger in Draft. Here's the main part of it.

And, to compare, here's the old dashboard:


I went to the Blogger in Draft blog to post a complaint but saw that plenty of people had beaten me to it. And what are we all complaining about?

I have to say I don't have any idea why they made this change. Yes, it looks a little nicer, but I can't figure out who they thought they were going to help by only showing the two most recent blogs. And they used a magic number of two -- where did that number come from? Let's look at potential users:

• Bloggers with 2 blogs or less -- these people won't even notice the change.
• Bloggers with 3 to 5 blogs -- these people probably rotate around their blogs, for a variety of reasons. For none of these people, can I imagine that "most recent 2 blogs" is a good set. For myself, I'm more likely to want the blog I posted on least recently to show up, as a reminder that I've been remiss in posting.
• Bloggers with 6 or more blogs -- these people are power users and probably have a variety of usage patterns, so there may be no way to satisfy all of these people (but we should try).
  

They also removed the total number of posts. I don't get that one either. Sure, it's not important to some people, but there is no other easy way to get that information.

I was initially surprised that, when I clicked Display all 3 blogs, they didn't remember that. In retrospect, however, that's correct. If they're hiding things and the things they're hiding changes over time, then I suppose they shouldn't remember that you hid anything. But that's a big IF and I think it's a flawed assumption.

What's the solution?

Well, there's the obvious one, proposed by a number of people commenting on the blog post about the new feature -- add an option to always show all the blogs. But, I've said before that every option we add to a user interface is a decision that we were unable to make during development. So, can we just do something that is so obviously right that everybody will just think it is the right thing? Sure we can.

First, we need to know what the objective is. I think the goal was to make cleaner, simpler, and smaller for users who have blogs that they're not posting to. I think they forgot easier to use, which should always be a goal because, if we forget that, it is way, way too easy to add features that actually make our products harder to use. And hiding things should never be a goal -- it should only be a way to accomplish a benefit, which it fails to do here.

Here's what I think they should do:

• Keep the new look -- it's fine.
• Show all the blogs, in most-recent-to-least-recent order.
• Collapse all blogs that have not been "touched" in the last month.
• Provide a expand/collapse icon or button to allow the expansion of any blogs that are collapsed. The collapse icon is probably not necessary, but having it there for symmetry is a good idea.

And what's the definition of "touched"? Any blog that has been modified to in the last month in any way (new post, editing of an old post, creation of a draft post, deletion of a post, etc.) or has been expanded in the dashboard is considered to be touched. The result is that active blogs are always available and dormant blogs are a click away. But even that click is improved because the click is on the exact blog the user wants and they know where they controls will be after the click, rather than having to click the expand button and then look through what's appeared.

A change like this would not even be noticed by most users -- it would just feel right. Users with multiple, active blogs will see no change. Users with dormant blogs will have them taking up less space and won't mind that. Even power bloggers with lots of blogs, will get the right behavior for both their active and dormant blogs. It's a win all around.

In short:

• Focus on the real goals of your UI change.
• Make sure that "ease of use" is always (or almost always) part of your goals.
• Aim for a change that just feels right -- that people will just say "that's the way it should have been in the first place"