When creating software documentation what could be better than using ScreenSteps? Why, using ScreenSteps with a group of your favorite co-workers, of course! Now you can do just that because today we released ScreenSteps Workgroup, the fastest way for teams to create visual documentation.

ScreenSteps Workgroup works very much the same as ScreenSteps always has. The main differences are:

• Your data is now stored on a central server in your internal network.
• Team members can check out lessons to let others know that they are working on them. ScreenSteps Workgroup’s simple locking functionality keeps team members from accidentally editing the same lesson at the same time.

Now you don’t have to worry about passing lesson and manual packages back and forth or accidentally overwriting someone else’s changes. All of your authors can work together in a simple, straightforward environment.

To learn more about ScreenSteps Workgroup please visit the web page. If you would like to request a demo key so you can try ScreenSteps Workgroup out at your organization let us know.

Learn more about ScreenSteps Workgroup

Our friends over at MindTouch recently released Mindtouch 2010 which has a heavy focus on documentation. Today we are pleased to announce an update to ScreenSteps Pro that makes working with MindTouch even easier.

In the old days (meaning yesterday) if you wanted to publish a ScreenSteps document to MindTouch you had to create a completely new page in your wiki or update a page you had previously created using ScreenSteps.

Not anymore. You can now insert ScreenSteps content into any existing MindTouch page. We think this is a big deal and we think that our MindTouch users are going to love it.

To celebrate this update and the MindTouch 2010 release we are offering a 30% off discount to all MindTouch customers (or anyone who can spell MINDTOUCH). But it’s hot here in Virginia so this sale is going to melt.

Here is how it works. Use the coupon code before Wednesday, July 28th and get 30% off. Use it on Thursday and get 20% off. Use it on Friday and get 10% off. Use it on Saturday and see our online store say, “I have no idea where you got that coupon code from because it isn’t worth anything.”

So, if you want to create some great documentation in MindTouch download the latest version of ScreenSteps. And if you need to add some more licenses to your team, use the coupon code MINDTOUCH to get a great discount.

Purchase ScreenSteps Desktop Pro

Download ScreenSteps Desktop 2.8.5

Read the documentation on updated MindTouch integration

This week we have been running a survey from Survey.io. Survey.io is a free tool that helps you gauge where you are in the customer development process. We received a few questions from users about the survey itself so I thought I would write a post about the purpose behind the survey and what it helps us learn.

Survey.io is pretty simple. You can’t change any questions. All you can do is run the survey. It took less than 5 minutes to set up. Our goals in running the survey were as follows:

1. Help us know if we have created a product that our customers not only like, but love.
2. Help us know what words our customers use to describe our product.
3. Help us know what type of people our customers think should use our product.
4. Help us know what we need to do to improve our product.

The Purpose of the Questions

Let’s go through the questions one by one to see how it works (we ran two surveys, one for ScreenSteps Desktop and one for ScreenSteps Live but the questions were the same in both surveys).

1. How did you discover ScreenSteps (Live)?

This just gives us insight into how people have heard about ScreenSteps. This becomes more important as we look at the results to the following questions. Were customers who came through a specific channel more likely to be passionate users than those who came through other channels? We are still analyzing this data.

2. How would you feel if you could no longer use ScreenSteps (Live)? (Very disappointed, Somewhat disappointed, Not disappointed, N/A)

The purpose of this question is to gauge the product-customer fit. Have we created a product that meets the needs of a specific type of customer? If we get a lot of “very disappointed” responses then we know that we are fulfilling a very important need. If we get a lot of “somewhat disappointed” responses then all we have done is create a “nice to have”, but unnecessary product. That is bad. As a business you want to create a “must have” product.

The results from this question also help us interpret the responses to some of the later questions.

3. What would you likely use as an alternative if ScreenSteps (Live) were no longer available?

This lets us know what products or services our customers are comparing ScreenSteps products against in their minds. In creating our products and services we have followed a lot of the ideas presented in the Blue Ocean Strategy (basically, create a product in such a way that you have very few direct competitors). The good news for us was that according to the survey results we have pretty much been successful in this regard. Most respondents said they either would not know what to replace ScreenSteps with or would have to replace it with a combination of multiple products (Word or Pages combined with some form of a screen capture utility). Many expressed their dismay at the very thought :).

An interesting note here. ScreenSteps Desktop users had a harder time thinking of replacement products than ScreenSteps Live users did. That means that our marketing job is a bit tougher for the ScreenSteps Live product. It also means that we need to do a better job at differentiating the ScreenSteps Live product in our customers’ minds.

4. What is the primary benefit that you have received from ScreenSteps Desktop?

Studying these responses helps improve our messaging. We have created a product that we believe creates certain benefits. But our customers may perceive very different benefits. Or, they may perceive the same benefits but describe them differently. Basically, we want to use these answers to help us “speak the language” of our customers better.

5. Have you recommended ScreenSteps Desktop to others?

This is another gauge of how passionate our users are. A low number here would mean that our marketing job is going to be very difficult. For both ScreenSteps Desktop and ScreenSteps Live the number came in at around 70%. We were very happy with that result. Thank you to all of you who have recommended ScreenSteps to others.

6. What type of person do you think would benefit most from ScreenSteps (Live)?

This questions helps us with both our marketing as well as our product development. We will be studying these results to see if there are groups mentioned that we haven’t considered before. Once again, this helps us know how to better speak the “language of our customers”. We know the job roles we are targeting, but how do our customers describe those roles? We are still looking at this data.

7. How can we improve ScreenSteps (Live?) to better meet your needs?

This seems like a simple product suggestion request but actually becomes much more valuable in the context of the other responses, specifically the responses to question #2.

Let’s break our customers into two groups based on their answers to questions #2. Those who responded that they would be “very disappointed” if they couldn’t use ScreenSteps or ScreenSteps Live are “passionate” customers. Those who would only be “somewhat disappointed” are “happy” customers. Our goal is to turn as many “happy” customers into “passionate” customers as possible.

Obviously we will read all of the responses, looking for overall trends (and we are definitely already seeing some trends). But this data becomes even more important when you segment it between the “passionate” customers and the “happy” customers. If you take the group of customers who would only be “somewhat disappointed” if they couldn’t use your product and then look at what features they are requesting you can get a better sense of how to convert “happy” customers into “passionate” customers.

How Did We Do?

We were very happy with the results. The people at Survey.io say that you really want to have at least 40% of your users who would be “very disappointed” if they couldn’t use your product. The numbers are still coming in for ScreenSteps Live (it is currently at 53%, but that might change with more responses) but for ScreenSteps Desktop are results are as follows:

• 61% would be “very disappointed”.
• 35% would be “somewhat disappointed”.
• 3.4% don’t care what happens to us.

We are still studying all of the responses and there is a lot of data to sift through. But we have already received some great insights into things we can do in the short term to improve both ScreenSteps Desktop and ScreenSteps Live.

Try it Yourself

Survey.io is a free service and really gives some great insights into your business. Try it out for yourself and see what you learn about how your customers perceive your product or service.

When running a customer help desk there are two types of problems a support agent can encounter:

1. A problem that can be solved by referencing your support resources.
2. A problem that requires a decision.

What is the difference and why does it matter?

Problems That Can Be Solved by Your Support Resources

First, let’s define what a support resource is. Your support resources are resources that are currently in place and can be referenced by the support agent. This might include:

• Software documentation
• Video tutorials
• User forums

Another aspect of your support resources are policies that your organization has established for dealing with specific issues. For example, you might have a refund policy or volume discount policy.

If a question comes in that has already been dealt with in your support resources then the support agent doesn’t have to take time to make a decision. Your customer help desk can easily point the customer to the answer they need or refer to your organization’s policy on the matter. No time is wasted making a decision since the decision was previously made and stored in your support resources.

Problems That Require Support Agent Decisions

Unfortunately not all problems are as easily solved. There are many problems that support agents can’t solve by referring to your resources. These types of problems might include:

• A new, previously unknown bug in your product.
• A customer who wants to use your product in a novel way.
• A customer who asks a “how to” question that is not covered in your documentation or forums.

When a support agent encounters this type of problem they have to make a decision. They may need to refer the problem to the development team, contact their manager or seek other resources for an answer. This takes much more time than simply pointing a customer to a support resource.

Improve Your Support by Improving Your Resources

Time is the most valuable asset you or your customers have. Support incidents that require a decision take more time than those that don’t. Your goal as an organization should be to reduce the number of incidents that require decisions. How do you do that? Improve your support resources.

Your support resources can’t possibly answer all questions your customers will have. You will never be able to predict every situation. But your support resources can continually improve to answer more of your customers’ questions.

Assessing Where You Are At

Take some time to take an inventory of your support requests. How many are being solved by your support resources? How many are requiring your support agents to make decisions? How can you expand your resources to decrease the number of support requests that require decisions? Ramp up your resources and you will improve your help desk.

Just read this quote over at Signal vs. Noise by Ed Catmull, President of Pixar,

We all know the saying it’s better to ask for forgiveness than permission. And everyone knows that, but I think there is a corollary: If everyone is trying to prevent error, it screws things up. It’s better to fix problems than to prevent them. And the natural tendency for managers is to try and prevent error and overplan things

“Preventing error” is the biggest impediment to great software documentation. One of the first questions many customers ask us is “How can we make sure that changes are approved before they are published?” This is the wrong question. Organizations believe that software documentation needs to be “proof read” and “peer reviewed”. If each change to your documentation has to go through that process then your documentation won’t ever get changed.

Your first question should actually be, “How can anyone on my team update my documentation at any time?” Your documentation needs to change. Often. Any barriers you put in place to prevent this will come at a huge cost to the usefulness of your documentation.

Unless you are documenting something that has to do with life or death or you have to comply with legal requirements stop being a control freak. Let any of your employees update your documentation at any time. If they write something that is wrong, fix it. It’s not that big a deal. If you can’t trust your employees to be responsible with your documentation then get new employees.

Putting up barriers to changing your documentation hurts your business. At the end of the day, stale, out of date documentation is much worse than a typo or two.

Your customer help desk is probably one of the most poorly used groups in your organization. Your help desk has more contact with actual, paying customers then anyone else in your company. But too often organizations limit the role of the help desk to simply closing out help tickets or answering support calls. Here are three suggestions for getting a lot more out of your help desk:

1. Have Your Help Desk Develop New Products

Your help desk team talks with customers all day. They will often speak with customers who are trying to use your product to do a job that it wasn’t designed to do. If your help desk gets enough similar requests it might be a sign that there is an opportunity for a new product. Have your help desk team enhance your existing product or create a new complimentary product that will work for these customers.

2. Have Your Help Desk Fix Bugs In Your Software

The help desk has to hear customers complain about bugs in your software all day long. If you put the help desk in charge of fixing bugs in your software the most important bugs will get fixed first.

3. Have Your Help Desk Write Your Software Documentation

Your help desk knows what questions customers have. They know how to answer those questions. Let them write your documentation and you will get help files that are more useful to your customers.

By this point in the article you are probably thinking:

“Is he crazy? You can’t have the help desk develop products, fix software bugs and write software documentation.”

No, you probably couldn’t with most help desk teams. But what if you had someone from your product management, software development and documentation teams “man the phones” once a week? Each one of those people would go back to their teams with an amazing amount of insight. Your products would be better. Your most important bugs would get fixed faster. Your documentation would be better.

It’s not about making your help desk people do things they weren’t trained to do. It’s about getting everyone in your organization on the help desk team.

Think this is crazy? Freshbooks has been doing this for awhile with what appears to be great success.

About a year ago we hosted a webinar on software documentation. During the webinar we showed an image annotation technique that is very common and, in our opinion, very ineffective. One of the participants in the webinar said they called the type of image an “Octopus graphic”.

What is an Octopus graphic?

An Octopus graphic is a screenshot that has been abused by the ScreenSteps sequence tool or other image annotation tools. Look at the graphic below:

Octopus graphics have many, many labels describing different buttons (obviously we have exaggerated a little in the example above). This seems to be a popular approach among technical writers which we feel delivers very little value to end users.

What are the problems?

1. Octopuses describe features not tasks.

Listing the names of buttons is of little use. This function can often be handled by a well placed tool tip in the interface. It is much more important to teach your users how to accomplish tasks. If you are teaching tasks then you will very rarely need octopus graphics.

2. Octopuses are cluttered.

With so many labels on the screen it is impossible to process what is going on. If you really feel that you need to label every button in the interface at least break up your labels into different graphics. Try to group the buttons into meaningful collections. People are better able to understand and retain information when it is put into smaller chunks. I would suggest limiting yourself to no more than 5 labels on a single screenshot. A single graphic with a bazillion labels on it presents information in a way that is hard to understand and even more difficult to retain.

3. Octopuses make you think you are done before you actually are.

If you use octopus graphics you run the danger of “documenting” your entire application without delivering any real value to the end user. Once you have labeled everything you may think that you are “done” with your documentation. But your documentation won’t deliver any business value to your organization. Your documentation shouldn’t be “done” until you have helped users accomplish real-world tasks. Octopus graphics don’t help people accomplish tasks.

Throw Out the Octopus

Do you have a lot of screen captures that look like this in your documentation? It is probably a sign that you aren’t taking the right approach to writing your docs. You are spending too much time talking about buttons and labels and not enough time talking about tasks. Start creating more “task based” documentation and you won’t feel the need to create any octopuses.

We obviously believe that adding screen captures to software documentation makes a huge difference. We would go so far as to say that it is the difference between software documentation that produces business results and software documentation that creates door stops.

But simply adding pictures isn’t enough. You have to add the right pictures in the right way. In the upcoming weeks we are going to post a series of tips for capturing images that improve the effectiveness of your documentation.

When we add screen captures to our software documentation we have one goal in mind: clarity. Clarity is all that matters. I want my reader to be able to quickly glance at the screenshot and move on. I want them to only have to process as much visual information as is absolutely necessary. Too much visual information will cause them to have to “study” the screenshot. Not enough visual information will force them to hunt through the application interface.

There are a variety of factors that can contribute to clarity, but in this article we are going to focus on size. If you get the size of your screen captures right then you will make big improvements to the effectiveness of your software documentation.

The goal

First, let’s talk about the goal for our documentation example. In this example we want to show the user how to export a lesson to the clipboard in ScreenSteps. To do this they will need to click on the Clipboard icon. An example is shown below.

Size errors come in two flavors, too big and too small. Let’s look at both.

Too big

Screen captures that are too big communicate too much information. By showing too much information it makes it difficult for the reader to discern what is important.

This first example captures my entire desktop.

The problems with this image are obvious. I have captured so much of my screen that the Clipboard icon is hardly visible. The extra data doesn’t add any value to the screen capture. It doesn’t add clarity. It just adds confusion.

Still too big

The type of screenshot shown above is much more common. Capturing an entire window is easy and it looks nice and clean. But the only thing I need to show in my documentation right now is the Clipboard icon so this is still way too much visual information.

Too small

This approach to adding images to software documentation is very common:

What is the problem with this? You are asking your user to play “Where’s Waldo” with your software documentation. No context is given to help the user know where the Clipboard button is in the interface. Depending on the complexity of your application interface, finding the icon you are documenting can be like hunting for a needle in a haystack.

Why do authors do this? To save themselves the hassle of having to update their screenshots when their application changes. The thinking goes: “If I only have a picture of the Clipboard icon then it doesn’t matter where that crazy software engineer decides to put it. I don’t have to update my documentation.”

The amount of frustration you will cause your users simply isn’t worth the time savings. Don’t do this.

Still too small

This is better but still not ideal. There is a little more context given around the Clipboard button but not enough to instantly communicate where the button resides in relation to the entire application interface.

Just right

Here is what I feel is an ideal size for the screen capture:

Notice two things:

1. We haven’t cropped the application window to remove the desktop background. Showing the borders of the interface help the user quickly orient themselves. Whenever possible, I like to get a corner of the interface in the screenshot. Including corners helps the user know if they should be looking top-left, top-right, bottom-left or bottom-right when following my instructions.

2. We include surrounding interface elements. Once again, we are trying to provide context. By including the surrounding elements I can give the user more “guide posts” that will help them locate the Clipboard button when actually using the ScreenSteps application.

Focus on what matters

I have worked with many technical writers who don’t like the look of this type of screenshot. They would prefer that the edges be tightly cropped for a nice, clean appearance. They are worried about ascetics. I am mostly concerned about clarity.

Aesthetics will give you a very nice presentation piece to show your friends. Clarity will decrease customer support requests, improve user satisfaction and improve your business.

We talk a lot about software documentation on this blog. But running a business requires much more than just software documentation. Documenting business processes is a simple investment that can pay big dividends. By establishing a simple system for capturing and retrieving your business process documentation you can really improve your organization.

Good process documentation has saved us literally 10’s of thousands of dollars by allowing us to do more with fewer employees. But sometimes people don’t know what to document. They think they only need to document “big” things or things that they do frequently. We have found the opposite to be true. The most important things to document are the little things we do infrequently.

Here are 10 examples of things we document that have saved us a lot of time:

1. How to file our quarterly or annual tax forms. A lot of this is done online. I don’t know about you, but our forms are a little cryptic. Documenting this process turned what was usually at least an hour of work into about 5 minutes. Also, I no longer procrastinate the job and thus avoid flirting with late fees.

2. Importing CSV files. About once a week we have to import CSV files from our marketing analytics software to our CRM software. Before the data can come across it needs a little “massaging”. Documenting this has cut a 15 min. process down to about 3 min. and also prevents me from having to deal with bad imports because of mistakes I made in the import process.

3. Issuing refunds. We have a 100% percent money back guarantee on all our products. Fortunately, our customers very rarely ever ask for a refund. But documenting this process for the few times that it does happen has allowed us to process refunds almost instantly. The customer may not have been happy with the product but at least they go away with a positive impression of our organization.

4. Accepting wire transfers. Some or our international customers pay via wire transfer. It happens infrequently but documenting the process means we can get them the information they need right away when that is the only payment option available.

5. Preparing invoices for special situations. Every so often we have invoices that we have to prepare that don’t fall into the standard categories we bill for. It might be some custom work or a special way a reseller needs to be invoiced.

6. Downloading banking transactions. Unfortunately, each of our banks and credit card companies has a slightly unique twist on downloading transactions into our accounting software. Documenting this process saves us time, but more importantly, it gives us less excuse to procrastinate this necessary but dull task.

7. Setting up webinars. Every couple of months we will do a webinar. Documenting how to set up a new webinar helps us focus more on creating great content than dealing with the mechanics of running a webinar.

8. Installing WordPress on our servers. Installing WordPress is pretty easy. But remembering the unique details of how to do it with our hosting company can be a little tricky. After documenting it once it is a breeze to do.

9. Configuring a new computer. Everybody likes getting a new computer right? But getting everything set up can be a pain. Documenting some of the custom settings that need to be made for your work environment or network will make sure that you can add a new system with a minimal amount of pain.

10. Renewing our SSL certificates. This only needs to be done once every couple of years but the instructions our certificate provider has on their site are not very helpful. Documenting this process makes sure we don’t mess up our SSL certs.

All of the items listed above are tasks that we only occasionally perform. Those are the most important processes to document because they are the processes that are hard to remember. Add a little more process documentation to your business and I promise you will see big improvements in productivity.

Just read a good post by Tristan Bishop titled “What if no one READS the manual?” Click through to read all the details but the gist is that technical writers need to become more engaged with end users. This is exactly along the lines of what we said in our post about who should write your software documentation.

Bishop is correct. Many technical writers are going to face challenges in the upcoming years. They will increasingly be judged on the effectiveness of the content they create as opposed to the quantity of that content. As Bishop says:

• The anonymity of our job? Gone.
• Lack of external accountability? Gone.
• Quiet days building intricate books alone in a room? Gone.

Technical writers need to get closer to end users. They need to stop thinking about documentation projects and realize that they are in a communication flow where documentation constantly needs to be created and updated. Speed and an ability to adapt to changing circumstances will be the key skills needed for technical writers in the future.

So where are you at? Do you know how effective your software documentation is? Do you know if anyone is reading it? Do you know if it is decreasing support requests or improving product adoption? If you don’t know then you should find out quickly because pretty soon the next question will be “Are you a necessary part of this organization?”

If you need some ideas for improving the usefulness of your documentation check out our article, “5 Steps to Improving Your Software Documentation”.