A long time ago, back when software was still a relatively new thing, developers were still learning how to make efficient programs and code. As such, when they made a piece of software, they usually included a manual that came with it. These manuals were found with anything from word processors to video games, and taught you how to use the software and some tips and tricks on using it.
Over the years, however, we’ve gotten better at making more efficient software. Manuals got slimmer and slimmer, and these days it’s unusual to open a book and read about how a specific piece of software works. Do you remember the last time you had to use a book, or even an online help page, to learn how to use an app on your phone?
Of course, the only way we can make manuals obsolete is if we make apps that don’t need them. So, how do you make software that ‘teaches itself’?
Use Standards
When you’re making software, you might be tempted to revolutionise how people use software. However, there’s no shame in using what’s already set in front of you!
The phrase ‘don’t reinvent the wheel’ comes to play. If you’re designing software or a UI, you can use elements which people use as standard in order to portray meaning to the user. For example, if you’re creating a video player app, you don’t need to write what each button does. You can simply use the symbols associated with Play, Stop, Volume, etc to better present what each button does.
Users also naturally take to UI elements they see in their everyday lives, such as toolbars and drop-down menus. Creating a new UI design just because you can might lead users to become confused on how to use the software, and they’ll have to search for help or email you directly on how to navigate it.
There’s no shame or disgrace using the tried-and-true solutions that are already in front of you. After all, by using them, you’re making the lives of the people who use your software so much easier!
Predicting Inputs
Let’s say you make an Android app. Someone who has never used your app before installs it, opens it, and checks its options. You’ve programmed it so that a pop-up appears with all the options displayed on it. The user sets the options they want. You’ve added OK and Cancel buttons to the pop-up so the user can easily leave the window. However, the user instead opts to press the Back button on the Android phone unit itself.
This is a little strange, as you’ve set up the pop-up to only accept inputs from the buttons you made. But your user just pressed the Android Back button despite the window buttons being clearly on display. Why did they do that? What did they want to do?
This is the benefit of predicting what a user does. Sometimes they won’t use the UI you’ve given them, and will opt to use the hardware at their fingertips instead. People might press ESC to close a window, or the Return key after entering data into a field, or the Home button on Android if they want to go to the main menu.
Good software will predict these user inputs and adapt to them, making them more intuitive to use. Think of the keys that could be pressed and decide what, exactly, happens when they are. In the above example, did the user want to go back and throw away the settings they set? Do they want to save the settings? How about asking them after they hit the back button if they want to save or discard their changes?
Smart Tutorials
Just because you won’t have a manual to guide your user, doesn’t mean you’re not allowed to educate them at all! Sometimes, if your software is particularly complicated and you need to describe something to the user, you can do so using tutorials. Of course, users don’t often like having large amounts of instructions being shoved in front of them while they use your software. The key, then, is to be clever about how you provide your user with this information.
The most basic solution for this is screen-by-screen tutorials. Put a button on a complicated screen which brings up documentation telling the user what to do. While this works, there are even better solutions you can use to help users when they’re stuck.
You could consider tool tips that appear next to the cursor when the user mouses over a confusing element. For example, if you create a game with three difficulty levels, you can make it so that when the user hovers over each difficulty option, it shows a pop-up next to the cursor. This will tell the user about what changes, how it’s harder/easier than the other modes, and what kind of player the difficulty is aimed at. New users can mouse over and learn about the difficulties, while experienced players can simply select the one they want without wading through information they already know!
Allowing your software to teach the user how to use it, rather than forcing them to read up documentation on a website or in a manual, can really improve the quality of life of your software. Designing your software so it explains itself, uses industry standards, and knows what the user wants to do when they make an input, can reduce the amount of confusion a user experiences when they use what you’ve created.
The next time you create a project and find yourself writing up a huge “Help” page to teach people how to use it, why not try thinking about how you can get the software itself to teach people? What kind of elements can you add to educate the user on how to use it?
