Which "Design" Are We Talking About? | Home | 10 Reasons We Love Flex 2

Filed under Design on June 21, 2006 by Chris LoSacco

Designing For The Common Good

As designers that define product, we want to make everybody happy. Unfortunately, the larger your user population, and the broader your set of user profiles, the more difficult it becomes. The following experience highlights the danger of being everything to everyone in design.

A few years ago, I was part of a team building the check register component of an online payroll suite. When we started development, we had a few main user requirements to meet, like check reconciliation and EFT notification, and a few internal requirements as well, like robust printing capability. With a brilliant programmer at the helm and tons of great ideas, we had high hopes for the outcome.

The end result was about as powerful as we could have imagined. It had many options for viewing, sorting, filtering and clearing checks and statements, as well as a strong printing facility for in-house use. We made sure that the data was fresh from the database, so that the program always displayed the most up to date information (a common user request). Our team lead would relentlessly pour over feature lists to make sure we'd included everything that our users had asked for. We even added some really complex operations to the software, including services that our users hadn't even asked for but that they'd surely appreciate and fawn over. We anxiously released version 1.0 to our user base and sat by the phones waiting for the praise to roll in.

None came. Hardly anyone used the program at all. In fact, even when our operations people specifically asked our users to perform tasks using that component, they'd politely decline! Our team had started development to address the existing needs of our users and now that we had, no one was taking advantage of our hard work. Something had gone wrong.

The reason for the poor adoption wasn't because of missing functionality or lack of features. The check register software was about as easy to use as an electron microscope. We had taken the clearly defined requests our users had made and obscured them in a complex interface under the guise of power and flexibility. Sure, our software could do everything asked of it, but since it gave equal weight to each task -- including the internal tasks! -- no one thing was simple and easy to do. The development lead was happy, but the end user wasn't.

For example, the ability to select a group of checks to print, - a solely in-house task that a customer would never use - was grouped with a selection control for client statements. Though the first case would be used only by internal staff about once a quarter and the latter would be used by all users of the software on a regular basis, both were displayed with equal weight. This lack of attention to feature definition sucked the usability right out of the program. By exposing all functionality without preference, the most usual tasks were lost in a sea of unusual ones. And no one likes to be lost at sea.

Instead of trying to satisfy 95% of our users with the common, oft-used functions of check reconciliation that would have made a difference in their workdays, we had built the flexibility and capability to suit all 100%, presented it right up front and achieved an adoption rate of 0%.

Responding to your users makes great business sense, but only if your response addresses their suggestions in context and rightly prioritizes the most common information and controls. Otherwise, you're designing for anyone and everyone, and it's the common user with the common tasks who suffers.

Post a Comment Digg Del.icio.us

Post a Comment:

Name:

Email Address:

URL:

Comment:

Which "Design" Are We Talking About? | Main | 10 Reasons We Love Flex 2