I came across a great presentation by Phil Nottingham from a conference called MozCon. Phil discussed some of the flaws behind the current strategy for using video as content, and I thought his advice was applicable to anyone who is creating content for teaching purposes - e.g. Salesforce Admins or consultants who are in charge of training.

Why do we make video?

Sometimes, we just want to create a video because video is impressive. So we approach the video creation process by saying, “I want to make a training video… what should I make it about?” 

Using screenshots to explain how to perform a process to your users is becoming the standard for writing customized Salesforce documentation. If you do it correctly, it's faster to write and easier to read - but if you don't know the best practices for taking screenshots, your users won't find them very helpful.

When you hire new employees (or your existing employees change roles), getting them up and running can be a headache - which is why I recommend creating a quick onboarding guide that you and your users can reference.

In ScreenSteps, you can include multiple images in one step. You probably only need multiple images in a step about 10% of the time, but it's handy to be able to have two images side-by-side when you need it.

We often get asked, "What's the difference between ScreenSteps and WalkMe?" In my last blog post, I showed you how WalkMe works with Salesforce, how to create a walk-thru, and shared some of its many features - so I won't cover that in great detail here.

Instead, I wanted to touch upon some of the differences between the two, focusing mainly on the Salesforce training use cases for ScreenSteps and WalkMe.

While we were at Dreamforce, we heard a lot of buzz about a web app called WalkMe. Several folks asked us whether our product, ScreenSteps, and WalkMe did the same thing. So I downloaded a trial of WalkMe and installed it on my Salesforce Dev account to see what it does. 

It might seem like a good idea for you to always be available and stand over everybody's shoulder to point them through screens - it's fast, it's friendly, and it gets the job done. But in the long run, it might be doing more harm than good.

The best kind of help documentation anticipates questions and problems that your users will have, and then makes the answers available right when your users have them. 

So making contextual help available to your users right in Salesforce can be a powerful tool when you're trying to improve how your organization uses Salesforce - but if it's not done right, it can leave you with the same hum drum results your PDF guides get as they continue to sit in the shared drive.

Here are a few things to consider as you create contextual help articles.

One of the most time consuming parts of a Salesforce Admin's job is answering emails from users with questions like "How do I log a case again?" and "What do I do with a duplicate again?"

Fortunately, this is also the easiest type of inbox filler to drastically reduce. Here are 3 tips for answering your Salesforce users' questions without having to actually answer your Salesforce users' questions:

Just the other day, I was forwarded an email from a friend whose colleague was in quite the predicament:

We are in the process of implementing Salesforce, but before we can roll it out organization-wide, we need to document how our staff members will use the system so that everyone is on the same page and data is entered and used consistently - unfortunately the consultants we engaged to handle the install have no materials to share.

Does anyone who uses Salesforce have documentation they can share with us?