I'd Rather Be Writing » ethnography

Martin Luther and Technical Communication

Tom Johnson — Wed, 29 Dec 2010 19:27:39 +0000

I watched an interesting biography about Martin Luther on Netflix while ironing some laundry the other evening. Luther initiated the Reformation of the Catholic Church in the 1500s largely as a reaction against the practice of indulgences (buying forgiveness of sin) that priests carried out. Luther starts his criticism by posting, on a Church door, 95 theses arguing that forgiveness and salvation are free gifts not requiring financial payment.

The Pope declares Luther a heretic and eventually excommunicates him. But Luther avoids death by burning because of the popularity of his writings. Whereas previously the Pope might have singled out and quashed a heretic with relatively little visibility, the invention of the Gutenberg printing press enables Luther’s writings to be quickly disseminated, such that he becomes one of the most popular authors in Europe. Many of his writings are accompanied by visual woodcuts depicting the ideas he puts forth.

Luther eventually gains an audience with Charles V, ruler of the Holy Roman Empire. After Luther defends himself, claiming that he has only done according to his conscience and could not disregard it, the council deciding his verdict can’t achieve unanimity to determine a fate for Luther. Luther returns home, but in the process is snatched away to a secluded castle where he translates the scriptures into common German.

As he translates the Greek Bible into vernacular German, he immerses himself among common people to get the language right. Wikipedia expands on this point: “To help him in translating Luther would make forays into the nearby towns and markets to listen to people speak. He wanted to ensure their comprehension by a translation closest to their contemporary language usage” (Luther Bible).

I find several things fascinating about Martin Luther, which all have some application to technical communication:

He stood up for what he believed in, rejecting an oppressive institution that had the power to extinguish him.
He began his writings with a quick reference guide (95 theses) rather than a comprehensive magnus opus.
He accompanied his writing with visual woodcuts to reinforce his message.
He was an eloquent and gifted writer, at times expressing his ideas in frank, unmistakable language.
He took pains to translate the Bible into a vernacular, accessible language that common people could understand.
He ventured among his users to better understand their terminology, idioms, and manner of speech.
He did much of his translation in seclusion, sequestered away from others.
He leveraged mass printing to disseminate his ideas, which led to a following that fueled the Reformation.

The parallels between the printing press and the Internet are virtually the same. The printing press enabled the Reformation to spread quickly and widely. It decentralized authority by allowing the masses to have copies of the Bible and other books in their own language rather than relying on priests to read and interpret Latin or Greek texts. Likewise, the Internet decentralizes authority and allows anyone with persuasive writing skills to gain an audience and following. The Internet allows you to quickly disseminate your ideas to a wide group of people in a short time period.

Despite some similarities between Luther and the modern-day technical communicator, at least one major, fundamental difference separates the two: motivation. Luther believed so fervently in his cause that it became his personal mission. He was willing to suffer anything because he believed so strongly in it. Technical communicators, however, mostly have a day job that ends at 5 p.m. We are hardly willing to exert the kind of effort that would ignite a reformation. And yet, if we did believe strongly in something, the same tools are available to us to do what Luther did.

Blog Sponsors

Relying on the Wisdom of the Crowds with Help Authoring [Organizing Content #20]

Tom Johnson — Tue, 27 Jul 2010 14:15:05 +0000

The most compelling idea from emergence, which I explained in my previous post, is the surprising wisdom of the crowd. The guesses of 800 people about the weight of an ox at the county fair averaged out to be just one pound from the actual ox’s weight.

The wisdom-of-the-crowds idea is revolutionary. Traditionally “the masses” are unintelligent compared to the elitist class or the lone genius. But now we have a reverse assertion about the formation of intelligent systems.

Now let’s bring this argument to the context of technical writing. You’re creating a help system, but not just any collection of help topics. You’re trying to create an extremely “intelligent” help system, so you extract the most relevant information for your users. You study their tasks and behavior, their pain points and business needs. You write hundreds of help topics describing different concepts and tasks in the application. You organize all the content into logical folder structures, and you even use the same terminology as your users.

You’re not just trying to document every task and screen in the application. You’re trying to create a system of knowledge that answers, in as succinct and findable way as possible, every user’s immediate question. You’re trying to create help that, almost with the snap of a fingers, gives the user the exact answer he or she needs — without frustration, without exasperation, and without requiring any calls to the support desk.

Given the diversity of users, their skillsets, and the problems they encounter, creating this type of help system requires an exceptional skill and genius. It isn’t merely a task like writing an email or composing an essay. A good help system is a complex system that exhibits a high degree of intelligence.

What About the Lone Genius Model?

I don’t deny the validity of lone genius model. Often it takes a lone individual to see past crowd-think and to formulate an original idea. But when it comes to help authoring, I’m not sure the lone genius model works so well. However much you reason out the help topics and their organization, you’re hopelessly trapped by your own perspective. All too often, you include the amount of detail you would need if you were the user. You organize the topics into containers that make sense to you. You use operate from your point of view.

While your point of view may be informed and mostly on target, you won’t have the benefit of organizing your content to meet the needs of the entire crowd without the input of the crowd.

Rather than write and publish your help content alone, consider another model. Your efforts to write and publish help content just get the momentum started. After you publish your help content, it passes through the hands of dozens, even hundreds, of people. Let’s assume all those people read the content and add or edit the content according to their perspective and business needs. Suppose, like Wikipedia, that you have hundreds of users analyzing and shaping the material. They see the problem from a thousand different perspectives. Any gaps, unanswered questions, unexplored bugs and quirks or other need-to-know nuggets of information they add. Now instead of the product of one mind, you have the collective intelligence of the crowd. The information is much more complete and answers every possible question users could have.

Relationships Between Content and Organization

This model sounds persuasive, but it may be more of an exercise in theory than practice. While the product of a thousand persons’ edits may produce complete and thorough information, it also produces chaos in terms of organization. This is evident in any robust wiki. Wikis with a lot of content are almost always mazes of confusion. The WordPress Codex is the ultimate example of this chaotic organization.

It seems that you could describe a type of relationship forming here. The more people who contribute to help material, the larger and more complete the help material becomes. However, the more information you add to a system, the more difficult it gets to organize it. If the organization is weak, it becomes more difficult to find the information. Hence the abundance of information added by the crowd becomes less usable because it is less findable.

As you increase the amount of content, the completeness of information also increases.

As you increase the amount of content, the level of organization decreases.

The more content you have, the less findable it becomes.

Despite this loss of tight organization, a good search engine (especially one with advanced search options) can be a quick way for users to find information even in a maze of chaos. I don’t mind if the organization of information on the WordPress Codex is impenetrable, as long as I can locate a list of relevant results from the search.

It seems that, in the end, you have to trade tightness of organization for completeness of content.

Mission Impossible?

I’m only skimming the issues here. No doubt most tech writers reading this will ask how they could ever possibly leverage an entire crowd to both read and contribute to the help material. Most tech writers never even interact with users at all, let alone have the potential to leverage the input of a crowd of users.

Even if you did have a thousand users at your disposal, what exactly would you have them do? Read through your help with a red pen? No. Give them a big edit button on each wiki page? Maybe. But users leave their marks in more ways than one. The tech writer can gather some of the crowd’s input by analyzing web metrics. If you’re tracking your help, a mass of hits on one topic indicates interest in that topic, so you can expand on it. If you can capture keyword searches, even better.

When you exhaust metrics on your own help system, turn to the granddaddy metric: the support center. What kinds of calls are they getting? Track the incidents logged, and use the resolutions to the incidents to increase the completeness of your help.

You can also gather feedback from the product manager, any trainers, and any other people who interact with your users.

Stumbling Blocks

While this method of gathering information from users to make the help more complete may sound like a good strategy, I doubt it will ever be implemented, for several reasons:

Most tech writers stop working on documentation post-release. Once software is released, the budget for their project ends, and tech writers have to move on to another project. The model I’ve been describing suggests a continuous attention to the product and related issues post-release.
Most tech writers don’t really care. Expectations for the quality of help content are low from pretty much everyone. No one expects you to deliver greatness, and most tech writers aren’t invested in the product enough to go beyond the standard expectations.
Web metrics don’t tell you much. Unless you have an excellent method for tracking how users interact with your help, web metrics will be vague and somewhat unhelpful. The last time I checked metrics on one of my help systems, the hits were abysmal. Most landed on the home page and only sometimes clicked one or two content pages. No strong patterns emerged among the hits. Much of the instructional content (e.g., videos) and PDFs weren’t tracked, and neither were keyword searches.

Conclusion

To be successful and to draw upon the wisdom of the crowds, the tech writer must move beyond him or herself and incorporate the input of the crowd. But in the end, the tech writer usually works alone.

Blog Sponsors

If No One Reads the Manual, That’s Okay

Tom Johnson — Mon, 28 Dec 2009 00:58:56 +0000

Most people take time off during the holidays, so if you don’t, you end up mostly sitting alone at work, wondering why you’re not taking time off too. I wanted to follow Penelope Trunk’s advice about pursuing your pet projects while working during the holidays, but instead I was trying to finish a project with an end-of-year deadline.

The project I’m working on is critical, but it has only about 3 to 4 users, most of whom are already familiar the application. One of the users even drives the design. The manual I’m writing, which is nearly 200 pages, is mostly a safety measure for business continuity planning. I don’t expect anyone will ever read it.

It’s a project I managed to procrastinate for months, working on other projects, even outside the scope of my regular assignments. The main deterrent, I believe, was my perception that no one needed the manual. The users seemed to be getting along fine without it.

And so as the year ticked to a close, instead of learning more about Mediawiki and screencasting and After Effects, I spent my time updating a 200-page manual that I don’t think anyone will ever read. It will be printed out, three-hole punched, and placed in a binder to collect dust on a shelf.

The idea that “no one reads the manual” is certainly not new. But despite this accepted truism, most of us don’t entirely believe it. I think we always have an imagined audience in mind when we write. I often imagine a confused user searching for questions in the help, or a new employee printing out the manual and reading it, making notes in the margins and going step by step through tasks a manager marked. I imagine a user familiar with an application suddenly dumbfounded on a specific screen, clicking help and scanning for answers.

I need this fantasy about the way my manuals are used because without it, there’s no motivation to write.

Charles Hurwitz, a technical writer in Israel, recently had an experience that confirmed the idea that no one reads the help. Charles writes,

Early on in my tech writer career I had the eye-opening experience of walking into an engineer’s office and seeing a multi-volume set documentation on his bookshelf still covered in shrink wrap. I thought to myself that after all the months work on the manuals he should at least have the common human decency to take off the shrink wrap. It’s like buy a painting and hanging it with the painted side facing the wall. Since then when people ask me what I do I tell them I write books that nobody reads. (It’s Official–Nobody Reads the Manual)

In his post, Charles also references a survey by Gadget Helpline that found 64% of men and 24% of women don’t read the manual before calling support (Gadget Problems Divide the Sexes).

It’s not just a matter of putting the manual gently aside. Users actually despise long manuals. Ron Jeffries writes, “Your customer hates big manuals. He has shelves and boxes full of them just like you do.” (Manuals in Extreme Programming).

I believe the discomfort of reading a 200-page manual compares with the pain a dentist administers when removing a tooth, or the frustration an IRS writer creates when he or she makes a long, complicated tax booklet users will have to figure out.

Joel Spolsky, a programmer and web entrepreneur, says,

Even if they have the manual, frankly, they are simply not going to read it unless they absolutely have no other choice. With very few exceptions, users will not cuddle up with your manual and read it through before they begin to use your software. In general, your users are trying to get something done, and they see reading the manual as a waste of time, or at the very least, as a distraction that keeps them from getting their task done. (Designing for People Who Have Better Things To Do With Their Lives)

When I interviewed Mike Hughes several months ago for a podcast, he said the conclusion of most studies about how people use help is that they don’t actually use help.

Some writers still find hope in the rare instances when users will consult the help. Sheila Fahey of Cherryleaf explains: “When things go wrong and it matters to the user, they will seek assistance. They will look for the easiest way to get to the information they need to do the task. If this is the manual, then they will use it.” (If no-one reads the manual, then why bother?)

Looking at help this way is seeing the help as an emergency kit in a car. People won’t normally need the emergency kit, but when you’re stranded on the side of the road in the middle of nowhere and hungry and cold, you will use it. You will break it out of the plastic wrap and actually use it.

Flipping Sides

Not many writers consider the positive aspects of users not reading the manual. If you do a lousy job on the manual, or if some SME discovers typos and inaccuracies, you can just laugh it off by saying no one really reads the manual anyway.

But consider the opposite scenario where everyone reads the manual. Is this a scenario you want? No. Because if everyone has to read the manual to figure out the product, it means the product is so unintuitive and user hostile it’s probably going to tank on the market and you’ll soon be out of a job anyway.

Also, if so many people are consulting the help, you probably aren’t contributing enough on the design/usability side of your technical writing role. Remember that you’re part of a team building a solution to a problem. You want the user interface to be simple and intuitive enough to not require a manual. So if only 10 percent have to consult the manual to figure out the product, that’s a good thing.

No One Knows

Knowing exactly how often help is used and by whom is hard to measure. If your help is entirely online, you can measure basic hits easily enough. But if it’s distributed in print, you can’t really know.

For example, on Christmas day, my sister-in-law was putting together a fish tank and filter for her boyfriend. (By the way, a Betta fish is a cool present to give someone.) Installing the pump and filter was confusing. Was the pump supposed to be above or below the waterline? Was it supposed to be making that humming noise?

At one point, just as she and other family members were getting frustrated, one person jeered, I can’t figure it out, and there’s no manual at all!

More people get frustrated assembling things on Christmas than on any other day of the entire year. It’s a day manuals are both cursed and blessed. But in this scenario, no doubt the company that created the filter was unaware of the frustrated user stuck without a manual. We’re often in the same position of ignorance about our users.

If you think about it, the technical writer is in an unusual role. Users hate the presence of manuals as much as they hate missing manuals. They despise lack of detail yet curse length. If no one reads the help, your position lacks value. If everyone reads the help, you’re on a sinking ship. Ideally, you want the user interface to be simple enough not to need help. But the more you contribute to this user interface simplicity, the less you’re needed.

Conclusion

As the year closes and the project manager is off skiing and the developers are playing video games and the quality assurance engineer is organizing his closet, I’m pounding out the last topics of a 200-page manual that I will soon deliver to a group of users who will smile and thank me for the manual, knowing they don’t have to read it or critique it anymore, but can just put it proudly on their shelf, or maybe even in a storage box.

If I find out, through feedback or on-site visits or other means, that they don’t ever read the manual, that they have never actually opened the manual beyond the table of contents, that’s okay. I hope they never have to.

Blog Sponsors

10 Ways to Gather Feedback from Users

Tom Johnson — Sat, 18 Oct 2008 03:22:44 +0000

User Knowledge Empowers You to Drive the Team

Ever since I came back from Doc Train West and had my epiphany about the transformative, empowering nature of user knowledge with the tech writer role, I’ve wanted to build stronger connections with my users.

Having extensive knowledge of user behavior can make you a valuable asset on any project team, allowing you to deliver key advice on application design and development. Additionally, as in any writing situation, a detailed sense of audience helps you write content much more useful to the audience.

In short, the more user knowledge you have, the more powerful you are as a technical communicator. Here are 10 ways you can gather feedback from users.

1. Create a “Send Feedback” Link in Your Online Help

I add a Send Feedback link on every page of my online help. This allows users a point of connection when they can’t find what they’re looking for in the help. I add the Send Feedback link on the master page of my webhelp target, so one instance in the footer automatically propagates to every help topic.

The link contains a javascript that opens the user’s default email program and inserts the absolute URL of the help topic he or she was on at the time. This link is important in identifying the problem the user was trying to solve, because often the messages users send are cryptic and ungrammatical. It also lets you know they were actually in the help. Here’s the script:

I’ve heard some people say they have feedback links in their help and never receive any customer responses. For an application used by about 1,500 people, I receive about one feedback email every two weeks. The email is automatically distributed to a list that includes our core project team.

It’s cool to receive feedback from users, except when they point out an inaccurate step in the help or a broken link. At that point it’s a little embarrassing, but still preferable to blissful ignorance.

Other times they’re trying to do something that’s not possible in the application. For example, two nights ago I receive an email at 9 p.m. from a user asking how to perform a task. At first it wasn’t clear what he was asking, but by visiting the embedded URL, I could piece together his real intentions.

The program manager saw the email and immediately responded, and I chimed in to the conversation as well. The user who asked the question was stunned at the quick response, and I ended up fixing a step in my help.

2. Track Help Usage with Analytics Tools

Most companies have an analytics tool to track visitors to their corporate site. For example, we use Omniture at my work. Others may use Google Analytics or other site metric tools.

You can add a script to each of your pages that tracks the pages most commonly viewed. From these stats, you can see what problems users struggle with most. (If you don’t know where to get the script, ask your company’s web metrics guru.)

Unfortunately, looking at help site metrics can be a little depressing. I counted about 37 visitors in a month once. Whatever the numbers, viewing help metrics is a reality check.

You can also pull statistics from your application’s database or logs (assuming your application has them, and that you can convince a techie to get them for you). This can help you understand actual application usage and trends. Based on the most commonly used functions, you might strengthen those sections in your help. You could also make your help’s home page a list of the top 10 topics users search for.

3. Monitor Support Center Call Logs

If you have a support center, the service agents usually log calls in an incident management system, and then document solutions and workarounds in a knowledge base. It’s important to stay aware of support center trends. You can often generate reports from their support logs.

You can also view the hits on various topics in your support center’s knowledgebase. If possible, try to integrate your own help material with the support center’s knowledgebase.

At my organization, the service desk agents have an incident management system that ties in with their knowledgebase. Apparently the integration is so close that keywords from the incident log automatically show relevant search results from the knowledgebase.

The first report I analyzed from the support center showed me that a lot of users had trouble logging in to the application. They also needed help setting up their committees and designating the correct roles. Using this knowledge, in the next release of the application we added additional help links to the login page.

4. Observe Users in Their Environment

It’s helpful to observe users in their own environment. For example, the main users for one of our applications are secretaries. I happen to sit near a secretary, and from casual observations, I can tell she spends much of her day scheduling meetings in Outlook and handling other administrative tasks through email.

She’s not a break-it-to-understand-it techie by any means, but she’s hard working and organized. And she seems to prefer print material. Mostly she seems exasperated most of the day, constantly looking at full Outlook calendars.

Wear your help ethnographer hat and go visit your user’s environment. You can often learn a lot about your audience. At a previous company, we provided documentation for financial analysts, whom we never met. One day we went on a field trip to one of their offices. The financial analyst we intended to visit was gone (playing golf with clients, I think), but the secretaries were busy at their desks, buried in paperwork.

We finally did meet some financial analysts at a smaller office. It turns out they had never read the documentation we wrote, as far as they knew. It was somewhat of a shock to both of us. Previously I pictured an aggressive financial analyst skimming the help as he logged numbers in spreadsheets. In reality, we were mostly writing for their assistants.

5. Contact Your Users Periodically

You can contact your users periodically with a friendly email asking if they have any questions or feedback about the application. I don’t often do this, but I have been starting to do it more lately.

Try to think of the last time someone from a major product you use (Microsoft, Adobe, TechSmith, etc.) contacted you to see how the product was working for you. Imagine if a person from Adobe just called to see if you needed any help with Photoshop. My jaw would drop to the floor, and I would never forget this non-marketing-based outreach.

An email can provide an important piece of contact information when a user needs help. They may not respond at the time (in fact, they may probably ignore you entirely). But when they’re frustrated, they’ll remember your email and seek you out. And people who find answers from one source tend to return, like a stray cat to a plate of milk.

Of course, being sought for help may be the last request you want — another to-do item on your already overburdened plate of assignments. If that’s the case, then yeah, you may not want to be reaching out to customers. But if you’re trying to fill yourself with user knowledge, the email may pay off.

6. Build User Profiles/Personas

It’s becoming more and more common to create user personas as means to ground your understanding of your audience. Personas are composite sketches that describe a typical user and his or her behavior. More specifically, a persona is a stereotypical description of an imagined user of your application, complete with a fake name and photo and all kinds of quirky details. Personally, I’ve never written a persona sketch, but I do have several in the back of my mind as I write.

You can pin these personas up around your computer or office wall (they might make great conversation starters) to help you remember who you’re writing for. Envisioning your audience as specific people (“Jim,” or “Susan”) can help you write with greater clarity and focus than writing with only a vague crowd of faceless people.

7. Establish Regular Communication Through Biweekly Tips

Almost no user ramps up to the power level on your application the first week he or she gets access. Instead, the user most likely learns just enough to get by; he or she figures out how to accomplish the needed basics. In this moment of initial learning, the user may read a dozen pages of your 200 page how-to guide. But once somewhat comfortable, he or she lays the manual in its coffin and continues on day after day with basic tasks.

A biweekly tips newsletter (housed on a blog, with posts sent in emails to users) can help spoonfeed that user little bits of knowledge in consumable fashion, helping ramp the user up to a power user in a period of time.

People can learn immense amounts of material if the learning is rationed out, chopped up into little segments and distributed every other week or so. Even the overworked secretary can watch a two-minute video tutorial and suddenly understand that cryptic feature that was really hard to explain in the documentation.

When you spoonfeed your readers with tips, you don’t only ramp your users up to a more advanced level, you also establish a line of communication between you and the users. You strengthen your role on the project team as the conduit and connection point for all those using the application.

8. Become a User of the Product Yourself

There’s no better way to understand your users than actually becoming a user of the same product. If you can start using the product you’re documenting, integrating it into your daily workflow, it can provide a tremendous perspective boost.

The main product I document right now is a meeting management and decision-making tool. When I started using it to record and track decisions for our own tech writing department, it opened my eyes about so many features.

For starters, I noticed that the authoring window was small. A button on the web editor toolbar, however, could expand the window to full view. I found the window expansion button extremely useful, but I had overlooked in my help, since I never had occasion to use it.

You notice little details like this when using the product. For example, I didn’t realize the need for a notes-only workflow in the application until I had to push all my notes through a formal minute-voting process. The application needed a streamlined way to process information-only announcements. Returning to my help, I’m now adding a workaround to the minutes process.

9. Create a User Council

At the last STC annual conference, I listened to a presentation on user councils by a writer from IBM. In her user council, she gathered about a dozen users and periodically met with them to gather feedback, test ideas, and do other mind-altering experiments (just kidding) over the course of several months for a beta product IBM was designing.

In return for their participation on the user council, each user received either a monetary sum or some other benefit. The main incentive for participation, though, was that each user had a chance to improve the software he or she spent much of their day using.

The technical writer carefully tracked all their suggestions and requests and periodically sent them responses letting them know the outcome of their feedback, whether their suggestions were used or not. This made the users feel that IBM was carefully listening to their suggestions.

If you can gather a user council, it’s an excellent idea. Often the user council is spearheaded and run by a program manager. Even if you’re not invited to participate in the meetings, you can follow the notes and other feedback compiled from their sessions.

10. Watch a User Try to Perform the Tasks in Your Documentation

Every once in a while, when someone asks if they can help me, I ask if I can watch them do the tasks in my documentation. This works well for interns in your department, or even other writers who have spare time. If you’re close with one of your users, even better.

Last year I knew one of the admins at my company who wouldn’t mind my little experiment. She asked for a tutorial on an application, and I asked if I could observe her use the help for a while. I scheduled an appointment for an hour and then proceeded to sit at a nearby chair to watch her move through the documentation. Her task involved migrating her department’s web content from single HTML pages to a new enterprise content management system.

As I watched, I realized more epiphanies in twenty minutes than I could gather from three months of editing the help on my screen. She skimmed the help while alternating her view from the screen to the help. She read quickly, and if she didn’t immediately understand, she turned to me for help. On more than one occasion, she actually put her finger on the screenshots and lists and used them to confirm her place in the help. Every five minutes, she was distracted by a phone call or a someone’s request and would have to stop the task. When she returned, she lost her place in the help.

Anytime you can borrow someone for an hour to watch them use your documentation, do it. The activity will show you the weaknesses in your help better than any other technique.

Also, observing users live is preferable to merely asking for feedback. I’ve noticed that when I give others documents to test, the feedback is usually mild. They say, “It was fine; I didn’t have any questions except I noticed this needed bold formatting,” etc. But if you watch the person, you can see their moments of struggle when they sit there trying to figure out what your document says — and where they’re supposed to click. You can see if they actually perform the task correctly as well. (You’d be amazed how people click erroneously with no idea they’re doing things in an unintended way.)

Conclusion

These ten techniques can be powerful ways to connect to your audience. It’s not always possible to implement them all, and every situation has its own needs. But I’m convinced that knowledge of user behavior is one of the most important aspects of technical writing.

Here are the ten tasks in summary. You can pin them up next to your computer and check them off as you attain each one.

10 Ways to Gather Feedback from Users

Create a Send Feedback Link in the Webhelp
Track Help Usage with Analytics Tools
Monitor Support Center Call Logs
Observe Users in Their Environment
Contact Users Periodically
Build User Profiles/Personas
Establish Regular Communication Through Biweekly Tips
Become a User of the Product Yourself
Create a User Council
Watch a User Try to Perform the Tasks in Your Documentation