The Philosophy of Trust

In the majority of eLearning projects that I work on, I eventually get the following question from the client:

Can we disable the forward navigation so that people don't just skip through the information?

And my answer is always the same.

 Of course we can.... but let's think about this. 

We can't force people to pay attention*. Either in classrooms or in eLearning, if someone doesn't want to listen and learn, then they won't.

Preventing forward navigation in a piece of eLearning will not convince someone to engage with the content and pay attention. They will let the piece run, surf the web, do other work or just tune out.

When I rent a movie, I can't skip the FBI warning, but does this mean that I read it? No. I still have no idea what that warning really is, yet I've seen it hundreds of times.

And let's not forget about the people who do have the intention of listening and learning. Taking away their control over the viewing experience will only serve to irritate them. Maybe they want to go back and review a section. How can they do this efficiently if they can't move backward and forward?

The best ways to make sure your audience engages with your eLearning:
- make your content concise, relevant and as interesting as possible
- use interactivity to help engage their brains and make them take action

Let's stipulate that, out of 100 people, 10 will not care about your eLearning and 90 will. And there's nothing you can do about that 10%, so why make changes to try and change their behavior ... changes that won't likely help and could be detrimental to your finished product?

Give people full control and trust that they will watch, listen and learn.

*Of course, if you really want to force people to learn something, you must have either a carrot in front of them or a boot behind them.

What's in a name?

How often does this happen to you: You meet someone at a party or work. A few days or weeks later, you run into them again and panic because you have no idea what their name is.

I have come up with a 100%* effective way to solve this problem. And it has nothing to do with improving your memory.

The next time you meet someone for the first time, they will tell you their name. What you do is, tell them that that's your name too. 

New friend: Hi, I'm Bill.
You:  Bill! I'm a Bill also! Great to meet you!

Days, weeks, or even years later, if you run into that person again, they will immediately call out to you using your name, which they think is the same as their name. So, they've just told you their name.

Bill: Hi there Bill!
You: Bill, good do see you again!

[Of course if too many of these new friends co-mingle, you might have some explaining to do but then you can just tell them about your secret technique and they'll admire and revere you for your creativity.]

*Gender-specific names may pose a problem.

I'm watching you, watching me... (Part 2)

I posted a blog entry a while ago about the LinkedIn feature that allows me to see who has viewed my profile. In that post, I made a passing reference to Facebook, and wondered what would happen if they did the same thing. Since writing that, my mind has been stuck on this notion, and it's gotten me completely distracted. So I need to get this out of my system.

Facebook. It's a lovely tool for sharing photos and saying what's on your mind, but who hasn't used it to secretly peak into the lives of someone else? We can use Facebook like this is because it allows our voyeurism to remain a secret from the target individual (unlike LinkedIn).

But what if that changed? We know that Facebook has the data - they know who viewed whose profile and when. What's keeping Facebook from one day exposing that information?

Did you just turn pale?  The thought of your ex-whatevers knowing that you were poking around their Facebook page is horrifying, no?

Well, if we know that Facebook has this data and that this data has value, why do we assume that they would not want to capitalize on it? They are, after all, a public company now - answering primarily to their shareholders - and shareholders want return on investment.

So, if Facebook decided to cash in on this data, how would they do it? I imagine they could do two things;
1- Announce to the Facebook community that they will be exposing this data and, if you want to have your view history kept secret, you can pay a fee. 

2- Announce to the members that, if they want to see who has been viewing their profile, they can pay a fee.

With this approach, they'd have thousands of people deleting their profiles completely, and a whole lot of people who are willing to pay to a) keep their activity private and b) see who's been looking at their profile.

From the Facebook Data Use Policy at the time of this writing: 

Granting us permission to use your information not only allows us to provide Facebook as it exists today, but it also allows us to provide you with innovative features and services we develop in the future that use the information we receive about you in new ways.

"The information" could be anything they gather, which is everything. "Innovative features" could be a fee-based service that shows you who's been poking around your profile and/or keeps your activity a secret.

Of course I have no idea if this will ever happen - but it could. 

Software Documentation: Delivering the Unicorn

When you use enterprise software, you are going to need help (even if you have received training). It goes by many names: documentation, help, the docs, user guide, manual, etc. Let's go with documentation, the value of which can be put into 2 buckets; effectiveness and efficiency. 

Effective documentation gives the user the correct answer every time. This is all about content. Software systems can be so flexible and dynamic that it's impossible to anticipate all the ways a user may want to do something. The technical writer has a mountain to climb in this regard. A user needs to be able to first understand what the feature is for, then how to use it, and also understand how that feature impacts outcomes as well as other features.

Efficient documentation doesn't force the user away from their task. The traditional documentation fails here. Clicking a link to access the documentation takes my vision and focus away from the software and into a sea of content.

So what would be the best user support scenario?


Here's the best thing I can imagine: the software vendor's product manager sits next to me and answers any questions I may have. This would maximize effectiveness and efficiency, but it's a fantasy, so let's call this the Unicorn Model.

Here's what we have today: I use the software and, when I need guidance, I click a "Help" link to find answers in the documentation. Sometimes it's effective but it's rarely efficient. I have to leave my task, search, read, interpret, apply the information to my specific needs, then go back to the task and see if I can do it. And if that doesn't work, I need to seek other resources; customer support, message boards, online tutorials, colleagues, etc. Let's call this the Mule Model; it works for the most part and we accept it, even though it isn't the most effective or efficient.

From the perspective of the software vendor, our goal should be to give the users of our software the best self-serve user support possible. By doing this, we reduce the burden on helpdesk and training groups and, perhaps more importantly, we foster customer satisfaction. If we indeed have this goal, we should strive to provide user support that is as close to the Unicorn Model as possible.

Effectiveness is really in the hands of the technical writer and the support they receive as they write the content. Let's stipulate that the content is perfect and can address all of a user's questions. The content represents the Unicorn Model, so let's turn to efficiency. How can software deliver the perfect documentation in a way that does not distract a user from their task within the software itself? 

I think this is the million-dollar question but it's not a new one. 

Remember Clippy, the animated paper clip that Microsoft introduced into Windows and Office? This assistant was an attempt by Microsoft to move closer to the Unicorn Model - to provide more efficient user support. And it failed. Users (this one included) found it annoying and distracting.

So what is the answer?

If I were starting an enterprise software company, here's what you'd see:

1) Software design specifications that included explicit user support functionality. This would be much more than a little question mark icon that popped up a sentence. It would be rich and dynamic. Maybe the software offers various modes of operation - beginner, intermediate and advanced - and provides on-screen user support that correlates with each mode. The key here is, don't make the user leave the software to get documentation. Put it in the product.

2) A role within the development team whose job it is to code user support functionality into the product itself and work intimately with the technical writer and interface designer.

This would move us from the Mule Model to something better. Not the Unicorn, but definitely in the right direction. But it's easier said than done. It requires business leaders who share these values and are willing to support them when budgeting. It also requires a product development model that includes user support as a major consideration in the development of user experience.

---

I would love to hear from you on this. Are help authoring tools getting in the way? Is user support (documentation) ever going to get a seat at the product management table?

I'm watching you, watching me....

In my work, I'm always asking the question "so what?". Sometimes, I can't avoid it, even when I'm not working.

We all know about LinkedIn, but I wanted to challenge the site's ability to show you who has viewed your profile.

When this feature first appeared, I remember thinking, Cool! I can see who's looking at me. Then I wondered, what would happen if FaceBook did this?   Take a moment and imagine that.

But back to LinkedIn.

I've always used the free LinkedIn profile, which allows me to see some but not all of the people who viewed my profile. And the site frequently uses the "I see you seeing me" feature as a reason for me to upgrade. They say that 9 people have viewed my profile and show me 4 of them. If I pay for a plan, I can see ALL the people who viewed my profile.

LinkedIn sees this feature as a real selling point, but why?

I know who viewed my profile - so what?!
What am I supposed to do with that information?

Let's consider a couple scenarios where someone views my profile and doesn't reach out to me directly. (I think we can agree that, if someone views my profile, then sends me a message or calls me, it doesn't matter than I know they viewed my profile)

Scenario 1: The Stranger
If an individual whom I don't know views my profile, but they do not reach out to me directly. What does this mean?

It means simply that they see no value in us growing our relationship to anything beyond strangers. Much like when you stand in front of someone in line. They see you, but they don't introduce themselves.

I could then look at their profile to see who they are and try to interpret their visit to my profile. But am I likely to contact them? I doubt it.

Hi there. I saw that you viewed my profile; why didn't you contact me? 

I don't think this is a good way to start any relationship.

Scenario 2: The Connection
Let's say that someone who I do know views my profile. Why does it matter that I know this? Someone I used to work with looked me up or stumbled upon my profile for some reason that only they know. They don't want to chat or to hire me, so what am I supposed to do?

The answer in both scenarios:
I should do nothing.

I should not care.

The truth is, it feels good to see that someone has visited your profile, even if you don't know why they did. You feel a sense of validation and your ego swells a bit. But if you don't know why they visited your profile - it could have been an accident - this pride is based on nothing. What would give me justified pride is if the person viewed my profile, then contacted me. And, as we stipulated, if this happens, it doesn't matter if I know ahead of time that they viewed my profile.

So while I don't blame LinkedIn for trying to capitalize on a) the data they have and b) people's desire to know who is checking them out, I don't see a practical use for this information. It doesn't pass the "so what" test.

I'd love to know if anyone has found a way to actually use this feature to build solid business relationships. Anyone?

The Great Morale Reversal of 2009

This holiday season, I found myself in a downward morale spiral - a combination of bad weather, crowded malls and a long shopping list. Thinking it would save me some time, I ordered a pair of boots from Zappos.com but, upon reading the shipping notice, I discovered that I had ordered the women's version of the boots and not the men's. So much for saving time. I picked up the phone, lowered my expectations and called Zappos.com. This is when the great morale reversal of 2009 began.

I called at around 8:00 in the morning. Someone answered the phone on the 1st ring. A real person. A real person who wasn't in a call center on the other side of the world. I explained to her my mistake and asked her how I go about fixing it. I would need the correct boots ordered and shipped and a return of the wrong boots which hadn't arrived yet.

The customer service rep then said, "the men's boots are actually more expensive than the women's, but I'll give you the lower price".

Then she said, "I'll ship these new ones to you overnight so you don't have to wait any longer to get them."

Let me remind you that this whole issue was my fault - I ordered the wrong pair of boots - I caused this.

Anyway, Zappos didn't have to go to these lengths to make me happy, but they did. And because of this, I tell other people to shop there and I plan to shop there again in the future. That means more revenue for Zappos, plain and simple.

This isn't a new story. We've all read about and maybe even experienced customer service like this (L.L. Bean comes to mind). But what surprises me is that it's still the exception rather than the rule. Maybe because it's difficult, companies don't pursue it. Maybe because it's hard to link good customer service with increased revenue, companies don't spend the money to make it happen.

And why am I writing about this? Because technical writers create what often represents the first customer service "touch-point" for a product. When one opens a toy, one must read the directions. When one buys software, one must read the manual.

That customer is my audience so I think about these things a lot. This isn't to say that technical writers can make software users as happy as Zappos made me but, if we acknowledge that Zappos has set the bar, and we aim for it, our readers will be glad we did. Plain and simple.

Happy New Year!

User Guide as a Guide

I recently read an article by Michael Hughes called "Users as Decision Makers".

His article is here: http://www.divshare.com/download/6513696-0d8

Michael's Blog is here: http://user-assistance.blogspot.com/

The gist is that product documentation often fails in its lack of guidance. In other words, there's too much information on what one can do and not enough information on what one should do.

And it's a very good point.

Knowing that a software setting can go from 1-89 is important, but what are the implications of the different values? What should I set it to so that I achieve my desired outcome?

Maybe this is one of the reasons that product documentation gets a bad rap from user communities; why they hate being told to "consult the manual" before calling for support. Most users of software are very good at recognizing the various interface elements and how they work - drop-down menus, radio buttons, fields and forms - these things don't need to be explained, at least not as much as what users should do with them.

Instead of "Click the drop-down menu and select a value between 1 and 89", a manual should explain how the settings will affect the user's goal. The user guide should really be a guide.

Anyway, Michael's article makes a great point - one that all technical communicators should keep in mind. Read it and I think you'll agree.

What size are your blinders?

I got a very friendly email recently informing me that my website contained a typo (Thank you again for that, emailer who will remain nameless).

And sure enough it did - a glaring one. Well, at least I'm not in the writing business.  Wait... oh.

Here's the thing - we all have blinders on. We may not be born with them, but we develop them over years of doing the same tasks over and over again. Anyone who has ever poured juice into their cereal or tried to start a running car knows this.

For me, it's all about comfort zones. When you're in a comfort zone, your attentiveness sort of idles. When you're out of a comfort zone, your survival skills kick in, boosting your attention to things around you.

"So what?", you ask? So, be sure to exercise your attention to detail by leaving your comfort zone from time to time. It may not feel productive, but it will likely keep those blinders from growing into the side of your face.

The bigger picture

Most enterprise software companies write up a special Release Notes document to accompany a new version of their product. The majority of Release Notes that I have come across are filled with the obligatory "fixed bugs" and "new features" lists.

I know for a fact that most customers do read Release Notes. They need to in order to check for bug fixes that impact their implementation or to learn about features that might help their users.

What a great opportunity to shine a spotlight on your application, regardless of what's new or fixed?

Who says the Release Notes have to be exclusively about that release? Why not emphasize new features in the context of existing ones? Or highlight fixed bugs and how they now allow for increased productivity in your product.

In other words, give the facts but don't miss an opportunity to show your customers the bigger picture.

Recipe for success

I enjoy cooking and I wonder if it has anything to do with the comfort of the documentation involved.

Documentation for cooking = RECIPE.

I can honestly say that, without the reliable format of the common recipe, I would neither excel at nor enjoy cooking.

According to my friendly neighborhood etymologist (http://www.etymonline.com), the word recipe was originally used by physicians who wrote it at the head of prescriptions. It meant  "instructions for preparing food". So, there is no question that these instructions needed to be both precise and concise. 

Look at any recipe today and you'll most likely find the following elements:

There is a title: what you will be cooking

There is a list of ingredients: what you will need in order to cook it

There are the steps of preparation: how you will cook it

Isn't simplicity delicious?

Hot off the presses

I'm the proud owner (but not quite possessor) of the new G1 smart phone from T-Mobile. I get to wait a month before I get to actually have it so, in anticipation of my new toy, I got a hold of the Getting Started guide for the G1.

I did this for two reasons: 1) to learn about what I had actually bought and, 2) to see how T-Mobile approached this new user manual.

Aside from the unfortunate and glaring typo on page 18 (Goggle Mail), it's a nice piece of writing. It informs readers on the basic anatomy of the phone, how to turn it on, and other requisite details, but it succeeds particularly well for 2 reasons. 

Layout The document is written primarily in landscape layout with 2 "pages" of content on each real page. This means that the writer didn't really expect people to print out the file - good assumption - and that, to maximize what a person will see on their computer screen, landscape was the way to go because computer screens are oriented in landscape themselves. Smart.

Just the Facts The sections of the document are very short and straight forward, instructing readers on how to accomplish simple tasks. There's little to no fluff. Good.

Add these characteristics together and you've got a very readable document. Maybe more importantly, you've got a document that's easy to skim - who's really going to read anything like this cover to cover anyway?

So, T-Mobile, you succeeded in knowing your audience and giving them a very friendly user manual. I am sorry though that today's modern spell-checkers can't catch it when you spell perhaps your most important business partner's name wrong. Call me - I do proofreading.

Don't build a closet for your skeletons.

If the software you're selling is going to have a few skeletons - and most likely it will - then don't give them a closet to hide in.

It's difficult to design software that is 100% self informative and logical in its use, especially if that software is complex or has more "under the covers" than on top. And your customers know this - they most likely don't expect perfection.

So, if your product has some areas that might not make the most sense, or are downright confusing, say so. Don't pretend in your documentation that these areas are normal or logical if they aren't.  

Now, I'm not suggesting you write a chapter called Where Our Product Sucks and Will Drive You Crazy, but you should include a section for Possible Problems where you can provide tips for navigating the tricky areas. Your customers will show their appreciation for this by a) not calling your help desk, b) training their colleague users, and c) not being annoyed with you.

Those are nice outcomes for such a simple thing, don't you think?

(Oh, and for your next release, maybe you can improve on those tricky areas and use the same Possible Problems section to brag about the improvements you've made.)

What matters most?

I'm not an English major, so I know from experience that perfect grammar doesn't equate to perfect documentation. So what matters most?

Here're my top 5 writing priorities when it comes to helping your customers help themselves:

Know what you're writing: Do your customers need a reference document with organized lists and tables of data? Do they need a step-by-step cookbook for how to progress through a process? Or maybe they just need some well thought-out diagrams?  If someone's expecting one type, and you give them another, you're wasting their time and they aren't likely to forgive you or give you another chance.

Know who you're writing for: Yes, I know I shouldn't end a phrase with a preposition, but I'm ok with it. I trust you'll be ok with it. See that? I know who I'm writing for. Seriously though, if you're writing for techies, then give them what they need. If you're writing for parents who need to know how to assemble a toy, give them what they need. Your audience should guide your writing almost as much as your product should.

Call it what it is: If it's a box, say so. If it's a button, say so. If it's a tab, well, you get the idea. So many products these days, especially in the software world, create their own interface elements and try to create new language for them. So, do your customers a favor and call the things what they are. Don't make them solve any puzzles.

Don't create dead ends: Never allow your customers to get trapped in your product documentation. Make sure your writing always has a way out or a way sideways.

Let your product be heard: I've helped a number of companies write their product documentation and most of them feel inclined to write about every detail, option, variable and setting. But if the product itself informs the user about a certain feature, why waste time and space writing about it? 

The best self-service option is the one that isn't needed. If you do this well enough, you won't even need product documentation. 

Can you imagine that?