UX Thoughts – Learning Phase Tools II

In my last post, I’ve made the point that traditional user manuals, help files are not too effective to get your users acquainted with your software. So, let’s see what else can we do?

Let them play

A lot of users like to play with their new software and discover its features by looking through menus, hovering over toolbar buttons, entering random data and pressing buttons here and there just to see their effect. Playing with the software, creating documents and whatnots without the only goal of getting to know the application is a perfectly valid, enjoyable and good way of learning it. I certainly belong to the “let’s see what this baby can do” category, and probably you do, too. On the other hand, some people - especially those not too tech-savvy – may not be too inclined to just play around, in fear of maybe breaking something or ruining the entire computer. Now, unless your application is controlling a nuclear plant, I suggest you have a look at it from this perspective. Does it allow for random, quick exploration? Can the user do any harm in while doing so?

One of the technically most difficult tools for allowing such a playful exploration is by adding an

undo feature. With Undo, users can confidently try new ways of doing things, play the “oooooo…. what does this button do??” game. And the best way of learning is to try things for yourself.

You will also want to make sure that users can actually discover the features they can experiment with. There is not much use (from the exploration / learning phase standpoint) if your greatest feature is hidden behind the Ctrl-Shift-Alt-7 keystroke. It may be fairly productive (see productivity phase later in this series), but absolutely not discoverable. Show the possible actions in menus, buttons, toolbars, handles to make them visible.

Self explanatory UI

We all heard of intuitive UI, and used metaphors to represent ideas. Usually these metaphors reflect real life objects. For example, there is the Trash Can – dragging documents onto it clearly throws it out. Windows has a recycle bin, indicating that even files in the bin can be recovered, recycled. We also have the floppy disk icon that has been analogous with the “Save” function since… er… well, since we use icons and floppy disks.

Now, here is the problem with these metaphors. I have a son, who is two years old. He has never seen a 3.5” floppy disk. These days most computers don’t even have floppy drives, and even CD/DVD drives are not necessary – most netbooks and some notebooks don’t even have one. So, while it is completely obvious to me, what the floppy disk icon means and I can associate it with a real world data storage object, my son will probably never use one. He will have different cultural background, which is a problem when you are trying to compress a lot of meaning into a 16x16 icon. He may learn that this funny looking square is how to save documents, but he won’t have the real life connection. And in ten years, we may have a completely different icon for the save function – a USB key for example, or an arrow pointing into the cloud?

There is one more problem with metaphors – they can become too crowded. For example, do you know how to eject the CD tray on a Mac? You drag it onto the trash can. Now this is something that no sane person would do without prior knowledge as putting stuff into the trashcan means you want to delete it. If I want to get the CD out of the computer, why would I try to delete it? Now, the Mac OS has improved upon the original design by turning the trashcan into an “Eject” icon upon dragging, but this is still something that feels a little bit awkward to me.

So, UI may seem to be intuitive, and your metaphors may be extremely self explanatory – but if you are writing software for people from different background (even in the same family), you will have to allow for some explanation and exploration. One way of assuring that you are on the same page with your users is to use their

Already existing knowledge

about computers, the problem domain. The best way to do this is to study other software, and follow written guidelines. For example, here is Apple’s Human Interface Guidelines, and here is the Windows UX Interaction Guidelines document.

Another way to help users reuse their already existing knowledge is to be consistent. For example, most of the Office 2007 applications have a consistent Ribbon-based UI. If you have already learnt how to use the Ribbon in Word, you will have no problem using Excel. And as a UX designer, you can leverage this knowledge by reusing the Ribbon in your own application – just like in the case of menus and toolbars, users will immediately feel familiar with your app.

By the way, the Ribbon strikes a very good balance between discoverability, usability, learnability and productivity. It is an excellent UX achievement from this standpoint – maybe I will share my thoughts on it in a later post. However, in my next post in the UX thoughts series, I will continue to discover the tools designers can use to help getting through the learning phase.