Creating Passionate Users

Too many companies are like bad marriages

It's been said that the secret to a good marriage is... don't change. In other words, be the person you were when you were merely dating. Don't stop paying attention. Don't stop being kind. Don't gain 50 pounds. Don't stop flirting. Stay passionate, stay sexy, stay caring. Answer their calls. Unfortunately, too many companies are all candle-lit dinners, fine wine, and "let's talk about you" until the deal is sealed. Once they have you (i.e. you became a paying customer), you realize you got a bait-and-switch relationship.

This is such a big bowl of wrong. I don't understand this in personal relationships, and I don't understand it in business-to-customer relationships. Shouldn't you treat the people you're in a relationship with better than you treat anyone else? Shouldn't you treat your existing customers better than the ones who've given you nothing?

Most companies would never outsource their sales reps, but we all know what happens with most tech support.
Most companies would never make a brochure with the same (lack of) quality in the product manual.
Most companies would never make their main website as uninviting as the tech support site.

If we want passionate users, we should take a lesson from successful marriages and keep the spark alive. Just because they're now a "sure thing" doesn't mean we take them for granted.

Besides, if we shift that marketing and ad budget from pre-sales to post-sales, we won't have to worry about getting new customers. Our loyal, cared-for customers will take care of that.

Are our tools making us dumber?

It's lunchtime at the cafe and you give the cashier a $20 bill for an $8 purchase. She gives you $32.78 in change. You mention the mistake. She says, "But that's what the cash register says I owe you." She can't cope with the cognitive dissonance between reality and What The Machine Said. Later that day you get a frantic call from a co-worker--a recent addition to the programming team. "I keep getting this error message that it can't find the classes I'm using!" You ask, "By 'it' do you mean the compiler?" He answers "I don't know. I'm using an IDE." That night, you're helping your 12-year old son with his math homework when you realize--in horror--that while he's quite good with the calculator, he couldn't multiply two three-digit numbers using only paper and pencil if his Wii depended on it. These tools were designed to make us more efficient, so that we can focus on something more important than the tedious task of, say, giving change, organizing source code, and doing calculations. But are they helpful timesavers, or are we dumbing ourselves--and our users--down?

Obviously this depends greatly on the tool, the operator, and the task itself. If we all had to understand what every tool was doing/hiding for us, we'd waste brain bandwidth that could be used for something more important--like what we're using the tool for. But in my examples above, think about how fragile the user's ability is if they don't understand what the cash register, IDE, or calculator is really doing. Without that understanding, what happens if the tool stops working? (In college I worked in a small surfboard shop in SLO, California, and the owner said, "I don't care what happens to the cash register, always take the customer's money!" Power outage? Use a damn cardboard box for the cash drawer until it comes back up...)

But should a web designer need to be an HTML coder? Or can he just use a WYSIWYG tool? The debates still rage in the web development world, although the issue should be resolved soon enough. In desktop publishing, for example, you will never hear, "Oh, you can't just use Quark or Adobe InDesign... you really need to tweak the Postscript by hand to do it right."

Some people think even automatic transmissions are dumbing people down. (I've offered to let friends borrow my car and I'm always shocked when I hear, "No, I can't drive a stick.") A flight instructor friend said there are some planes they don't want you to learn on, because those planes do too much for you. Some people think convenience foods like TV dinners are keeping generations from learning to cook. My sister's boyfriend could fix his own VW bus, but that was before cars became computers, before master mechanics were often reduced to part-orderers.

Tools can reduce errors, handle the tedious work, and potentially let us spend more time in flow. Still, when I see those cashiers and programmers, I think we need to keep a few things in mind:

Tool developers
If you make a tool that's hiding things the user should understand, maybe you could provide a tutorial or even an understanding mode where the user can ask the tool exactly what it's doing and how it made the decisions it made. But there's another issue for tool developers, and that's where passion comes in. Consider a point-and-shoot digital camera with presets for things like Portrait, Sunny Day, etc. The camera hides the complexity of making adjustments for exposure, white balance, etc. For most people, that's the whole point of these cameras--they don't WANT to mess with the settings of an SLR. But it's staying in point-and-shoot mode that keeps most people from developing a passion for photography (and ultimately, buying more expensive cameras and lenses).

But what if you could use your point-and-shoot as a way to learn more about photography? It would be so helpful if you could put the camera into a kind of "teach me" mode, where it explained what it adjusted and why it did it. That would make a great bridge to help you feel more confident moving into a (more expensive) digital SLR and avoiding what most first-time SLR owners do--keep it in program/automatic mode.

Tool teachers
Consider forcing students to do some things the old-fashioned way before letting them get their hands on the tool that'll automate much of the drudgery. My first semester of college stats wouldn't let us use computer apps for anything. Just us and our HP calculators. I hated it. But by the time we started running (and writing) our own programs, we had no doubt what was happening at each step and how to troubleshoot. When I teach Java, I always teach it using nothing but a simple text editor and the command-line. I do advocate tools for development, but never, never, NEVER for someone who doesn't understand Java at a fundamental level (compiler options, packages, namespaces, access modifiers, etc.)

Tool users
90% of the time we probably don't need to know how things work under the covers. I only barely understand why 747's ever leave the ground. I've never changed my own motor oil. (I have, she says proudly, topped off my windshield wiper fluid.) But I shouldn't think about putting a bit in my horse's mouth before I understand everything from horse anatomy to the principles of leverage that bit was designed for. I don't have to know how to create a microchip to use this MacBook, but if I don't understand the basics of its UNIX OS underpinnings, I can get into trouble figuring out where things are, how to set up security, etc. And just because there's one Starbucks per every 20 square feet in the US does NOT mean you shouldn't know how to make good, strong coffee the old-fashioned way.

Just something to think about, and as always... I'd love to hear your thoughts about tools, dumbing down, and strong coffee.

[FYI: I'm travelling right now, so if you're waiting on email, I'm hoping to catch up by the end of the week.]

What tail is wagging the "user happiness" dog?

March, 2002: I was in a Quality Review Board meeting at Sun, shortly after our division went Six Sigma. I started listing solution ideas for some big customer problems in my area. The woman running the meeting said, "Oh, we can't talk about solutions today! We're weeks or months away from that... we're still in the data gathering step." The Six Sigma tail wagging the customer happiness dog. September 2004: I was in a meeting at O'Reilly, emphasizing the importance of code annotation for reducing cognitive load. A production person said, "Nope, sorry, our software won't let us do that." The production tail wagging the reader happiness dog. And then there's the all-too-common IT department that makes its life easier at the expense of employees and users. Don't get me started on the Accounting department...

You can't swing a poodle in business without hitting a tail-wagging-the-dog scenario, where some process, policy, procedure, or program controls user happiness. Where we become slaves to the needs and demands of the IT department, efficiency, accounting, PR, legal, marketing, next-quarter's results, Upper Management, etc.

We've heard all of the justifications and excuses. Worst of all, these decisions are nearly always made by people with the least amount of contact with Actual Employees, let alone actual customers. Imagine working at a place where Customer Advocates -- internal evangelists for what users need -- wielded as much power as the IT guy. Where the software developers (and other employees) have the power to use the tools they need to best serve the users, even if it's a pain in the ass for the sys admins. (No offense to sys admins--I'm talking about the misguided and/or too-far-removed-from-customers ones, not the clueful.)

I'm not dissing Six Sigma or IT or Accounting or Production or Policies or Procedures or Process or whatever. I'm just saying we have to be very, very careful about who wags who, especially during that critical phase when a company transitions from a small everyone-does-everything start-up to a bigger company. Users are often best served when everyone from the manager to the developers to the accountants has to spend time on customer service and support. But when that's no longer realistic, we must work hard to make sure that nobody in the company forgets who we all really work for--the users.

We're all guilty of it -- from the big company to the two-person start-up (or the one-person author!) -- and we do need to balance the needs of the company against the needs of the customers, but I'd recommend putting a big picture of a dog in your meeting room, and emphasizing who's the dog, who's the tail, and who wags who.

Bonus link: a wonderful post by Joel Spolsky on customer service! Two thumbs way up.