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
Adapted from an article that appeared in Personal Engineering & Instrumentation
News.
Return to the article index.
|
