How to Design a Walkthrough That Users Will Read

If a new app is a new product, then the walkthrough is the instruction manual. A walkthrough appears when new users open an app for the first time. They get a brief overview of the app’s features before they start using it. This is necessary so that new users can use the app without confusion.

Excluding walkthroughs in your app can leave users confused. But making your walkthroughs hard to read and navigate can also leave them confused. Users will end up skipping them so they don’t have to go through the hassle.

Your walkthrough should motivate users to read it so they’ll know how to use your app. You do this by using clear navigation cues and making your text scannable. Users should also be able to retrieve your walkthrough again if they need to reference it. All these are necessary for a user-friendly walkthrough.

Scannable Text

Text that’s scannable is concise and to the point. Say what you need to say but use as few words as possible. Use headings that sum up your points in just a few words. You can put body text descriptions underneath the headings but keep them short.

Avoid making the user’s eyes work too much by placing the text near the navigation. This decreases the distance between the text and navigation and shortens their eye movement. They’ll be able to read and navigate faster with less effort.

walkthrough-text

Clear Navigation Cues

Some designers will exclude navigation buttons for their walkthrough. Instead, they’ll only display pagination dots and expect users to swipe. Not only is it easy for users to miss such a small visual cue, but it’s not intuitive that the dots mean swipe.

Don’t force users to figure out how to navigate. Use clear navigation cues such as a button with a ‘Next’ label so that users won’t have any doubt on how to navigate. Buttons are intuitive for tapping which every user understands. You can still allow users to swipe to navigate, but make sure there’s a button as well.

walkthrough-navigation

End with Call-to-Action Button

Placing your call-to-action button at the beginning of your walkthrough isn’t a good idea. This will tempt users to skip your walkthrough. Most users will skip it because they’ll feel like they don’t need it. But chances are they’ll end up a confused user looking for the help page if they skip it.

Place your call-to-action button at the end so you don’t give users the option to skip it. This is a more sensible and expected flow that’s better for the user in the long run.

walkthrough-button

Images Should Show How to Use App

Some designers will keep selling users in their walkthrough by touting their features. Once users have downloaded your app there’s no need to sell them on it anymore. Instead, they need to know how to use it. Your images should display the user interface and pinpoint what users need to tap or swipe to use a feature.

walkthrough-feature

Retrievable Walkthrough

After users are done with the walkthrough they may still need to go back and reference it. You should make it easy for users to retrieve the walkthrough by placing a link to it in your navigation menu. You can label the link: tour, tutorial or how-to.

Make Walkthroughs a Walk in the Park

A walkthrough that’s a pain to read and navigate is one that users will always want to skip. But if you make yours short and useful they’ll have no problem viewing it.

A walkthrough is not a help and support page. It’s a quick overview of features to help users get started. In-depth details on how to use the app belong on the help and support page.

One reason people skip instruction manuals is because they take too long to read and are hard to follow. Although a walkthrough instructs users, it should never feel like an instruction manual. Instead, it should feel as easy to read as a sticky note.

Source: ux movement

Author: Anthony

This entry was posted in Knowledge sharing and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


− 3 = two

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>