World Usability Day is November 14th!
By pmonday on Nov 13, 2006
November 14th is World Usability Day! If you don't know what usability is or why it matters, there are some great posters at the World Usability Day web site. The posters are, of course, geared to the broader topic of usability as it touches us every day. As a computer guy, I am occasionally responsible for influencing (and occasionally controlling) how "usable" our products are to the consumers.
Usability in software products is a competitive differentiator, especially in a bid situation. There is a finite amount of time to make an impression on a user and if they cannot properly interact with a system to achieve their goals, you will be thrown out of a bid.
Often, software engineers believe that they can build a usable interface merely because they are good at putting widgets together and understand the functionality of the product. Unfortunately, the combination of "knowing" the functionality of the product and being able to whip together a "user interface" can be a dangerous combination. As I've been shown over and over, an engineer's gut instinct is to represent all of the components within the software and all of the possible object attributes, then uplevel these to the "user". This works great for the developers since the product functionality is relatively easy to test.
Unfortunately, this often does not work well for the REAL user of the product. User interfaces built by software engineers are often complex for real-world users and don't take into account how a user would best "interact" to achieve a desired result. I first started to understand this concept when I read the book "The Inmates are Running the Asylum", here is a review. The book discusses the art of "Interaction Design". I don't remember it very much in detail, so I'm not going to try to regurgitate it here. BUT, keep in mind a lot of what I say here originated with that single book that served as my epiphany.
Here are a few things I've learned over the years about users, many via hard earned lessons (that I could have learned quickly had my ears been open when Nancy talked to me):
- They want to be able to use a product quickly and without reading a lot
- They don't want to be intimidated by a product
- They don't mind gradually discovering things in a product as their need and expertise level increases (basic / expert modes, search bars, expandable property pages, etc...)
- Mistakes in the interaction model can kill (literally)
- Common language is important (if you are in the storage world, tell me, what is a "Volume"...seriously...its a trick question, a "Volume" has different meanings in different contexts)
- Number of clicks does matter, but no more than meaningful and expected behavior from those clicks
- Visual representations are incredibly important and if you don't put the proper graph up for the proper purpose, you are simply wasting space and confusing people
The last bullet is particularly interesting to me as my neighbor spent much time working with our user interface design teams on figuring out proper presentations for various information. I was amazed at how useless and confusing pie charts often are (especially in the storage management space), it blew my mind. On the other hand, what user's needed was often a pareto chart (even if many didn't know what one was). A pareto chart for things like capacity consumption or performance bottlenecks is like a little piece of magic. Basically, a user could look at the pareto chart and find the top 10 offenders for some parameter, and how badly they were offending, like this pareto chart that reflects IO performance on a product that I used to be the architect for. Pie charts are often confusing as to what they are really showing. Our engineer doing the pareto chart also found that the ability to offer the chart (top 10) along with a table-view was a sweet spot. It gave "at a glance" in a not-to-crowded way along with the ability to get very fine-grained details.
Still, I digress. My belief that has been built over the years is that
- Interaction design is a critical early step in product development
- Interaction design and usability does NOT hurt product schedules on average, as long as the team is disciplined
- Interaction designers and usability engineers are RARELY built from the same material as software engineers, we are just "different"
- If a software engineering team cannot truly interact patiently with an interaction designer or usability architect, perhaps they don't really know how their product will be used, which in of itself justifies their time spent with the interaction designers and usability architects
- The penalty for not using an interaction designer or usability architect is often software engineers that quickly create prototype user interfaces but then spend weeks and months tweaking it to "get it right" (and never really getting it to what a user wants). The user interface also often stacks up poorly against competitor user interfaces that did use interaction designers, especially in competitive bid situations and product comparisons.
In summary, take a few moments on November 14th, World Usability Day, to marvel at a few things that are usable, and a few things that are not usable. Pay attention to software. Think of Tivo vs. the old days of VCRs. Think of a Network Attached Storage device vs. a General Purpose File Server. Think of two competing products and what you like about one vs. another, you may be able to guess which ones have interaction designers and which ones don't. Be careful NOT to look at your own software products if you are an engineer, you will be deceived by your own deep knowledge about the usability of your product.