Issue 265: Design with End Users in Mind

Whether you’re building or programming microcontroller-based systems, you should always keep your end users and their needs in mind. That means restraining any urges to stuff a project with superfluous functionality and parts. In “What Were They Thinking?” (Circuit Cellar 165), Steve Ciarica argues that over-engineered electronics products are typically more annoying than impressive. Ciarcia writes:

I’ve mentioned this before, but the original BMW iDrive on my 2002 745iL was a prime example of overzealous design. Back then, somebody had the bright idea of condensing nearly all the switches and knobs formerly found on typical car dashboards down to a large knob, called iDrive, on the center console. Combined with a fancy graphics LCD, the joystick provided the driver with 3-D motion control for selecting specific subsystems and individual functions within that subsystem. The bad news was that zooming into and backing out of various control functions was so complicated it was a real driving hazard.

I’m guessing the iDrive designers got caught up in the process of creating a slick design and completely forgot about the basic reason you’re in the car in the first place—to drive, not to run a computer! Let’s face it, when you’re driving, it’s more expedient to reach for a single-function control you can locate out of the corner of your eye. The world was not ready to deal with a 3-D joystick, a complex decision tree on an LCD, and a dozen hand motions to tell a computer to accomplish the same thing. With the original iDrive, you either left the same Sirius station on forever with the hot air blowing in your face or learned to use the voice-response system to at least jump over some of the “slick” functionality and get directly to the heater or radio LCD screens.

It took until I got my 2010 X5 for them to get it right. (My three BMWs in between had iterative improvements.) The solution? They put most of the buttons back! Yeah, like most other cars these days, it still has a joystick knob and an LCD that controls individual settings, but a “real” button takes you directly to the right subsystem.

Circuit Cellar Project Editor Dave Tweed related another example to me while I was talking to him about this editorial idea. He told me about the Kawasaki intelligent proximity activation start system (KIPASS), which is an ignition system for some of Kawasaki’s high-end motorcycles that’s based on a “proximity fob” (RFID). If the physical key is in the ignition and you bring the fob within a few feet of the bike, you can start it (by turning and pushing the key). Sounds nice, right?

You can leave the key in the ignition all the time. When you walk away with the fob in your pocket, the key is captured by an electric latch so it can’t be stolen. All’s well and good. But it seems that most riders are in the habit of stopping the engine by using the “kill switch” instead of turning off the key. That’s fine until you realize that the headlight is only controlled by the ignition key—the light stays on until you turn the key to the “off” position. On a normal bike, you would do this anyway in order to pocket the key before walking away. But with the KIPASS fob, you don’t need the key and lots of bikers simply stop the engine and walk away—leaving the headlight on and killing the battery.

Here’s where it gets fun. With a dead battery, you can’t start the bike except by jumping it using another vehicle. The Allen wrench you need to open the panel you have to remove to get at the battery is in the tool kit under the seat, which is locked by the ignition key. In a real Catch-22, the ignition key is still “captured” by KIPASS even without power, and you can’t remove it to unlock the seat! The only solution is to find a friend or a tow truck with both jumper cables and the correct Allen wrench.

Home theater equipment is another irritation. Forgiving for now that most functions can be accessed only from the remote control, you’d think the few buttons they do have would work correctly. For some reason, I’m finding the built-in buttons are a lot less responsive than the remote. I suspect the interrupt handling software for the IR receiver has a much higher priority than the hardwired switches. My Blu-ray player, in particular, virtually never responds to the physical change disc button on the front, and I almost always have to use the button on the remote. Even powering up the unit takes two to three firm panel button presses but only one click on the remote. My HDTV is similar. There’s a manual button to change the input selection, and it always takes two to three presses before it actually starts to switch inputs. On the IR remote, it is instant. Grrrr.

The point is, when designing a new piece of equipment, don’t get caught up demonstrating as much technology as possible to the exclusion of all other considerations. How hard can it be to design a piece of equipment to respond equally to a few hardwired buttons as well as the IR? Similarly, just because you have the computing power and software expertise, sometimes it’s counterproductive to put all functional control only in the remote control or to put every function into one multi-option/multitasking joystick. As a designer, you have a responsibility to reduce hardware costs by eliminating excess manual controls, but you should always take the time to put yourself in the place of the end user who has to deal with your choices. More importantly, think about what happens after the dog eats the remote.

Circuit Cellar August 2012 is now available.

Comments are closed.