In the context of an application, we think of a walkthrough as a step-by-step guide that walks a user through a particular task. They are almost always associated with user onboarding. While it’s true that walkthroughs are an important tool for onboarding – they are not the only component of an onboarding experience, nor are they only useful in this context.

Walkthroughs are an important (and relatively painless) way to improve many different elements of the user experience. This post will take a look at some of the broader uses for walkthroughs, build vs. buy considerations, and how integrating them with user and product data can make them much more effective.

Walkthroughs – More than Just Onboarding

Our general experiences with walkthroughs in software are typically as part of an onboarding or training experience. It’s usually run once, and focused on learning basic skills in the application. More advanced learning, or learning later in the usages lifecycle is often constrained to separate knowledge base content. This approach misses some of the key elements of walkthroughs that make them a great training tool for all aspects of application learning – not just the initial onboarding:

• No cross-referencing – users can see the key documentation right in the context of the application.
• Control over sequence – stringing together step by step guides avoids any confusion or missed steps in the process the user is trying to master.
• Learning by doing – seems simple, but learning is reinforced by having the user complete the action as part of the walkthrough.

The walkthrough is one of the best software training tools there is (other than face-to-face instruction). We know that much of the software documentation that is produced is rarely read, and that most customer churn in the software is related to unrealized value. Shifting from traditional documentation approaches to an in-application delivery approach makes a ton of sense for organizations with limited support and training resources.

Using walkthroughs in this manner means that they need to be deployed differently within the application. They will need to be easily accessible to the users without being obtrusive. Users need to be able to start, stop, and come back to the training whenever they need. Placing walkthroughs in an on-screen help module is helpful, but also consider placing them directly as tooltips next to a item in the interface. That way the user has an immediate recourse if they don’t understand something.

Build vs. Buy

The next key point to think through is the approach to creating and deploying walkthroughs. There’s no escaping the fact that guides like this must be rendered within the application interface. This means that either some tooling must be acquired, or development resources must be borrowed to support the implementation. One possible workaround is to deploy the content outside of the application entirely using a browser plug-in. The obvious drawback to this approach is that is ends up significantly limiting the supported platforms, and requiring a client installation to access help – not ideal.

The tradeoffs for walkthrough build vs. buy are similar to those for any other internal tool, and a build vs. buy calculator is a good space to start figuring out which is the best approach for a given project. There are a couple of additional considerations to take into a account when deciding how to approach a project like this:

• Maintenance and walkthrough authoring: Typically the development team will not be the content authoring team. How will updates and publishing of the walkthroughs be handled? What about a workflow for reviews and approvals? Will any change require additional development resources?
• Other costs: Are there any costs associated with a tool outside of the subscription fee? Will it affect the application performance, open up security risks, limit the supported platforms? These factors should weigh on the decision as well.

Using Analytics to Power Smarter Walkthroughs

The other key factor that differentiates walkthroughs from other training methods is the ability to alter the content, or even show content at all, based on insights from the user. Think about all of the different pieces of information relevant to the user context that might impact the training experience. We can think of basic things like browser, device (mobile, tablet or desktop), or local language, that might dictate changes in the walkthrough content that is presented. But there are quite a few intriguing use cases to which we can apply product data to improve the walkthrough experience. Consider the following:

• A user has successfully completed an application task 5 times. The help option no longer shows to them because they’ve demonstrated feature mastery.
• In a satisfaction survey, a user gives a poor review or rating based on usability. They are immediately served options to consume “101-level” help for basic tasks in the application to help them better understand the interface.
• A user’s “basic” plan-level disables a number of features in the interface. Any walkthrough content for those features does not show to them.

Each of these cases helps to address the underlying design tension between clearly explaining capabilities, and simplifying the interface. Tooltips are great, but when dropped like sprinkles across the interface, they scream “massive usability problems ahead”. Product data helps us understand the user context, which allows us to serve up walkthroughs that will be the most helpful, and the training content that will make that particular user most likely to succeed.

Moving support and training content to the walkthrough format, and then deeply customizing that content based on the user context can significantly improve the user experience, and ultimately make the application more successful. When applied thoughtfully, walkthroughs are much more useful than just an onboarding experience.