Usability is nothing new. What is new is the use of the term usability by anyone and everyone. It has become the de-facto buzzword across the design world. There are so many definitions and differences of opinion across the web on what usability actually means. Let’s take a look at the dictionary definition:

Websters defines usable as the following:

1. capable of being used
2. convenient and practicable for use

As UI designers, we draw upon a few more concepts to define this idea further. My personal definition takes into account the following:

• Learn-ability
• Memorability
• Performance
• Expected Interactions
• Consistency
• Repeatability

Yes, I know that’s a lot of “abilities”.  I will discuss this in future articles,but right now let’s just focus on what falls into the category of usability from an application standpoint and how it can directly impact adoption of our application.

Here’s A Feature, There’s A Feature, Every where’s A Feature

Many notable UI Designers, Interaction Designers, and User Experience Designers have talked about the problems of “featuritis.” The term simply refers to the rapid increase of features beyond either application need or user desire. This can occur to almost any product you can think of.  The goal is to minimize and avoid user frustration by understanding what it is the users really need. After you have identified what is needed it’s important to categorize your features, functions, etc into primary and secondary interactions ( I will talk more about this in a future article.)

Even The Best Applications Have Skeletons In The Closet.

Let’s examine some existing products on the market and identify some problems with these applications. Im sure many of us have used Illustrator, Photoshop, 3dsMax, or Bryce. These applications have a high user competency. You may need classes, formal training, and many years of experience to produce professional results. That is not to say these companies have “driven usability off the cliff.” In fact, many follow the same “menu” toolbar structure seen in 100’s of applications. Each application may have their own slight twist and or added access to complex functions. Regardless, there is no doubt a very important process has taken place at some point during the development of these applications to priortize the location of menu features. Hopefully, this process involved usability groups to actually figure out what the priorty was.

Take 3Ds Max for example. 3DS max is aimed at highly competent designers with modeling, mathematical, computational, and visual skills.  One version of 3DS Max I’ve used contained many complex context menus with alternating functions to complete as expected complex design modeling tasks. Personally, I’m glad I’m not a 3D modeler working with Max or Maya. The interfaces may be some of the most difficult UI’s I have ever encountered. Multi-Tiered cascading menus, complex keystrokes, and alternating views of wire-frames.

Let’s take a look at Photoshop. Pretty much every designer I know has used this behemoth of an application. The sheer power of the tool led to a lot of acceptance of any short comings. Yet, with the creation of CS 3 Adobe redesigned many core menu structures. One simple example is the tool bar that can now be set to a single strip along the side. This was one of my pet peeves. I would frequently run into the tool bar constantly being in the way. This small change (to the user interface) has saved me many minutes of productivity, and eliminated a major annoyance.

We The Users Will Not Stand For UI Mediocrity

Alan Cooper’s Book “The Inmates Are Running the Asylum“-(published in 1999)  talks about the complaceny users of software faced when working with web applications. of course, it is now 2008 and a more recent study by Jakob Nielsen points out that users have lost thier patience. No longer will users stand idly by and wait for that 30 second flash splash screen to load. Poor UI designs and convoluted interfaces, face a growing demand to be made better. It’s our job as UI designers to improve and invent new and easier methods of interaction. If any feature proposed as a usability enhancement fails it is much easier for users to swich prdoucts.

There was a time in the past when humans were pleased by simply improving complex processes with the use of a computer and software. The novelty has worn off, and now users expect much more out of the software they buy.

Think back to the last time you waited for a web page to load. Did you wait patiently? Maybe you tried to click faster in hopes the page would load faster. If you are like me, you simply go to one of the billion other web sites.  It’s reasonable to assume loyalties will shift and applications that fall to the road-side and allow usability to suffer will ultimely loose users.

The Dreams That Dreamweaver Dashed

For many years I was an avid Dreamweaver user. The tool allowed me to code faster than notepad, and did not overwrite my code. Adobe became comfortable with it’s lead on the market and the tool never really pushed the bounds of innovation.

Each subsquent upgrade lead to more features, but what I really needed now was a tool that could read my complex CSS style sheets and visually give me a good in program rendering engine. This would allow me to not have to constantly switch back and forth to my browser to check my designs.

So after years and years of program use I switched to Expressions Web. The CSS rendering engine was  amazing. Sure, it was an entirely new interface to learn not to mention Microsoft’s insistence this was not a FRONTPAGE tool but instead was directly aimed at professional designers. I hesitated making the final switch, but haven’t looked back. That being said now Expressions is falling behind on delivering the best software experience. I may have to take a look back at Macromedia.

Don’t let your software and usability become a fat pig. Conduct usability groups and determine where to go next with your application. When you have your list of features be cautious.

All Features Are Not Created or Treated Equally

Imagine you are in the market for a new luxury car. The list of features reads something like this:

• Power Steering
• Anti-Lock Brakes
• Rear View Mirror Camera
• Internal GPS
• IPOD Connection
• Stereo CD Controls
• Cruise Control
• Defogger
• Air Conditioning
• USB Ports
• Extra Outlets
• Block Heater
• Light Panel
• Spare Tires
• Microwave Oven

This is a top of the line luxury car. It has items you may never need. The engineers believed it was best to have two spare tires. One attached to the roof, and one in the trunk. They reasoned with the manufacturer that because of all the extra features the tires are not the best quality, but we did get all the features in. Occasionally, the operator of the vehicle may turn on the brights when adjusting the radio. They may short out the battery if too many items are plugged in to the outlets. They may burn fuses, but “everything” asked by the car manufacturer was included. Some pieces are less reliable then others, some have some major bugs, some even may cause system failure.

You may laugh at this example, but sadly it is very true. So many times features are the prized cow at the fair. They are the desired outcome of a super speed, fuel injected, development cycle.

Now let’s fast-forward a week later to the purchaser of this vehicle. His initial reaction was WOW it offers me all of these things? That’s a lot of stuff. Sure I may not use many of them, but oh well. I may need them some day! (just what the engineers, and developers wanted them to think). In The past they would have drank the kool-aid! OH YEA! Today that car is going right back and guess who just lost a sale and millions in investmetns?

The next time you want to jam that feature or expand that application. Stop! Think a moment about what the cause and effect will be.  Not to just the current implementation but future expected implementations. You may just prevent your application from careening off a cliff!

*Author’s Note – Due to the size of this article I was a bit late in publishing.

Related articles:

1. Features In The Front Usability Get To The Back
2. UI Design Series 1: Web Application Design Where’s The Vision? What’s The Value?
3. Design Lessons: Should You Rush Your Design To Market or Stall it for Great Design?

Why Use Icons?

First a brief synopsis of why you may want to use icons.

• Icons are meant to increase the speed of visual scanning
• Icons should be the same size and used consistently across your application.
• Some icons are so recognizable: print, save, it becomes common sense. Frequently though when building a new application you will find the need to develop your own icons based on new functionality.

So how do you know when to break out the design tools and create some new icons? Here are some common indicators that let you know it’s time to possibly look at branding icons across your application.

When To Use Icons

• The functions you are representing are common and existing mental models. Icons that fall in to this category include print, save, pdf etc.. Pretty much everyone on the web can identify a print icon and understands that something is going to get printed when clicked.
• If space is tight in your application and future implementations may make this problem worse. In this case you really need to look at the application as a whole (we will be doing this in later examples) and identify similar functions idea for icons.
• If using an icon would help spatially an visually withlearn ability. An example of this would be if there are many secondaryfunctions in your application in the same area. In this instance too muchtext even if the text clearly states the function can hinder the visual recognition.

Studies have proven humans can recognize pictures faster then text.

Things You Should Do With Your Icons

• Do make all your icons similar across your application or brand
• Do make all your icons adhere to the same size when in proximity to other icons.
• Do use size in order to emphasize function prominence or importance
• Do use standard icon sizes 12 x 12 16 x 16
• Do make sure icons mean something
• Do test your icons & icon sets to make sure users can quickly identify the function

Things You Should Never Do With Icons

• Do not make icons blatantly different in the same applications or brands
• Do not over use  icons purely for decoration
• Do not use icons if you are unable to visually depict the function
• Do not change functions of an icon across your application or brand.

Are You Convinced?

Hopefully you have a quick idea about when you should use icons. There is no cut and dry path, but the guidelines above will help you to identify icon requiring situations or solutions.

Related articles:

1. How Can I Speed up Proto-typing & Visual Design Mocks with Hybrid Design Proto-typing?
2. Which Widget is the Right Widget for My Application Design?
3. Did You Know Paper-Prototyping Adds Value If Done Right?

Think of it like Jenga. In the game Jenga you must pull out the bottom blocks and place them on top. Every time you place a new block on top the structure becomes shakier and is unable to support the weight until it eventually all crumbles to the ground.

Imagine an application that is under this same pressure. You start out developing and have an ok UI that “seems” to support the weight of the tool and then you release the product to the consumers. They begin to complain of slow load times, confusing UI interactions. Back in the design room discussions are held about how to improve the usability. And the #1 thing brought up is add new features. No, No, No!

Take another look! You may not need to start from ground zero but, the foundation on which the application has been built is weak and trembling already and about to collapse. The last thing you should do is throw more weight on top of the impending disaster.

This is exactly what seems to have happened in more places then you can imagine. You eventually reach a point where the application looses it’s ability to scale to the increasing features. Sometimes you have to just close your eyes walk away and wait for the impending I told you so.

At this point you should be utilizing real user feedback, comments, and in house usability testing first hand to see what problems are plaguing the user. Sure some features that may be missing may be the culprit, but more often then not the tasks we perceived to be simple are way too complex and the base functionality of the application MUST be revisited to support future growth.

Kathy Sierra talks a lot about this in her blog.

I still have yet to find ways to counteract this line of thinking, but it’s just human nature – more is a perceived better. Any more ideas on how to combat this line of thinking?

Related articles:

1. Corporate Conflicts A Cantakerous Cacophany of Confusion.
2. Why Did My Design Fail Miserably and Other Not Nice Things?
3. UI Design Lessons: Are You Driving Your Application Usability Off A Cliff?