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

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.

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"
  

Making the Redesign Case

Previously, I wrote about the old version of Sampa and how I came to the conclusion that it was necessary to create a completely new UI. But I still had to make the case for such a radical redesign and I didn't have the time (or the money) to run usability tests or create a variety of designs that I could compare. But, I did have a few things going for me:

• There was quite a bit of data about what people had used and not used in the old Sampa. Marcelo's built quite a stats engine. Of course, the data has to be taken with a grain of salt, but if something was particularly hard to do and users went through the pain anyway, I could pretty much assume it was valuable. I knew we needed to prune the interface and focus on the key features for our customers.
• There was a decent understanding of the target market -- probably as good an understanding as you can expect without the benefit of hindsight (it's always easier then!).
• There had been a lot of research about competitors and potential competitors and even some non-competitors. This enabled me to make a much shorter pass through them than would have otherwise been possible.
  
• Someone else had created a partial, rough proposal for the UI that went in the direction of making it look more like a standard Windows or Mac application. My inclination was to move in the opposite direction and seeing a fleshed-out version of the system as an app helped solidify my opinion.
• Finally, I knew I didn't have to create the final art itself. I was going to be able to work at the conceptual level and there were graphic designers who would make it look beautiful. This saved me a lot of time.
  

I quickly set out some primary goals for the new user experience. As much as possible, we would:

• ... accommodate easy exploration and provide users with the ability to tinker.
• ... give users both instant gratification and the ability to procrastinate.
• ... give users a warm feeling and a feeling of ownership.
  
• ... provide for both incremental construction and re-entrancy.
  

I also concluded:

• All editing and site management would be in context, but not in place. At all times, site owners would see the site pretty much like their visitors would see it.
  
• We would provide instant (one-click) access to the top things that users wanted to do.
• We would organize the UI around the way users think of their site.
  

This was all fine and good, but, in order to do the next step, I had to go out on a limb. Basically, I had to design (almost) the whole experience in order to show what it could be. If I couldn't do that, how could I convince anybody that it was viable? Even though I didn't have to create the final art, it had to look good enough to make the points and not be distracting. So, I did what any reasonable person would do -- I went home, closed the door to my home office, and spent a solid week drawing and redrawing until I was happy.

And the result? Not only was the redesign given a go, but the design was solid enough that we were able to proceed with implementation and final graphical design in parallel. Coming up, I'll talk more about the new design itself.

Here are two unmodified mockups from the set that I drew in those first two weeks, along with similar screen snapshots of the current live UI, plus one bonus image of the new UI.

A Few Hundred Options

They say a picture is worth a thousand words, so let's start there:

Unfortunately, this is just a part of the picture. There's more, lots more. Beyond what you see here, there are another 40 or so items that are available. Altogether, you can get to a few hundred possible options in two mouse clicks or less. You’ll commonly see a statistic like that touted to indicate that an interface is good.

But, it's not a good thing -- it's overwhelming. As a user, I don't know why I'm here. The things that are shown are all over the map -- ranging from configuration to content editing to status information that's not actionable -- and there is little to help the user get oriented, figure out how the system works, or accomplish the tasks that they want to get done. Although the options are organized into sections, the sections aren't parallel, which makes them less useful. The result is that it's a Winchester Mystery House of an interface.

I could analyze this interface to death, pick apart every piece of it and tell you every single little nitpicking thing that's wrong with it.

But I'm not going to.

So why am I showing this random interface to you? Well, in November, this interface became my problem. It's the old interface of Sampa, a web site creation service, and I joined Sampa to tackle it. So what did we do with the interface?

We tossed it.

And that's the real reason that I'm not going to nitpick the old interface. It's history. I wouldn't have joined Sampa if there hadn't been a clear commitment to make big changes, whatever they were. Paul and Marcelo (CEO and CTO, respectively) signed up. At the beginning, I'm not sure they really knew just how big those changes might be.

Even before I started, I had reached the conclusion that the interface was unfixable, but Paul and Marcelo hadn't. Just today, Paul reminded me that he had thought that I could just fix the old interface. This meant I really had to make the case for a new interface.

To cut to the end of the story, we launched a completely new Sampa today.

If you're lucky enough to be presented with a problem like this, I highly recommend looking at the big picture. You can't take an unplanned explosion and overlay it with a solid foundation. In the long run, you'll regret all the time you spend on bandaids. It's a big commitment (and you might have to make the case), but you need to build a new foundation and provide yourself room to grow. Next, I’ll write more about how I made the case and, after that, I'll discuss Sampa's new UI foundation.

I just wish I could solve the clutter in my garage as easily.

Update: Follow-up article: Making the Redesign Case
Press release about launch: PDF

It Just Takes One Good Way

Can't decide which way is the right way to provide access to a feature? Just support them all! We know that users have a hard time figuring some things out. It must be their fault. We also know that users, in general, don't read documentation. Obviously, that's their fault. But, if we support a lot of different ways to access the feature, surely one of them will work for users.

Take this example. How do you edit the blog post in this user interface?

Let's see. You can click on the pencil icon for the blog post ...

... or you can right-click on the blog post and choose Edit from the context menu ...


... or you could click on the blog post to select it and then click on the pencil icon on the toolbar.


Two of those three methods have an unlabeled icon for a non-standard operation (Edit), so it's just as well that there are three different methods. Oh, wait, I forgot. You can also double-click the line.

One Good Way

Instead of providing multiple not-so-great ways of editing the blog entry, why not just provide one good way?

If you provide a method which is clear and consistent, you don't need to provide alternatives. Notice I'm so confident you can find it, that I didn't even bother highlighting it like I did in the earlier examples.

Then why do we still support double-click?

Good question. We probably won't document double-click, but double-click happens to be a near-universal standard for editing. If a user does double-click the row, what would they expect to happen? Our choices are: something else, nothing, Edit. Let's take this point-by-point:

• something else - this is pretty unlikely. Double-click almost always means Edit.
• nothing - the user double-clicked. What is the chance that they did it just for fun?
  
• Edit - this is almost certainly what the user expects. Whenever possible, we should do what they expect.
  

But isn't it a good idea to provide multiple access points?

Sure, but that doesn't mean multiple ways at the same location. It means that there may be completely different places in your user interface where access to a feature makes sense. While changing this, we did add another access point -- at the blog entry itself. If you view the blog and you have permission to edit an entry, then an edit icon appears next to the title of the entry.

Notice that it's a larger icon than the ones used earlier, so as to make it stand out better. You won't see this icon on other blogs, so that helps too. If you move the mouse over it, it highlights and a tooltip appears that reads "Click to Edit this Blog Entry."

In Summary ...

The principles are simple:

• When providing access to a feature, provide a single, clear method in any given location.
  
• If users expect to get access to the feature in multiple locations in your user interface, then there's a good chance you should be meeting their expectations.
• If users expect a standard mechanism (like double-click) to work for accessing a feature, then you should probably make it work -- but don't rely on this for making the feature discoverable.