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.

One of the themes we constantly hammer home to our clients is the value of design. It’s a topic that cannot be summed up in a few sentences but rather requires a long and hopefully engaging dialogue about why investing in design is good for business. An initial hurdle we have to tackle before that conversation can happen is what exactly we mean by “design.”

Let’s run down the list. Web Design. Interface Design. Application Design. Experience Design. Visual (or graphic) design. It’s pretty safe to say that just saying “design” isn’t enough. Most people think of design in the visual sense (e.g. fashion design or interior design). We can easily get pigeon-holed as graphic artists that can whip up some nice icons and colors. We know we’re a lot more than that and we also know how important design is to us. So where do we start?

How about a dictionary definition? I like this one:

• To conceive or fashion in the mind; invent.
• To formulate a plan for; devise.
• To plan out in systematic, usually graphic form

Ah, now we’re getting somewhere. I think the single most important message we can convey to our customers in the business world is the value of design as a means of mitigating risk. It’s a lot less painful to find a flaw in a design phase than to find that flaw in the actual product. The cost of flipping the pencil and erasing a flaw in a design is a lot cheaper than discovering that flaw in the actual product. Such flaws don’t necessarily have to be your typical software bugs. They may be simple interface design flaws that can be tackled with a lot less impact in a design phase than after a product is half built.

For us, design is about forethought. Thinking through a good end-user experience. Thinking through a sound architecture that will scale effectively. Thinking through whether the goals we’re seeking bring real value to the intended beneficiaries of our products. Once the hard work of thinking through the design of a product is complete, the remaining task – building it – is far less painful; far less risky and as a result, far less costly. When we “design,” the pitfalls and roadblocks are considered and a plan is formulated.

There will be many entries in this blog that will hone in on the value of interface design or the value of spending the time to design a good architecture, but for now we wanted to hit on the underlying theme beneath them all: design as a synonym for forethought.  

As a total devotee of next generation design methodologies and web technologies (and other cool sounding -ologies), I’m psyched about blog.arc90.com and the opportunity to bring some of my insights to the party. You can call me Chris LoSacco. I’m an interface designer (among other things) at Arc90. Today, I want to step back and talk about why interface design is important at all.

More often than not, design is the odd man out of the software engineering process. A business analyst who took a print design course in college might throw together some ideas that wind up becoming a product, or a coder will mockup a rough prototype to display functionality which never gets changed before the shipping date. A laissez-faire attitude toward design usually results in sub par software and a huge reservoir of uncollected profits.

How can good interface design impact a business’ bottom line? Let’s consider the numerous ways that a design effort for internal software can boost returns, without even considering the customer-facing output (where perhaps even more is to be gained):

• Productivity. This one’s a no-brainer. If the part of the software that the employee interacts with 100% of the time–the interface–is designed for the best possible experience, productivity goes up because the user can spend less time battling with his tools and more time on actual work. Actual work means actual profits.
• Fewer errors. Easy, intuitive interfaces help users accomplish tasks without making mistakes. More of the work being done is translated into usable result as erroneous entry decreases, so quality output goes up.
• Reduced labor and training costs. Ever heard of anyone taking a course in Google or Amazon? Of course not. But the bills for labor and training on bloated software are exorbitant. Well designed software doesn’t require a three day retreat for training or on site experts drawing a healthy paycheck every month. These costs accumulate, too: as the business grows, new employees need to be trained and support staff may need to expand. Rather than planning for these costs, taking the time to architect a good design up front translates into significant savings down the road.
• Low barrier of adoption. People will not want to use software that makes them feel stupid. An interface that isn’t designed with the user in mind (often the side effect when a programmer designs an interface to show the features of his program) will put the user off and drive him away. "I can’t do anything in that program. It hates me," says an employee. That’s terrible for business, and wastes a lot of money.
• Morale. Business 101 dictates that happy employees will work better than their unhappy counterparts. (It’s why Microsoft stashes Xboxes around their campus and Electronic Arts has a garden labyrinth. Perks are important!) With bad design, as Joel Sposky writes, "[Users will] try to accomplish things, and either fail, or struggle, and for very real reasons this will literally make them unhappy." Irritated employees aren’t as productive, and the bottom line suffers.

It takes great ideas and a hint of black magic to come up with a solid interface design, but spending the time and money to solve design problems up front and create an effective solution can turn into tremendous returns on that initial investment down the road. A good design can, quite directly, make a lot of money.