The Email Game

The Email Game works only with Gmail and Google Apps. Once you type in your email address, The Email Game sucks in about 50 of your latest gmail messages and lets you process them rapidly — replying, archiving, labeling, and so on. There’s a timer counting down with each email, so that you don’t spend too long replying.

For email that I need to save and address later, I label it with the Next, Action, or Waiting On labels that come with ActiveInbox. ActiveInbox is a plugin for Gmail that incorporates some Getting Things Done philosophy into email.

Using The Email Game in combination with ActiveInbox works beautifully.

One limitation with The Email Game is the inability to log in and thereby save your email signature. However, if you bookmark an address like the following:

emailga.me/login?email=joe@gmail.com

then it logs you in automatically.

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

For the past couple of years, my gmail inbox has been flooded with so much email that unless I respond to incoming email within a day, it gets buried with other incoming email. I’m guessing that many others have a similar problem.

Gmail has come out with various solutions — priority inboxes, stars with various colors to note importance. But I finally bit the bullet last Sunday afternoon and created about 30 filters to make non-essential e-mail automatically skip my inbox and be filtered in the sidebar. With all the non-essential email out of the way, I can focus on the important communication — the email that is actually from a real person to me, and which requires a response.

I set up filter to automatically catch non-essential email and make it skip my inbox. This leaves my inbox free of junk.

The list of automatically filtered email is pretty long, and includes most of popular online services such as Amazon, Facebook, Goodreads, Netflix, Paypal, Linkedin, Google Plus, Twitter, and a host of other non-essential sites. A good majority of it includes social media updates, and I even (sorry guys) have a filter for Blog Comments.

Rather than minimizing the non-essential email messages, the filters allows me to review them in a more streamlined way, since they’re all grouped together rather than scattered about my inbox.

Filtering out nonessential messages also allows me to better focus on the task at hand rather than checking out the Gmail notifications that appear every few minutes in the corner of my screen.

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Citing research in sociology, Penelope explains that “people who work are happier than people who don’t because people who are employed spend more of their time being creative.” Creativity, then, is an important factor in personal happiness and fulfillment. Most of us know that. But here’s how you measure the degree of creativity in your work. Penelope says,

How can you tell if you are creative at work? You could just ask yourself if you like your job. It is nearly impossible to like a job if you are not solving problems that are challenging. And if you are doing that, well, that is creative.

For a more scientific gauge, you can look at your cell phone call log. If you routinely call your friends from work, you’re probably not happy at work, according to research from Nathan Eagle, at the Santa Fe Institute.

In other words, one measure of creativity at your job is whether you’re solving challenging problems all day. If you’re not presented with these problems, then most likely you’re talking on the phone instead. (Keeping yourself busy with e-mail, Twitter, IM, and other online chatter is the equivalent of talking on the phone.)

Most people consider writing to be a creative endeavor, and in some situations, it certainly is. But creativity is not just associated with writing, art, and the humanities. Penelope broadens creativity to include problem solving too.

In many ways, even though technical writing involves writing, the writing can be less creative than coding a program or creating a user interface. Technical writing can even be less creative than designing the look and feel of the online help that will house the writing. Many times writing procedural information is not creative at all, in fact. Sure, there’s a need to figure out how the application works, but once you’ve done that, merely transcribing how to do tasks in the system can make you start yawning. There are no more problems to solve. It’s mere knowledge transfer. When knowledge transfer is what you spend your day doing, technical writing loses the power of creative fulfillment.

On the flip side, because technical writing poses numerous technical challenges outside of writing, with solutions not always apparent or easy, technical writing can also be engaging. The technical side of our profession is actually what engages me more than the writing, even though I was initially attracted to the idea of writing.

I’ve been thinking about this unexpected reversal a lot lately because I’ve noticed how consuming I find technical challenges in contrast to writing. I’m drawn to problem solving with web issues, especially WordPress sites, to an almost addictive degree. When I’m working on a WordPress project, it consumes me entirely. I can easily sit at the computer for an entire afternoon or evening working on problem after problem, ignoring everything else. Building websites often includes an almost endless supply of problems to solve.

Changing how something looks is only one part of the game. Finding the additional functionality you need, figuring out the best way to organize the content, designing the navigation with usability in mind, configuring new plugins — all of these questions and problems provide engagement with the mind. For me, coming up with solutions is a creative act that surpasses the writing of technical procedures.

Fortunately, writing only takes up a small part of the technical writer’s day, as Shanghai tech writer notes. Once you’ve finished the writing layer of a project, there are countless other technical issues to address, everything from single sourcing the content to designing the online help skin to figuring out relationship tables in Flare. I used to think these tasks were ancillary to the core task of the written content. But now I realize that as far as engagement goes, it’s the other way around. The technical challenges are the rewarding, creative part.

Blog Sponsors

• 3Rabbitz book
• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Webworks and Twitter -- Innovative uses of Twitter with documentation

Earlier this week I asked how others are using Twitter in their documentation and branding strategies. Alan Porter at WebWorks wrote me with details, saying:

As you know we have a branded Twitter account (webworks_com) that we use for product announcements, information on speaking engagements, webinars and just general company updates. We also have a hashtag set up for information related to our annual RoundUp users conference.

We are also encouraging our partner companies, and consultants that we work with, to set up Twitter accounts, and several of them have set up accounts and are using them.

We actively follow all the top Tech Doc twitter accounts like yourself, Sarah O’ Keefe, Scott Abel, Anne Gentle, Paul Mueller, Alan Houser, etc., as well as any STC region that is on Twitter. We also follow any customers that we know have Twitter accounts.

Several of the WebWorks staff have personal Twitter accounts. The two most active are:

• Me — I tend to post on my STC related activities, and my freelance writing projects.
• Jennifer Whitley — Jen posts a lot about social media; she is also a pilot and posts a lot about flying.

There are several other people at WebWorks on Twitter, including the CEO and Support Staff, but as yet they aren’t as active.

OK, so how do we use Twitter as part of our documentation strategy?

1. Currently we use an RSS feed from Twitter search to be notified of anyone asking questions about the product. When that happens, we respond by Twitter giving them a link to either our documentation wiki or our Help Center wiki as needed.
2. We tweet about updates and new topics added to the wikis on Twitter.
3. We tweet about technical blog posts. By the way, we just launched a new blog site at http://blogs.webworks.com.

We are considering doing some prototype work on the following:

1. Integrating the Twitter feed directly into the documentation wiki based on hashtags and RSS.
2. Having recent changes to the wikis automatically generate a Tweet.
3. Have the WebWorks Twitter account feed directly into the product online help for instances where the install is connected to the internet.

As I said these three are just conceptual ideas at the moment, and we are doing some experimental work around them. I’m also talking to a couple of other companies that are looking at integrating Twitter (or social media in general) with their corporate publishing strategy.

I’m impressed at the extent that WebWorks incorporates Twitter into their work, especially their use of hashtags to identify different areas of their documentation.

I was about to post Alan’s response when I saw a tweet from Dan Maurer, a technical writer in a rhetoric and professional writing program, saying he might write a masters thesis on Twitter and technical communication. I asked Dan what he thought of WebWorks’ use of Twitter.

Dan thinks Webworks’ use of Twitter focuses on the user, which is a good thing. And services that send Twitter direct messages when a wiki entry is updated are useful, especially for people who prefer this type of communication.

However, Dan fears that this is “just another method of getting word out to the user. A new way, and one that’s useful, but not really different from an e-mail list, blog, or RSS feed.”

So exactly what is the value of Twitter, in contrast to other means of communication? What unique quality does Twitter bring to the table? Dan lists three unique characteristics of Twitter communication:

1. Low attention threshold. (140 characters)
2. Mobile capability.
3. Networking. Our @ conversations are public … that’s how I find new people to follow.

But if given the option to subscribe to Twitter, RSS, or email to stay updated about a product, Dan says he would choose RSS, because it keeps his inbox free.  “I use Twitter for conversations with interesting people, not to learn about the newest gadgets. Again, that’s what RSS is for,” he says.

I agree with much of Dan’s analysis. If one technology already fulfills a need, there’s little value in duplicating it with another technology. However, given the increasing amount of information we must sort through daily, the limitation of 140 characters per message is appealing.

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:

            <script type="text/javascript">/*<![CDATA[*/document.write("<a href=\"mailto:youremail@company.org?subject=ACME%20Application%20("+document.title+")&body="+location.href+"%0A%0A"+"\">Send Feedback</a>")/*]]>*/</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

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