feature article
Subscribe Now

Stupid Customers!

Who Needs ‘Em? Real Users Don’t Appreciate Brilliant Engineering

Sometimes customers can be the stupidest people. Why do they have such a hard time using simple products? And why are they so allergic to reading manuals, FAQs, or help screens?

We’ve all heard the (likely apocryphal) story about the tech support technician who breaks the news to his customer that the CD-ROM tray isn’t really a cup holder. Are users really this dumb? Well, yes and no. A lot of tech-support lunacy is spawned because the engineers and programmers who create stuff (that’s us) don’t have the same mindset as the people who use this stuff. We’re engineers; our customers aren’t. We think differently.

We’re also too close to the problem. After spending 18 months on a user-interface design, you’ll be intimately familiar with it. Perhaps too intimate. Even when our customers are engineers, they won’t have the same preconceived notions or product-history background that we do. I recall watching a hardware engineer check out a new Tektronix oscilloscope. He kept pinching the screen to enlarge the image. “No, it’s not an iPhone,” the weary Tek salesman had to tell him, and obviously not for the first time. The pinch-to-stretch gesture didn’t come from Tektronix and had nothing to do with oscilloscopes, yet the customer somehow assumed it would work. And who can blame him?

Developer/user mismatches spring from a lot of different causes. Good engineering teams will employ, or at least listen to, outsiders with good customer-facing experience. Nontechnical people are sometimes your best source of tough-love feedback.

They don’t see the beauty

Consider the combination TV/DVD player. These make perfect sense technically. Everybody owns both; they’ll always be side by side; they’re permanently connected together; and putting both functions into one housing saves space, eliminates video cables and does away with one power cord. It’s elegance itself. Yet nobody ever buys them.

Stupid customers apparently want to buy their TV and their DVD player separately. Maybe it’s because they like to upgrade them on different cycles, or they’re afraid if one breaks it’ll take the other down with it. Whatever. The point is, what’s neat and elegant to us isn’t always attractive to the buying public. Get over it.

They have their own expectations

Once the product is in customers’ hands, do you keep getting the same support calls? If your customers continually misuse the machine/software in the same way, it’s probably not their fault. Yes, it’s likely that they haven’t read the manual, but that’s not why they’re screwing up. Consistent misuse is a symptom of bad design, and no amount of “it’s in the manual” will fix that. If your new car came with the gas and brake pedals reversed, would a note in the owner’s handbook be enough for you to learn to drive it?

Like the Tektronix oscilloscope, every product exists in a larger world, a world that has influenced users’ expectations. And, like Tektronix, you can’t do anything to control it, but you can (and should) be respectful of it and respond to it. No product exists in a vacuum, and the broader “user world” should indirectly influence your own designs.

They don’t follow the script

User manuals and help screens are useful, but they really answer only your questions, not the customer’s questions. Whoever writes the help text unconsciously guides the questions, not just the answers.

We saw this same phenomenon in our survey of surveys. Help screens and pop-up responses can answer only the questions you’ve already anticipated. They can’t foresee “off the menu” questions that real users are likely to ask. No matter how thorough and well-written your help text is (and it’s probably neither), it can never predict the unpredictable.

As a clue, help text should never contain tautologies like, “To save a file, click the File menu, then click Save.” That’s never helpful and certainly not what the customer is asking. Anyone caught writing that sort of help text should be tattooed with helpful directions for engaging in certain anatomically improbable acts of personal violation.

They’re visually oriented

Human-factors engineers tell us that people memorize locations, not labels. You expect the “File” menu to be near the upper-left corner on a Windows PC, and the “close” button should be in the upper-right corner. Swapping their positions guarantees confusion. If it all changed tomorrow, you’d still instinctively reach for the File menu in the wrong place for months until you’ve finally retrained yourself. That’s one reason people were slow to adopt Microsoft Office 2007: all the familiar buttons had moved. No matter how logical the new layout may be (and that’s debatable, too), the only salient point is… they moved. “Better” isn’t always better. You can’t just swap the gas pedal and the brake. We’ve all learned the old user interface.

They don’t read

More subtly, visuals count for more than text. After position, what we remember is the appearance of the thing we’re reaching for. We look for the yellow folder icon, or the green checkmark, or the red cancel button. We’re not actually reading the text; we’re pattern-matching the visuals. If a badly designed Windows application swaps the positions of the OK and Cancel buttons, we’re momentarily confused, but we still expect them to look like OK and Cancel buttons. If all the traffic lights in your town were secretly turned upside down, with the red light at the bottom and the green at the top, you might not immediately recognize quite what happened, but you’d know something was wrong.

The upshot of all this is that you can’t expect your users to read. Text is third in line of succession after position and appearance. It’s there as a backup; a confirmation that this really is the File menu or the Save button. Text is never the primary indicator.

To verify this, I once used a Swedish version of Windows with very little trouble, because all the menus were in the same position and sequence as the English version. Menu selection and mouse clicks all felt natural and automatic, as long as I didn’t look too closely. Even an Arabic-language version (where text runs right-to-left) wasn’t all that hard to use; I just counted over from the edge of the screen. (I found swapping the mouse to my off hand also helped.)

So don’t be too quick to prejudge your customers as the illiterate louts they undoubtedly are. Your product is not the most important thing in their miserable little lives, so they’re not going to spend a lot of energy learning to use it. They’ll drag all sorts of emotional baggage and prior experience to the party: things that will randomly alter their expectations and behavior. Between their BlackBerry, the ATM at the corner bank, and those five years they spent using WordStar, they’re irretrievably tainted. Deal with it and take their money. 

3 thoughts on “Stupid Customers!”

  1. I remember working in tech support. Not necessarily fondly, but I do remember.

    One customer seemed incapable of following directions. No matter how many times I said to “push the big red [reset] switch,” he kept asking what I meant. “There’s only one switch on the machine. It’s on the front. It’s red. Push it.”

    “You mean now?”
    “Yes, now.”
    “The red one?”
    “Yes, the red one. The one we talked about.”
    “Yes, push the ^*@#$ switch!”
    “The red one on the front?”

    … you get the idea.

  2. At Wind River I led the product development of the new toolchain, which became workbench. As WR had just acquired many companies leaving us with 4 IDE’s, 3 compilers and multiple other overlapping tool capabilities. Unsurprisingly all those team leads had their own ideas of the best UI for our customers.

    Problem was that they all had their own idea of who the customer was.

    Luckily for me, one engineer pointed me at a book called “the lunatics are running the asylum” by cooper. It basically identified that engineers all think they know the customer – and they don’t!

    His approach, which we in the PM team used, was to create a complete fictitious engineering team – who had differing responsibilities at different stages of the dev of a telco switch. We gave every customer in that team a personal identity, an educational background, a list of strengths and weaknesses etc etc, and we then challenged our engineers to make every single one of that 20 strong sw dev team happy with the toolchain – as if the toolchain was designed for each of them.

    The UI dev team we had at WR were part of the original borland Team – in one day they said they learnt more about what they needed to do to satisfy the users than they had learned in the previous 10 years.

    So yes I agree engineers can create crap products – but its down to the PM team to lead them in such a fashion that they can innovate and achieve what the market needs. its a team effort. My PM team did not lay out widgets, or craft UI formats, the creative engineers can always do that better than the average PM – they just need help to ensure they don’t get stuck with the idea there is ‘one’ customer to satisfy – the one on their head.

  3. I remember having just signed on to a large… um… chip player and was having dinner with my new boss. As we were leaving, I made some comment about understanding what customers want, and he responded, “Well, actually, often we know what they want more than they do.”

    There’s a time when that can be true – when you’re facilitating a paradigm shift, for example – but most often, it’s just a cop-out.

    Of course, knowing your customer makes it possible to gauge their intuition… and intuitiveness isn’t always what it’s cracked up to be.

    But more on that in a week or so… stay tuned…

Leave a Reply

featured blogs
Jun 1, 2023
Cadence was a proud sponsor of the SEMINATEC 2023 conference, held at the University of Campinas in Brazil from March 29-31, 2023. This conference brings together industry representatives, academia, research and development centers, government organizations, and students to d...
Jun 1, 2023
In honor of Pride Month, members of our Synopsys PRIDE employee resource group (ERG) share thoughtful lessons on becoming an LGBTQIA+ ally and more. The post Pride Month 2023: Thoughtful Lessons from the Synopsys PRIDE ERG appeared first on New Horizons for Chip Design....
May 8, 2023
If you are planning on traveling to Turkey in the not-so-distant future, then I have a favor to ask....

featured video

Synopsys 224G & 112G Ethernet PHY IP Demos at OFC 2023

Sponsored by Synopsys

Watch this video of the Synopsys 224G & 112G Ethernet PHY IP demonstrating excellent performance and IP successful ecosystem interoperability demonstrations at OIF.

Learn More

featured paper

EC Solver Tech Brief

Sponsored by Cadence Design Systems

The Cadence® Celsius™ EC Solver supports electronics system designers in managing the most challenging thermal/electronic cooling problems quickly and accurately. By utilizing a powerful computational engine and meshing technology, designers can model and analyze the fluid flow and heat transfer of even the most complex electronic system and ensure the electronic cooling system is reliable.

Click to read more

featured chalk talk

Peltier Modules
Do you need precise temperature control? Does your application need to be cooled below ambient temperature? If you answered yes to either of these questions, a peltier module may be the best solution for you. In this episode of Chalk Talk, Amelia Dalton chats with Rex Hallock from CUI Devices about the limitations and unique benefits of peltier modules, how CUI Devices’ arcTEC™ structure can make a big difference when it comes to thermal stress and fatigue of peltier modules, and how you can get started using a peltier module in your next design.
Jan 3, 2023