One of the concerns I hear quite often about documentation is that people aren't reading it. This results in users continuing to ask managers and Admin the same questions, and doing processes incorrectly.

While you can do quite a bit to help users reference your documentation (here are a few ideas), making your documentation easier to consume will go a long way. So today, I'm going to share a tip that may help you in your quest for making documentation easier to understand - using a flowchart.

I really enjoy organized learning programs when they're done right. But when they're done wrong, it is a very frustrating experience. 

Here is the story of a training I attended that was a huge disappointment, and 3 lessons I learned so I never repeat it.

To have an effective training and teaching session, you only need two things:

1. Somebody who is sharing information
2. Somebody who is receiving the information

So why is training so ineffective? That seems like it's pretty basic!

Every organization should include live training (even if the training is virtual). Human interaction is important, especially for new-hires being onboarded or when a new feature/platform/workflow is being rolled out.

But what's the purpose of live Salesforce training? Why are you gathering together and spending precious hours of your day in a room together instead of at your desk working? 

One of the problems with blog articles is that they are one-offs. Going back to find an article that you really like isn't too difficult, but finding and sharing three or four that build on each other and teach multiple concepts is not easy.

So I decided to take last week off from blogging and instead put together a course for creating internal Salesforce documentation.

Reflect on live training events you attended in the past. How did they go? If you're like most, what you got out of the training depended on how you went into it.

If you knew nothing about the subject being discussed, and the training covered intricate details, it was like sitting in front of a fire hydrant. 

If you weren't interested in the subject, it was a huge waste of time. All of the answers being provided may have been great answers, but they weren't important to you.

But if you went in with questions, and those questions were answered, it was a great experience. 

When you put on your own training sessions, are your users drinking from a firehose? Wasting their time? Or is it a great experience for you and for them?

As Will Ferrell's famous SNL character, Harry Caray, would say, "It's a simple question" - why are you writing Salesforce documentation?

Are you doing it because you heard somebody at Dreamforce tell you to "document, document, document"? Are you doing it because... well... that's just what you do - it's part of the job description?

If those are your reasons for writing documentation, then you will never realize all of the benefits documentation can provide. You'll continue to write, and your end users will continue to ignore. 

I was reading a blog article about writing documentation, and I came across this quote:

The purpose of technical documentation is to take someone who has never seen your project, teach them to be an expert user of it, and support them once they become an expert.

While that's a great definition, I think there needs to be a distinction between technical documentation and what you're trying to accomplish writing Salesforce documentation for your end users. 

Even though you documented everything with pictures, annotations, and clear text, a common situation you will find is that end users don't reference your documentation.

All of that time invested in creating a knowledge base, yet you continue to waste time fielding the same questions about how to do something in Salesforce (or you get crummy results because folks aren't following directions).

One reason might be that your articles are too long, making it difficult to find relevant information or see important details. To solve this problem, I recommend breaking up long articles that cover a few topics and/or tasks, into mini articles that each answer one specific question.

The hardest part about creating Salesforce documentation is writing those first few articles. So for those of you who want to use ScreenSteps to create your documentation, I went ahead and created a documentation website with over 150 articles to jump-start your documentation efforts. You can import the entire site into ScreenSteps and customize everything to reflect how your organization uses Salesforce.

If you don't want to use ScreenSteps to create Salesforce documentation, that's fine too - you can still checkout the documentation website and use it as a template to create your own internal wiki.