The Haves, Have Nots & Feature Bloated User Experience.

Imagine with me a minute that you have just identified in your Book Keeper 2.0 web application that too much information and functionality is jammed into the “add new book” page. The business analysts insist that everything needs to be available to the user. They “need” to have the ability to do numerous things on 1 particular web page.

Book Keeper 2.0 – Keeping Books Since 2006

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?
4. User Experience Design in an Agile Development Cycle
5. Book Review: “The Visual Miscellaneum” – Explore The Design World of Infographics In Only A Few Moments