As our content continues to spread to mobile, we have to rethink and adjust our help to cater to the special needs of mobile users. Unlike with desktop help, there aren’t any real standards out there for help on mobile apps. So how should we adapt when writing mobile help? To understand that, let’s take a look at some of the challenges surrounding mobile and at what methods already exist that might address these challenges.
Differences and Challenges
Users learn about and consume content differently on a mobile device than they do on a desktop PC. The two platforms are not at all alike and so the method for delivering help content has to take on a whole other shape on mobile.
On desktop, our traditional help generally leads users away from the product. This isn’t a problem as it’s fairly easy to switch between screens when you’re on a desktop computer. You can also arrange the help content and the product you’re working on side by side so that you can follow along when using help. On mobile, accessing traditional desktop help isn’t really this practical or user-friendly since it’s not an option to switch screens easily and, on many devices, not possible to have your help and app screens appear side by side. You also have the additional worry of writing for a very small screen: open up your desktop help on mobile and suddenly a table that appears just fine on a regular computer gets cut off and is hard to see and navigate.
In addition, even if you keep your desktop help as succinct as possible, you have a lot of freedom to add details and information. On mobile, there’s less space for information so your goal is to keep to as few words as you can. Also, people using mobile devices are on the go so their attention spans are even shorter than those using traditional help. They want to know what to do as quickly as possible and move on.
There are also differences in terminology. If you decide to reuse your desktop help, you’ll still have to customize it for mobile with new terms: where you click a mouse and press a keyboard on desktop, on mobile you tap, double-tap, swipe or pinch.
Other challenges and things to think about when writing mobile help are your screenshots and videos. Are these useful on mobile? On desktop, screenshots are useful for telling users what to look out for but on mobile, screenshots can appear too big or hard to see, they don’t fit as well which might confuse users who may try to tap or interact with your images when they think they’re inside the app.
What about videos? Whereas on desktop there are many different options for capturing screens for videos, on mobile it’s a bit more of a logistical challenge: there are very few apps that let you do this efficiently. In addition, as mentioned above, since you can’t have your screens side by side, watching a video and referring to the product at the same time is either impossible or very challenging.
What about inline help and tooltips? On desktop, these are a great tool for helping your users since they can see your help right there inside the product. You can show users inline help when they fill out fields or if they mouse over a button you can show them a tooltip. Unfortunately on mobile, there’s a lot less real estate and your stakeholders most likely won’t want to clutter the page with inline help. As for tooltips, since you can’t mouse over, there’s no real practical solution for incorporating these.
Best Practices for Mobile Help
So given all of these constraints, what are the best practices for delivering mobile help? What works for users?
Show up when needed: The best mobile help shows up when and where it’s needed the most. Help for mobile is best when it’s within the actual app and not on a separate page that you have to click away to get to.
Short and to the point: Short help, broken into pieces, works best. Mobile users have short attention spans and want to read less and do more. Also, scrolling or page turning is uncomfortable and harder to follow and navigate.
Don’t get in the way: Mobile help shouldn’t get in the way of a user using the app. Pop ups that show up in the beginning distract users from the app and might not really be useful. If a user doesn’t need the help when it appears, the user might be frustrated instead of finding your work helpful.
Not all at once: If you give a user too much at once, they may not remember all of it or know if they need all of it and when they do need the information, most likely they won’t remember it. Gradual help is best, slowly reveal different things that a user might need to do in the app as they come across these different features.
Not too much: You want to give enough help, not too much. Don’t overload your user with information. Provide only the details that the user needs.
Help only users that need it: This may be the hardest to achieve. If in-app help shows up when a user doesn’t need it, it might frustrate and get in the way of the user’s experience with the app instead of helping. Your goal is to help the frustrated users that need the help but leave the savvy users who want to figure it out for themselves alone.
Current Methods and Issues
What are current methods for showing help and what are the issues with them?
Overlay: A greyed out screen pops up over your app screen and points out different buttons or aspects of what you’re looking at, similar to tooltips in a way.
If this is something that pops up in the beginning, users won’t have context for it as they’ve never used the app before and they won’t remember all of the information if there’s too much of it.
If you’re using an overlay, consider showing it when a user is more familiar with the app and only point out a minimal number of features at a time. Maybe show several different overlays throughout the app.
Also, since a spontaneously appearing overlay can get in the way, you may want to trigger it only when someone needs it as opposed to showing it when a user gets to a certain screen.
UI walkthrough: Billboards that pop-up when a user opens an app and give users a few details or information about the app as they swipe through it.
Most of the time these appear to first time users when they open an app so a user won’t have the context for what they’re reading or learning about. They’re also not gradual and don’t help users discover an app. They usually bombard the user with too much information that they won’t remember and get in the way of users who just want to play around and see if they can understand the app for themselves. They’re popular because they’re relatively easy to implement, but they’re not necessarily useful to users.
Traditional help center: A traditional help center that documents the app.
These are useful as a tool to document your app but as mentioned, may not be as useful as they are on desktop. For mobile help, keep your help center short and to the point.
If you find a more creative way of using this kind of help, it may also prove useful. For instance, I once saw an app where the help would appear when you pulled down the screen. The help was in the form of tips that you could swipe through and you could still see the app underneath the tips for context. The tips were there whenever you needed them without leaving the app screen. You could make an even more useful version of this kind of help if the tips that appeared when a user pulls down the screen are only those relevant to the specific app screen the user is on.
Dummy text: Greyed out text that appears in a field and gives you more information about the field. For instance, in a search field, you can have text that tells you to type a search term and tap enter.
This is generally useful because it’s there when you need it but doesn’t get in the way: the text disappears as soon as the user taps into the field.
This kind of help has very limited use though as it’s only relevant if there are fields of some sort.
What are your thoughts? What are your personal experiences with mobile help and dealing with these challenges? Do you have new ideas or methods for presenting mobile help?
Disclaimer: I’m currently a technical writer at Google. The views and opinions expressed here are my own and do not necessarily reflect those of my employer.
Resources and interesting articles
“10 Realizations While Writing Documentation for a Mobile App.” idratherbewriting.com.
“Are UI Walkthroughs Evil?” Tapity.com.
“If you see a UI walkthrough, they blew it.” MaxRudberg.com.
“Rethinking the Mobile App ‘Walkthrough.’” TechCrunch.com.
3 Examples of Inline Help. Baymard.com.
Mini-IA: Structuring the Information About a Concept. Nielsen Normal Group.
Mobile Content Is Twice as Difficult. Nielsen Normal Group.
First time user experiences in mobile apps. Kryshiggins.com.
Rethinking Mobile Tutorials: Which Patterns Really Work? SmashingMagazine.com.
Video: “Extra Credits: Tutorials 101”.