February 16, 1998

The smart-vs-simple balance

I was quite upset at first when I read the profile of a crane de-sign-and-manufacturing company that was recovering from some severe financial difficulties (Reference 1). The president and CEO had trimmed the company's engineering staff, noting "engineers add complexity and cost." That's quite a shot at our profession!

But, on reflection, I realized that he had a point. His company makes units targeting the rental market, in which low cost plus simplicity of use and maintenance are paramount--much more so than extra features. It's easy for marketers, supported by engineers, to get into the "creeping- elegance syndrome." Soon the 80/20 guideline is in effect, in which just 20% of the users need 80% of the features. And sometimes this guideline extends to a 90/10 split!

The tendency to add more, better, and smarter features to a product is so common because it's often easy. A little software here, a small algorithm there, and pretty soon you have added some self-adjusting, self-tuning, and self-anticipating characteristics. However, these features may not be what users want, need, or can handle in the context that they plan to use your product. It takes only a small step to change a useful device into a complex solution that's bigger than the problem it's designed to address.

What can you do? First, keep asking the tough questions: Why are you doing this? Who will use it and how? How many people will miss it if you leave it out? Do the testing and documentation on your part that this feature requires outweigh its benefits?

Second, be humble. Just because you can be smart doesn't mean that a smarter product is the right strategy for your design. As Bellcore's (Holmdel, NJ) Robert Lucky has stated, engineers are trained to produce optimized, intelligent solutions, whereas sometimes a suboptimum, dumber approach is better in a real-life application (Reference 2). After all, a PC is a powerful tool for computation, but vendors sell millions of basic calculators every year because they fit many situations far better in terms of basic usability. Lucky notes that centralized network control can provide a fabulous system but only if you know each and every operating circumstance now and for the future. Otherwise, a suboptimal, decentralized, yet more flexible system is probably better.

The broader question may be: Do users want flexible, versatile, expandable products, or do they want products that do just one thing (or a few things) well and that are easy to use and comprehend precisely because of the products' limitations (Reference 3)? Although there's no easy answer to this question, you should at least think about it when you incorporate "must-have" vs "who-really-needs-this" features into your design.

References

1. "Terex's fortunes improve after tough cost-cutting," Wall Street Journal, Sept 30, 1997.

2. Lucky, Robert, "Reflections," IEEE Spectrum, November 1997.

3. Elliot, Heidi, "Shoot first, do market research later," Electronic Business, January 1998.

EDN Access | Feedback | Table of Contents |