Creating a Better User Experience: Write a Quick Start Guide

I had to check and polish up a "Quick Start Guide" for some beta software recently and it was a much more powerful exercise than I was anticipating. This is something I'll now try do for every project I'm on, as it help flush out usability issues from the tiniest details such as common terminology to the very large issues such non-intuitive work-flow early on in the process.

To create the Quick Start Guide, we start with the product vision and sketch out the grand user story. From this, we can then then graft on the specific references to the software, how it supports the users needs and how they have to operate it to achieve their goals. Issues then begin to surface in five major areas (although I'm sure usability experts and designers would find more than I have).

1. Work-Flow Vision. Does the software live up to the vision for the solving the users' problems? If we find ourselves jumping around a lot in the software to achieve things, then odds are that it isn't properly aligned with the vision. This is a very compelling reason for doing something like this as early as is possible. Leave it until the end of a project, and we're forced to twist the vision to fit what we've done, live with the embarrassment and hope our users won't hate us for it. Of course, getting the software and Quick Start Guide into users' hands early is as, if not more important than the guide itself, as they're the real arbiters of usability.
2. Intuitiveness. Does the context of UI elements need to be explained so that they are meaningful? If so, then the interface isn't communicating its purpose efficiently! For example, "...click Start to begin translating the document": the button should probably read "Start Translating" or "Translate Document". Controls that have different effects in different contexts should also be a cause for concern, as this requires the user to build up a complete picture of the internal application state in their minds. Remember, we already have that privilege because we wrote it: the user does not, and will rapidly give up if expected to hold too much information in their heads. Finally, interactions we force the user to make that don't seem to be relevant to their task should also be stamped out. For instance "click Initialise Dictionary to load the language definitions into memory, then click Translate to translate the document". Make it obvious, make it unambiguous and make it matter.
3. Feedback. It's good to end important work-flow steps by letting the user know what visual cues they expect to see. For example "The file will appear in the Translated Documents area" or "a green tick will appear to indicate the operation completed successfully. If a red cross appears, it means there was an error". If this can't be written down succinctly, or there is nothing in the UI to communicate this, then we need to go back to the drawing board and figure out how to add this to the software. A bad example would be "the translated document can now be found using Windows Explorer in the Translated Documents directory set in the User Preferences". When feedback is required to communicate problems, it should focus on the exact error rather than general failure. There's nothing worse than "there is an error in the form". What error? Where?!
4. Illegal Operations. Illegal operations are those things we may need to inform the user they shouldn't do because of the negative effect they may have. Whether the reason is an adverse effect on performance or - the worst kind - something that will cause a crash, it should be fairly obvious that this is cause for alarm. If there is any interaction that can break the software, then it should be locked out. Operations that may have a more subtle negative effect should be warned against in the software, not in documentation, for example pop-ups that say "...this may take some time..." or "...this will break backwards compatibility with version 1.1". For long running operations, a modal progress dialog is a simple solution. Selective greying out is also common for locking out UI controls that could endanger processing, although whole application mode switching can be a much stronger visual cue.
5. Terminology. Is the same terminology used everywhere in the Quick Start Guide and the software? A good way to start kick-start this is to introduce specific terminology and concepts in a short introduction to the Guide, and this may even reveal ambiguities or gaps in the overall vision. Consistent, meaningful and succinct UI terminology (and even spelling and grammar) is all too easy to leave out (how important is it compared to some low level bugs?), but it is incredibly cheap to fix and has a big impact on the user experience. While content and functionality is undoubtedly important, the user experience can make or break an otherwise great product. This "polish job" can be made easier by staying on top of it all of the way through development, and the presence of early documentation as a visionary reference for terminology and work-flow concepts can really help everyone stay on the same page.

Finally, another excellent tip from my Product Manager (thanks Derek!) was to get someone to read the Guide that has never seen the software before! It's easy to overlook the fact that the project team all carry implicit knowledge about the software (together with their pre-conceptions and prejudices).

In suggesting early documentation as a big help in maintaining a strong vision for the user experience, I'm by no means implying that it can replace a strong product vision: this is absolutely vital in creating what's best for the user and successfully guiding a project to success. However, having seen the powerful revealing and magnifying powers of the Quick Start Guide, I'd recommend it as useful tool to help communicate and implement product vision.