Why Change Just to Change?

November 20th, 2007 § 0 comments § permalink

I regularly get my news from MSNBC.com. I read it daily. Well, let me correct myself, I used to read it every day. With all websites, MSNBC.com has a new look. The problem is they have traded glitz for usability and now I can see less news and what I can see is buried in clunky Javascript menus and slow navigation.

I get wanting to refresh your site, but was a usability lab done? Was it done with current readers? Was it done by monkeys? This new site is bad. Of course it’s pretty at first glance, but if you read my recent take on Apple’s design ideas, consistency is so important. Especially when you have hundreds of thousands of readers.

It sounds extreme, but MSNBC.com has lost me as a reader. I will move primarily to CNN.com now most likely for my daily news bits.

image image

Look at the consistent navigation, the lack of advertising above the fold, the quick headlines on the right. It was very usable and easy to read. Now there is almost an overload of headlines, the navigation is only half visible and if you move the mouse the site is obscured by very poorly written menus.

I know it takes a serious ego hit to roll back, but this design isn’t quite ready for prime time.

Editor’s Note: Historical preview brought to you by the Way Back Machine.

Thoughts on User Interface Design

November 14th, 2007 § 2 comments § permalink

On the heels of my not so friendly analysis of RedBox’s user interface and strategy in general, I thought I would share with you some of my thoughts on User Interface Design. One thing that I wanted to start with is an edited version of Apple’s Introduction to Apple Human Interface Guidelines. I know that we all develop for many more systems than Mac OS X, but the guidelines are fantastic and will serve you well no matter what your intended platform is.

  • Users will learn your application faster if the interface looks and behaves like applications they’re already familiar with.
  • Users can accomplish their tasks quickly, because well-designed applications don’t get in the user’s way.
  • Users with special needs will find your product more accessible.
  • Your application will be easier to document, because an intuitive interface and standard behaviors don’t require as much explanation.
  • Customer support calls will be reduced (for the reasons cited above).

Feel free to debate any of these, but they are simple, concise and accurate. I am not going to say that it’s too late to revolutionize interface design. I will say, attempt to do so at the risk of your application. There are plenty of proving grounds, user acceptance testing centers and general UI evangelists that would be able to help you define and refine a revolutionary approach to application interactivity. I would only ask you to be sure it’s the right time and place.

Don’t sacrifice familiarity for the sake of innovation
Take a look at Microsoft Office 2007. The new interface is a considerable departure from the interface that we have become comfortable with over the years. It is also strikingly familiar and closely adheres to the first guideline above. It adds new elements and design, while still having the ‘feel’ of the last few versions so you don’t find yourself wondering where everything went.

clippy You can also find an example of the second guideline in Microsoft Office’s history. Remember clippy? While clippy was an interesting concept, Microsoft Office was well enough designed at the time, that users didn’t need to be handheld through using it. Clippy was replaced with the sidebar in Office 03, accomplished the same task, yet somehow wasn’t as intrusive. In other words, it didn’t get in your way. I am sure that was a big lesson learned for Microsoft.

When I am designing an interface, regardless of a client side application or web based application or site, I begin by looking at other successful products in the same or similar genres. The point isn’t to copy or clone them, but to keep in line with what the users I am trying to convert will be expecting. The one thing you don’t want to do is introduce a product with a steep learning curve when you can avoid it.

I am a developer at heart, and I think like a developer. The first point I would address is to know your audience. Understand what their primary needs are, keep relevant features prominent and subtle ones deeper in the UI. Don’t try to place everything visible. Make it clean and usable, obvious and simple.

Tip: Take a notepad, draw a bubble in the center of the page that says features. Draw large bubbles around it for your core features. Base these off of an honest analysis of user tasks. Place the ones that are most important and most commonly used closest to the center bubble. In concentric circles, and smaller bubbles, place additional features around it. Add bubbles for configuration. Don’t forget that some configuration items could be commonly used so don’t place them too far away!

One thing I have found that helps is to create prototypes, segment features, concentrate on focused sections and don’t try to sew up a large application in one design initially.

Avoid Feature Bloat
Try to keep your application simple. As you are diagramming features, pay careful attention to the relevance to your core application’s purpose. Beyond increasing the size of your application, these incidental features that are potentially rarely used will be the items that clutter and eventually ruin your interface.

The best products are tightly integrated into the function the perform, making them simple to use and easy to learn.

During the design process, if you discover problems with your product design, you might consider applying the 80 percent solution—that is, designing your software to meet the needs of at least 80 percent of your users. This type of design typically favors simpler, more elegant approaches to problems.

If you try to design for the 20 percent of your target audience who are power users, your design may not be usable by the other 80 percent of users. Even though that smaller group of power users is likely to have good ideas for features, the majority of your user base may not think in the same way. Involving a broad range of users in your design process can help you find the 80 percent solution. – Apple Human Interface Guidelines

Test and test often
With your prototypes, it’s important to create internal and external focus groups for testing. These don’t have to be incredibly formal at first, just don’t allow your initial design to go to formal user testing without letting users outside of your core team give you their thoughts and ideas. Be sure to initiate criticism. Give your test bed a comfortable environment to point out flaws. Don’t let your friends tell you how cool it is!

Summary
In a lot of cases these are common sense guidelines. It’s important to keep yourself in the frame of mind that you are designing a way for someone to interact with a machine. Make the work that your application performs seamless so the user feels like he or she has an efficient tool to perform a task, not that the user is performing tasks to allow the application to take the credit!