10 simple ways to improve software’s usability

Through various roles in customer experience, software usability testing, self-service support, and technical communications I come into contact with the impact of software usability issues on end-users. What’s more, I see similar issues again and again.

I asked various contacts in user experience and technical communications whether their experience was similar to mine… and discovered there are several common issues that regularly creep into software and have a negative impact on usability. The good news is this means it should be easy to start doing something about software usability, so that users are more confident, can learn how to use it quickly, and make fewer mistakes.

How to improve software’s usability?

Here are 10 things I think development teams can do to help improve usability:

I. Check your end-to-end workflows for key tasks

People I spoke to all emphasised this as the place where all software they’ve worked with could benefit from simple improvements! Your software is almost certainly a combination of bits of functionality created by different people, over a longish period of time. It’s pretty common for individual features to be added – each implemented very well – that just don’t fit with the workflow – e.g. they ask the user to re-enter data that they’ve already entered, they expect the user to have completed a step that they’re unlikely to have done yet, or the user has to open multiple dialogues to make complete the task. Running cognitive walkthroughs can help identify things that need to be sorted out.

II. Sort out your terminology

Terminology needs to be clear, unambiguous, consistent and match the way users understand what they’re trying to do. Hint: if you’ve got configuration options or dialogue boxes with names that are similar to functions or classes in the code, then your UI is using developer terminology – which users are probably not going to understand.

III. Check your consistency

If you’ve had several developers working on different areas of the UI, it’s likely that similar functions are named and work in slightly different ways – for example “Save changes” in a configuration dialogue works differently from “Save changes” in a user management area. This can be confusing (not to mention meaning you may be maintaining more code than necessary).

IV. Rewrite your error messages

All your error messages should tell people what’s caused the error and what they should do about it. People do read error messages…and if they need more help understanding them, they contact your support team or they Google, so don’t forget to also include an error number or short description so they can easily describe the error they’ve encountered if they need to.

V. Reduce the number of errors users will encounter

In particular, look for errors that are generated because of user behaviour… and find a way to prevent or catch that behaviour earlier. For example, if passwords need to have a combination of letters and numbers, say so; if a field is mandatory, make it clear that this is the case – instead of telling the user they’ve missed it after they’ve clicked the “Submit” button.

VI. Remove a feature

Some research by the Standish group nearly a decade ago found that over 60% of software features were rarely used or never used.  Features like that get in the way of your users finding the good stuff. So if you’ve got features that have crept in during development “just in case the user wants to do x” or because the development team had written the code and might as well make use of it … consider taking them out and making sure they really are of value to users before you add them back in.

VII. Rename buttons

Except in a few standard dialogues, standard buttons like OK and Cancel aren’t very helpful. You may have given them a sentence or two of text to explain what they’re doing, but are you sure it’s clear from that plus the button names what their deciding to do? For example, if you present a message that asks the user “You have unsaved changes in your file. Would you like to save before you close it?”, isn’t “Save Changes” vastly more helpful than “OK” or “Yes”?

VIII. Check defaults

Could empty fields be populated with data you have about the user or their system? Are the defaults the most likely values that users will suit users?

UPDATE: if you need convincing on the importance of getting this right, this article from Jared Spool is well worth a look – it confirms your users are counting on you to get defaults right for them!

IX. Only offer functionality that really is available to the user

You’ve probably done this already, but it’s worth double-checking. Disable options, buttons or fields that don’t apply, and only re-enable them when they do apply (it’s usually best not to hide them completely, though – it’ll confuse people when the functionality appears).

X. Put some “help” in the UI

I’ve seen time and time again in usability tests and through analytics data that users do make use of tooltips, pop-ups and links to useful information or video demos. Don’t put extra text in just for the sake of it, but if there are options that you know your users struggle to decide between, then give them a bit of help … or if there’s a button your users aren’t sure about clicking, add a tooltip that explains what will happen if they click … or if there’s a screen where users have to take some action to get started, use the blank space on the screen to present some tips or link to your video walk-through.

P.s. this should go without saying by now, but before you add this sort of help, make sure you’ve got your buttons, options and all other components named as usefully as possible. It may be that you don’t need help at all – just better labelling.

What have I missed? I’m sure this list isn’t comprehensive – what else should be there?

What next?

Once you’ve done all of these, you’ll have got rid of a lot of the obvious bugs. To develop a more in-depth understanding of how usable your software currently is (or isn’t) and work out what to do about it, usability testing is a sensible next step – preferably integrated into your development processes.

p.s. thanks to everyone who contributed to this on Twitter, discussion forums and in person.

Originally published on 05.11.20