SLTF Consulting
Technology with Business Sense

 Home | Bio | Contact Us | Site Map


 

Functionality alone won't guarantee a successful design

Scott Rosenthal
January, 1992

Have you noticed the revolution going on in embedded design? Are you prepared for its implications? The embedded world is changing fast and you need to master its progression. The issues are complexity and usability and it's having a tremendous effect on embedded system developers and end users. In my opinion, complexity is the inevitable evolution of integrated circuits, allowing more and more features to be designed into embedded systems. And usability, the trait that separates the easy to use instrument from the technologically crippled design, is becoming an increasingly large problem with the complexity of today's embedded systems. You as the designer need to tackle not just one or the other of these problems but both of them. The key is attention to detail, being a perfectionist, and insisting that everything in your design be proper from both a technological as well as a customer point of view. In the martial arts you're supposed to let your opponent's force work to your advantage; complexity and usability, even though the combination might seem overwhelming, you can control these in your embedded system development.

In the beginning, people didn't have computers on their desks. If a computer was available, it was either locked in a special room or buried somewhere in an engineering lab, in both places restricted in its access. Instrument designs, and even embedded system designs, competed against other instruments or equipment, not computers. Today though the situation is vastly different. Everyone has been exposed to computers and the vast majority of people work daily with a computer. This familiarity with computers has now trickled down to embedded designs so that the powers-that-be expect that every little design must compete directly against that computer on their desk: full blown graphics, huge database capability, alarms that sound like CDs, easier to use than any computer program (they designed it, right?), and cost peanuts. I'm here to say that it doesn't work that way.

Complexity has a price which most people in high places have difficulties accepting. WINDOWS applications look great but how many dollars and years did it take for WINDOWS 3.0 (not 1.0) to become accepted? Are your managers or customers willing to foot the time or money for the elegance they think they so desperately need? Can the complex issues be solved in the first release of the design? The second? Is there even a window of opportunity that allows a second try?

An elegant engineering solution to a complex problem might not be what the customer actually needs. I once developed the software for a real-time blood analyzer used during cardiac surgery. The software was slick; I knew it was good. Everyone at my customer's facility told me that it worked great too. However, reports started coming back from the field with complaints about the difficulties using the instrument. I finally went into the operating room while the instrument was being used. I was appalled - they were using the instrument wrong! That wasn't how I had designed it. I had assumed that the perfusionist (s/he runs the heart-lung machine) would be watching my machine the whole time. Too bad no one had told me that s/he had better things to do, like keep the patient alive. It was back to the drawing board, learn the user's constraints, and design something that would actually solve their problem, not create another one. The original design had solved the complex technological issues but it hadn't addressed the usability issue. They must both be solved if the design is to succeed.

It's in the designer's best interest to learn as much about the design's intended use as it is to learn about what goes into the design. Go to trade shows, not just the ones for developers but also the ones targeted at your customers. When was the last time you went to your boss and asked to visit a customer site just for learning more about the customer's application? How can you appreciate what your customer is capable of doing unless you've seen his operation (no pun intended). Remember, just because an idea seems slick to you doesn't mean that it's what the customer needs or wants.

Another example of not designing a product for a customer are radios. Remember the old ones that had dials for tuning? You could take that dial and know exactly how far to twist it to jump to your favorite station. Try doing that with a push button. The push buttons might be sleek and "fit" into the design but they're not as usable. I just read a review on marine VHF radios and the reviewers refused to evaluate any radio lacking a tuning "knob". The push button tuning wasn't user-friendly. The problem with the old tuning knobs was reliability, not that people didn't like the knobs. The advent of electronic tuning allowed this potential failure mode to be removed, only they removed too much. Optically encoded knobs work very nicely and they don't fail like the old tuning knobs. Hewlett Packard has a full line of these digital panel mount optical encoders. Don't solve one problem by creating another problem.

The examples of mistakes made concerning usability, even though the technological complexity issues had been solved, are everywhere. I personally have learned the usability issues the hard way. One of the first instrument designs I worked on was for measuring the constituent content of animal feedstuffs such as forage and silage. This instrument used a brute force calibration technique requiring 50 samples and numerous multiple linear regressions. At the time this instrument was very advanced, with the multiple linear regression program built into the instrument's software (in assembly language on an 8080). No more would a minicomputer (before desk top computers) be needed to do the calibrations. I was proud of this feat and I got the opportunity to teach the international sales force and new customers how to use this instrument for which I had designed the software. I traveled for six straight months pounding into everyone's heads how this beast was supposed to be used. I finally turned the problem around and asked the question "What can I do to the instrument's design that will allow me to stop all this traveling?" The major usability problem customers had was with the repetitive cycling needed for the multiple linear regressions. To solve this usability problem I squeezed a stepwise regression algorithm into the software which removed the calibration chore. The complexity was still there but it was now masked, making the instrument usable.

A great book on this entire design issue is "The Design of Everyday Things" by Donald A. Norman (Doubleday Currency). An MIT-graduated engineer who now is head of the Cognitive Social Science Group at the University of California, San Diego, his book asks the question "Why do we put up with the frustrations of everyday objects, with objects that we can't figure out how to use, with those neat plastic-wrapped packages that seem impossible to open, with doors that trap people, with washing machines and dryers that have become too confusing to use, with audio-stereo-television-video-cassette-recorders that claim in their advertisements to do everything, but that make it almost impossible to do anything?" This book isn't specifically aimed at the embedded market but since so many objects today contain embedded processors, you can't help but think that some of his frustration is pointed at us. I found out about this book the hard way - a customer told me that I should read this book. This was after I showed him my design for a new instrument (what do you mean that this could KILL someone). And you know what, he was right! My latest design knocks the socks off the one I had previously shown. I'm now an avid proponent of instrument/software usability, not just by the developer but by an inexperienced user that's versed in the instrument's field, the customer.

To paraphrase, complexity does not an embedded instrument make. No customer anywhere cares about how complex the inside of your instrument is; all he cares about is whether or not your instrument does what he needs it to do, and does it in an effortless way. Just look at your own habits. Don't you cringe each time you need to drag out the logic analyzer, not because it won't help solve your problem but because of the setup time it takes? If only there was a better way... PE&IN



About Us | What We Do | SSM | MiCOS | Search | Designs | Articles

Copyright © 1998-2014 SLTF Consulting, a division of SLTF Marine LLC. All rights reserved.