When all else fails – RFTM (Reach for the Manual)

As UX professionals, we design products and experiences that are intuitive, easy to use.

What happens when a product is released that isn’t clear, and users have to reach for the manual?

If you have any interaction with the Software Development industry, it’s likely that you’ve heard of the Agile Methodology. Agile focuses on small but complete design iteration, in “sprints” compared to the traditional Waterfall method, which delivered everything in one go.

At its core Agile’s focus on an incremental, user focused and iterative approach to development is a good thing, and UX can fit neatly into the process.

There are countless resources for Agile on the web if you want some background reading, with the original Agile manifesto developed in 2001.

Research on how to fit UX into agile has been ongoing for years, and there are numerous online resources available that argue how this should be done properly.

Misconceptions of Agile Methodologies:

Testing isn’t just functionality testing by software testers, and user involvement isn’t just stakeholders meetings every month.
Users should be involved throughout the process, only then will the end products actually serve the user need they were set out to fill.
Without the proper use of UX and user involvement, the product will not end up being the sleek, easy to use, and intuitive product the users hoped for.

And what will happen when users can’t perform a certain task? They’ll go to the help section or to the manual.

This then highlights a potential fail point of the process; Agile puts less emphasis on detailed documentation than Waterfall. Rather a lightweight iterative process of documenting alongside development.

Now let’s look at their Manifesto again:

“Working software over comprehensive documentation”

that can be quite easily misinterpreted to mean that documentation isn’t important. Changes to UI/Functionality could be left out or forgotten over time. Or no documentation could be completed at all.

This leads me to 3 points I’d like to make:

Agile shouldn’t equal zero user documentation.
An Online Forum is NOT an adequate replacement for documentation, as they’re difficult to navigate, and can be intimidating for new users.
Introductory training is great, but it does not replace a manual.

It may sound odd for us to push for documentation, as surely if we’d done our job right, we wouldn’t need the manual in the first place?

Remember that no matter how much testing you do, there is always a margin of error. Things slip through the cracks. Or a development team may skip UX entirely. Yes it happens. Shocking isn’t it?

One of the Nielsen Norman 10 Heuristics for User Experience reads as follows;

“Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.“

So we should really be pushing for this documentation to be precise and clear, to give users a back-up plan, otherwise they’ll get frustrated. The user should be able to quickly and easily identify the task they wish to complete and the explanation should be simple enough that they can perform the task.