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.
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.”
“Now?”
“Yes, push the ^*@#$ switch!”
“The red one on the front?”
… you get the idea.
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.
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…