Seven deadly excuses for poor design

COMMENTARY--I’ve experienced many different corporate cultures though the course of my consulting practice. Some companies embrace the idea that their products are only successful when they meet the needs of those intended to use them; and these companies’ processes, metrics, and rewards work together to encourage good software and web design. However, many companies unwittingly reward their staff for products that don't meet the needs of end users.

Most often, a culture that rewards poor design has an unbalanced focus: The company focus is primarily inward, and to some degree, there is a neglect of customer needs and goals. There are many subtle ways that companies can forget about the customer and become too internally focused, and these are often exemplified in excuses I’ve heard throughout the years—excuses for poor design.

The seven deadly excuses
When people make excuses for poor design, they reveal a lot about a corporate culture, as well as about their own beliefs and the level of personal responsibility they feel for a product’s success. I’ve chosen to discuss seven of these excuses and the underlying problems they represent:

1. "We have to be first to market."
Translation: “We don’t have time to make sure the product meets our customer’s needs.”

Underlying this excuse is the fear that a focus on customer needs will slow the development process. However, a customer-focused process can actually save time overall by eliminating less important features, reducing rework when customer needs are discovered too late, and reducing programming time through increased consistency and greater re-use of constructs and components.

Another underlying assumption is that first to market will lead to market dominance—presumably by hooking customers before other alternatives become available. Unfortunately, history does not always support this conclusion. Thomas Edison was first to market with the phonograph, but Emile Berliner’s Gramophone ultimately dominated the market; the Apple Newton was the first to market but the Palm Pilot won out.

These and countless other examples demonstrate that the lack of competitors is only one factor of a product’s ability to capture market share. And if a product fails to meet customers’ real needs, “first to market” may well mean “first to flop”.

2. “Our budget doesn’t allow for design specialists."
Translation: “We can’t invest what’s needed to maximize long-term company revenue."

This excuse can indicate a fragmentation of company goals across departments and management levels. Even if the higher-ups understand that a usable product will result in greater revenue, they often fail to convey expectations to the IT department that products must be usable. Instead, they continue to reward IT for internally-focused metrics, such as speed to market and project cost, to the exclusion of externally-focused metrics, such as increased sales or the transfer of traffic from call center to web site.

A fragmented corporate culture fails to engender ownership at all levels. It may instead create microcosms where each department has difficulty focusing on the company as a whole—let alone the customer. A highly intense, customer-focused project can be more costly at the department level, but the rewards for the company as a whole can be enormous…if the culture allows it.

3. "The requirements make it clear what has to be done."
Translation: “Simply including certain features is more important than how those features are implemented.”

Development of requirements should be part of a customer-centered design process: it should be based on established user needs and followed by a design process that includes customers throughout. However, many cultures have become feature-focused, and they over-emphasize what needs to be done while paying little attention to how it is to be designed.

Companies with feature-focused cultures will tend to generate requirements in-house and base requirements on scanty, anecdotal, and/or antiquated customer information. They may also consider the requirements the measure by which finished products are evaluated, instead of balancing that view with external measures such as usability test results.

4. "Well, it makes sense to me."
Translation: "I’m a representative sample of our customer base."

Unless you’re developing tools for the project team itself, no one on the project is a true end user. For one thing, it’s rare that the target audience consists of developers or project managers. And even if that were the case, team members still do not qualify, simply because anyone assigned to the project will have a much more intimate knowledge of the system than the average user, and their ideas of how the system should work will always be skewed by that knowledge.

The tendency to evaluate designs based on ones own perspective goes hand in hand with point #3. This is because corporate cultures that are inwardly focused when generating requirements also tend to look inward when assessing the value of proposed designs. In these cases, management often becomes the target audience by evaluating the designs and making judgments based on their own needs and expectations—or on what they believe customers to need. However, in my experience, what companies believe their customers need and what they actually need are often two very different things.

5. "It will be so cool if we do it this way."
Translation: "My personal target audience is my co-worker (or resumé) rather than the customer."

Once when consulting with a Fortune 100 client, I worked with a very talented graphic artist who refused to render some of the screens as I had laid them out because he didn’t “want to have his name associated with them.” In the end, his manager had to do the graphic design and despite the disdain expressed by this particular artist, the final implementation was hugely successful with customers.

It was that experience that first made me realize that while we may pay lip service to the customer as the primary audience, it’s not necessarily true for everyone on the project. For this particular employee, the audience was other graphic artists, not the customer.

Sometimes a company seeks to distinguish itself from the competition by doing something in a completely different way. Such an approach is great when it’s also better for the customer. However, sometimes a corporate culture places value on “cool” technology, on odd approaches to user interaction, or on unusual (or off-the-wall) graphic design simply for its own sake. But this is just another trap which causes companies and their employees to become imbalanced and internally focused.

6. "Customers will get used to it."
Translation: “Customers will continue using the product long enough to lose touch with how difficult it is."

It’s rare these days to have a product that is so unique and intrinsically valuable that customers will readily overlook design flaws. Adoption cannot be guaranteed even when the target audience is captive, such as for a corporate portal. For instance, an April 2004 study by Forrester Research found that nearly half of employees offered a benefits portal have never used it—and the problem is apparently failure to consider employees’ goals in the design.

By expecting customers to use a product that is difficult or doesn’t meet their needs, companies are often implying that the customer is dependent on them rather than the other way around. There’s a fine line separating company pride and egotism, and statements like this may indicate a culture that engenders the latter.

7. “That’s what the help desk is for.”
Translation: The design issues will soon be someone else’s problem.

Many corporate cultures simply accept that training is a part of every project, and there often seems to be a belief that training will "make up" for poor design. IT is sometimes very willing to accept this perception, since it means that they can transfer ownership of the problem onto someone else. And companies encourage such shifting of responsibility when they measures IT only on whether they were able to deliver on time and in budget, rather than also including the product’s success with the customer in the formula.

Until they see it done, companies rarely understand that it’s possible to create software and web applications that need no explanation. One company I consult with has a dedicated training department that met with me as we were nearing deployment of a large web application. They were somewhat distraught because while training guides had always accompanied past web applications, this latest design was so straightforward that they didn’t feel like they had anything to say.

Achieving balance
If excuses like the above are being tossed around, it’s probably time to for a company to look at consciously shifting focus back toward the customer. Here are a few ideas to begin that process:

Install champions of the customer experience. There is usually a trade-off between “easy for the customer” and “easy for the programmer”, and companies need to make sure that they have customer advocates on every project. The most successful projects will give equal power to both groups, and when differences of opinion arise, a single manager will make the final decision.

Follow a user-centered process. Generate requirements through field studies and other customer-focused activities. Include usability-related statements as part of the requirements. Evaluate products with actual customers and allow those evaluations to carry at least as much weight as management’s opinions.

Reward IT for meeting externally-focused criteria. Expand on the theme of “on-time and in budget” to include other metrics, such as adoption rates, reduced shopping cart abandonment rates, reduced call center volume, etc. Look for ways to increase personal and departmental ownership for company success. For instance, consider increasing IT’s budget by a portion of the profit resulting from a successful product.

biography
Dr. Kevin Scoresby is a Business Analyst, Designer, and Trainer focusing on the customer experience. He has been consulting with large and mid-sized companies since 1996 to develop customer-focused strategies, design and evaluate products, and mentor internal personnel in usability techniques and best practices. More information is available on his Web site http://www.scoresby.com.