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?

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?

Lately, I’ve been trying to push the power of paper-prototyping. It’s a tough concept to get across though because some just don’t see the value. In fact, the customer, BA, Product Owner, just want you to show the customer a mocked up (coded) prototype. This is nerve racking because problems and issues in the design can be ferreted out much quicker using the paper prototyping method.

The overwhelming response to paper prototypes that I have personally faced is: They don’t seem professional, are hard to read, may be difficult to understand complex web actions. These people need to quiet down and listen. Paper is cheap and easy to modify on the fly. Paper prototyping is more than just showing a piece of paper. It’s about defining, refining, and streamlining the interaction between the user and the proposed widgets, functionality, etc. Paper and markers and traditional means can represent all these concepts with little difficulty. You just have to get a little creative at times, but the new ideas that come from these paper prototyping sessions can point you in a new direction.

Several times I have worked through a prototype with limited customer feedback(not recommended) and discovered core application function that was not identified. By discovering this up front you can better prioritize absolute functions from secondary functions. IE: I need to be able to save my book title, but I also need to give it a custom save descriptions.

Customer: “Wow, we never thought about that. We just wanted them to save the book using the title as the saved name.”

You may even discover larger problems such as entirely missing pieces of functionality.

If at all possible you should involve the end customer of your product. I’ve been trying to get this practice cemented into our process but it’s not an easy one. The general premise is this; everyone feels they are right and specs were translated correctly into business needs. It kind of makes sense that you need the customers input to ultimately test the system? However; this type of input rarely seems to happen at the level required. Focus groups, usability testing, is an afterthought and tends to be reactionary instead of proactive

Related articles:

1. Which Widget is the Right Widget for My Application Design?
2. When is it the Right Time to Use Icons?
3. Design Experiences: Don’t Rub Your Product Experience All Over Me.

more to come…

Related articles:

1. Agile UI Design: A Fundamental Miscalculation in UI Design Excellence?
2. Agile UI Design Series: UI Design in an Agile Project Cycle Part 1
3. The Haves, Have Nots & Feature Bloated User Experience.

Well, one method is this blog. That is one of the reasons this has been put out here. So here is the first design challenge. We don’t have many readers yet, but I have faith! Think of a complex design that you had to break down into an easy to use web application.

• Why was it considered not user friendly?
• Was the applications activity fully understood?
• Who was the user base?
• Was the technology proficiency of this user group under or over estimated?
• What do you think was your #1 reason for failing in this design?

My most recent experience is with an account application. I knew after spending over 15 different screen mocks and numerous in person sessions that the design was overly complex and we were trying to do way too much. I voiced this, but eventually just gave up under the weight of pushing the application through development, Quality Assurance, and into demonstration mode. I should have pushed harder, but so many voices were in on the design that it took on a solid form and any variation outside of what was deemed “approved” was not really up for debate. So I pushed on with the design knowing full well it could be better.

As it turns out the design was even complicated to implement programmatically. It was obvious that we had to take a radically different approach to this design. The business wanted to include so many features and I knew from my experience the usability of the application would suffer. After numerous issues of real internal users trying to use the application that had never seen or been involved in the intiial development. It was quite obvious that we needed to take another crack at it. So I came up with another 3-5 hours worth of designs. I was still adhering tightly to our existing model because code had already been written and we didn’t want to toss it and because we had to stay inside our approved design model and within the timeline. On this second pass, or maybe it was third I lost count. The same initial problems were maybe cleaned up a bit but within the existing framework there was not enough outside thinking to turn the app around. Features that were determined to be core feature sets were insisited to remain. Even though I felt how feature bloated the application was I could not make a dent in radically changing the design from what was the pre-concieved and accepted design.

I hope to someday go back and redesign this application, which probably currently only has an adoption rate of 1% users. And that adoption is not because of usability but because of shear necessity. That’s probably the #1 thing you will hear from developers and programmers it works! Working isn’t good enough, especially when you want to have pride in your design and the ability to make the task it was designed for quick and painless.

There were several reasons this design failed. The activity for which the design was built for became way to large. It was imposisble to account for every scenario even though the mentality was that we needed to. We should have focused on the the top 2-3 primary activities and make the application do those like a pro. Any other functionality should have been carried by the main application and not handled within the management. I knew this from the start but couldn’t get the dreaded buy-in I needed. And in a corporate environment buy-in is the key to getting your voice heard. Eliminating those less important features would have made the User Interface extremely flexible.

Another downfall revolves around the understanding of the primary application goal. My understanding became so muddled as we added more functions and features I started to loose site of the users and what they would be doing. I was trying to balance the primary features and elevate the lower level features as high as the primary application function. This caused a complete blurring of what the whole product was meant to do. And more importantly what path the user would take to complete task A – Subtask B – Subtask C – all in hopes of reaching end task F. Then repeating this cycle for another user. That looks complicated just reading it in text!

So please feel free to share your stories and info!

Related articles:

1. UI Design Lessons: Are You Driving Your Application Usability Off A Cliff?
2. The Haves, Have Nots & Feature Bloated User Experience.
3. The Most Important Questions to Ask When Building A Web Application UI.

Feature List That Needs To Exist On New Book Add Page:

User Needs:

• to add a new book in rapid succession
• to delete a just added book
• to Edit The New Book Entry
• to create new book categories
• to add reviews to the new book
• to maintain a registry of who has original book copy
• to search for books
• to manage categories
• to manage users

Now it’s quite obvious that some functionality may be used 1% of the time. And thus begins the battle between UI designer and business analyst or the client. The number one problem I have faced personally is unnecessary features in non-logical places. A virtual Swiss army knife. They client or BA may want a Swiss army knife, but what does that really mean. Well, if you have used a Swiss army knife you have to remember where all the tools are, and pull up the right tool in the right sequence, while making sure that other tools don’t get into your way. Basically, you have to find what you need by memory, or worse luck. Think how easy would be if you needed a knife and you had a pocket knife in your pocket and that’s all you had.

The same is true with our development process. Why should we put 20 features into one application process, path, when they may never be used by the common user. Couldn’t that time be spent on other application development cycles. Things like speed improvements, or gasp improving and revising your existing UI.

The hard sell in corporations and even to a client wanting you to build an application is the concept and mentality that “more is better.” Our application can do 50 things! What we fail to illustrate or tell is: it’s confusing as all hell to use, only 1% of our user base are advanced users and they might use more than 10 features in every given application usage sitting.

What can be done to convince these non-designers, non interaction developers, that more is not better? That tossing the usability out the window, or just tacking it on at the end is really not good enough? There are a few ways to do this and one way is to just let it all hang out and see what happens. Let the application go live and then learn from the failure. In a corporate environment you don’t have that luxury unless you hate the people you work with and you may.

Excluding the option above you need to find a way to convince these other groups that usability and the design of the application is more important then adding 50 extra features that 1% of users may use. So how do you do that?

Tune in later as I examine more on this topic.

Related articles:

1. SXSW Interactive 2008 – Day 1 March 7, 2008
2. SXSW 2008 – Day 2 Summary -
3. UI Design Lessons: Are You Driving Your Application Usability Off A Cliff?

Believe me I have seen some crazy ideas about what a “good application looks” and functions like. Next thing you know you and the rest of your team are throwing around generalizations about things such as:

• one color is better than another
• one navigation is better for the users than another
• one feature is more important
• one bug is higher priority
• design is secondary to function
• one technology is better to use than another

That’s just a short list. It’s easy to see how on a daily basis we encounter these conflicts that can disable, disrupt, and derail a development team. If your team is larger then 5 people this can drastically change your time line. How can you eliminate conflict? Well, the short answer is you can’t, but there is good news. You can begin to identify your sources of conflict and the impending arguments and cut them off at the pass.

Now every once in awhile there are members of a team that are not “team players.” They have such passion and zeal for their work that they cannot and will not back down. Even after reprimands, and threats, and warnings. Your final recourse may be to remove the broken wheel from your team. This happens in corporations as well as independent design teams. Sometimes there is just no recourse, and if you are in that situation and have exausted all your other conflict resolution chances, do you have the balls to make the decision to transfer, or remove the problem?

Stay tuned for more on this topic.

Related articles:

1. Features In The Front Usability Get To The Back
2. So what is this corporate thinkers site all about?
3. Blog Respose: Bowman Leaves Google

In addition I hope to provide concrete examples on user interface design as it pertains to web-based applications and consistent design patterns.   

Related articles:

1. So what is this corporate thinkers site all about?
2. Why Did My Design Fail Miserably and Other Not Nice Things?
3. UI Design Series 1: Web Application Design Where’s The Vision? What’s The Value?