Delighting People

Lately, listening to podcasts and reading articles about user experience, I have heard the word delight come up frequently as a goal of design.

Can we delight people with technical writing?

I think so. Most of us know all the rules of writing well (whether we use them or not). But, if technical writing was only a matter of good content, then most users would be happy and satisfied.

My guess is that a large percentage of the time people are dissatisfied with their help because they can’t find what they are looking for and they don’t know how to ask for it.

What makes really cool websites “delightful” to use?

Responsiveness. Interaction. That’s why people like sites that use Ajax so much. Sites like Google Maps make you feel like the page is responding to you, like you are communicating with the page and it is listening to what you want.

When people click help and get the search box, a massive list of faq’s, or worse yet, the dreaded industrial-sized table of contents, they are no longer communicating. It is like they are dropped in the middle of a giant library with no librarians and usually very little guidance.

This is not delightful.

How can we start a dialogue with people before they completely frustrated and lost, hopelessly clicking on faq’s and typing “I hate you” in the search box?

The Aptana ide had a very nice way of doing this. Although, it seems to be gone in the latest version. The first time you open the software, the start page in the middle of the screen gives you information about different parts of the UI and what they do.

I think to delight people, you want them to feel like you care about them and have anticipated what they need to make them happy.

The Aptana interface answered my questions before I knew I had them. This is very similar to video games that show you how to play with little pop-up windows that explain things without interrupting the flow of the game.

You are not alone. We are here to help. We know, this stuff is confusing. Let us help you. How can we help you?

This is delightful.

Don’t think like a user.

Think like a user. Think like a user. It’s the usability mantra. But how can you really think like a user? Especially when you have been documenting the same software for a long period of time. You are familiar with the interface, you don’t have to search for buttons. You know the names of all the toolbars and buttons and special features and you even know you know exactly where to find the answer to questions because you probably wrote the answer yourself.

You are getting so used to talking to Product Managers and Programmers that you are using words like query string and concatenate in instructions for saving documents.

It’s hard to stay fresh as a Technical Writer. Everyone says that no one reads instructions, anyways. It can be discouraging. But people need our help. They really do. And people want to be helped. They want to click that help button and find exactly what they are looking for, quickly.

Unfortunately, you can never truly “think like a user” because you are not a user. You are a Technical Writer. You are a teacher, you are a guide through the bewildering universe of formatting toolbars, right-click menus, dialog boxes and error messages.

When people click the help button, they do not want someone who thinks like them, they want someone who can anticipate their problem and guide them quickly to the answer they are looking for.

Don’t think like a user, think like a user advocate. It’s your job to understand not only what questions users have, but also to know the questions they don’t know they have. To lead them on to more relevant information, to show them things they didn’t even know they had questions about, all the time gently, yet quickly herding them towards the answer to their question.