User Interface Usability Checklist Part 1

User interfaces are changing quickly, and it can be default to keep up with new designs and trends. The smaller the team the more corners are cut to try and get the product to market. Lots of people advocate the creating and releasing the minimum viable product. This is fine, but companies try to do so without the minimum viable staff level.

Creating a great user interface takes good design, user testing and lots of iteration. Unfortunately user testing is often the first "cost" that is abandoned. The next is the available design time. So when you become incredibly constrained then making good design choices becomes your only course to prevent a horrible mess at the end of the project. I have created a usability check list of common design mistakes. I have seen all of these mistakes in projects from the most expensive to the most basic free apps, and if you can avoid all of them you are well on the way to producing a high quality application.

User Interface Usability Checklist

 1: Using checkboxes where you should use radio buttons

 Checkboxes imply that you can select more than one item, radio buttons indicate that only a single option from the list is available. Sadly too many interfaces have single selecting checkboxes. Radio buttons are also often not the best option, sometimes icons or hyperlinks are better interaction options. I have generally found that radio buttons are one of the least understood generic UI elements, only multi-select lists cause more confusion/

2: Using a checkbox out of enable/disable context

It is important to take care in making sure your checkbox is an obvious boolean state switch, depending on the wording it can be unclear what occurs when you unselect the checkbox. e.g. a checkbox with the label Always print receipt slip. When it is on you know what will occur, but with it off will it never print a receipt or sometimes print a receipt? Remove the ambiguity by renaming the checkbox or provide a radio button with all of the options available.

3: Using command buttons as toggles

Toggling states tends to cause confusion and mistakes, more so when you are using a magically re-naming button.

4: Using tabs as radio buttons

This can cause confusion because the standard use of tabs is for them to just break up areas of the same object into different visual regions of information. If you use them as a data manipulation method to achieve the same type of functionality as a radio button this will confuse users as they will be unsure of what will happen with the "hidden" data, is it saved to the system or not?

5: Too many tabs

Determining if an interface has too many tabs is generally down to individual use cases, however, I have a basic rules of thumb. If you require 5 tabs to display your interface it is important to think is this the best way of presenting the data. More than 5 tabs starts implying that you should reconsider how the interface is displayed. Of course this can be broken, but only with careful consideration.

6: Using input controls for display only

Sometimes people use disabled input fields to display data that cannot be edited. Disabled fields imply there is a way of unlocking them for access, if this is not the case then disabled fields should not be used. However, sometimes people take this one step further and use input fields for display text. input fields should only be used if data entry is a possibility.

7: Always using text fields when data entry needs to be constrained

HTML5 introduced a number of field types, such as email. It is important to use these rather than a generic text field with client and/or server validation (or worst still no validation), especially in the mobile context. Try typing an email address in a standard textbox on a mobile device and watch the spelling correction mess up your entry. Highly frustrating for any end user I am sure you will agree.

8: Disappearing menu items

While contextual presentation of information can be useful in aiding the understanding and interaction flows of an application, it can also hide the available actions and cause confusion in long term users who memorise the application's menu structure. Microsoft XP's start menu is a prime example of this with its short and long menus.

9: Intolerant data fields

I am sure many people have experienced the following problems.

  • Your password must be between 8-10 characters and must not contain $*!. It can be very frustrating trying to create a memorable password that meets those constraints.
  • Enter your phone number, but I'm not going to tell you if I will accept with or without international code until you fail validation as the end of the form.
  • That post code you just used which works on ever other website is not a valid post code. A common mistake is needing to type in post codes in a specific format. XXXYYYY is invalid but XXX YYYY is fine... 

Try to be intelligent in validation so that the user does not get told they are wrong when the computer can easily check to see if a minor reformatting to match the database requirements is needed.

10: No defaults for input fields

Providing defaults can really speed up the interaction with your systems design. Consideration should be placed into supplying defaults.

11: Poor defaults

Defaults are important in allow appropriate customisation of your application, while allowing users to quickly access and use your product. Poor defaults can make your application look rubbish and make people think that the desired behaviour does not exist in your application. Excel's default behaviour regularly annoys me and has caused countless support issues in many companies. If you type in a number such as a phone number it will happy cut off leading zeros and stop the number from having its original meaning. I do not understand this default behaviour, people do not just enter leading zeros for fun, they have a purpose. This is just one of many default behaviours which are undesirably in Excel.

12: Negative checkboxes

Yes there are plenty of websites that have negative checkboxes, check this box to not receive a torrent of useless span from us, they do this to try and trick people into checking the box when they do not want to. Use positive checkboxes to help make sure your users are making the correct decisions rather than checking the box by mistake.

13: Check the titles are right

We have tabbed browsers, multi-window applications, try to identify the tab or window by putting something a little more useful than the domain or application name in the Window / Brower title information.

14: Don't use self-links

It can cause people to consider that they might get directed to a different version of the page you are on. If the page changes regularly then a self link might seem a simple solution to get the page refresh, however, if possible aim for a more dynamically updating page to assist the user in understanding that there is new/changed content in relation to the context of the page.

15: Competing search boxes

Multiple search boxes on a page can often cause problems, using the wrong one can at a minimum make you have to go back, or at worse think there is no information available for a search when there is and so make incorrect decisions from this.

16: Poor search results

Searching is not a simple matter. Most people have no experienced Google and realise that it is possible to have relevance ranked, spelling corrected, sentence contextual returned results. As a developer we realise it is not that simple to achieve a search as good as Google, but often you will have the benefit of a less varied set of data to search over than every web page in the world and so can create a pretty good search rather than just a basic exact text match.

17: Inconsistent terminology

This is incredibly common, and can cause failed interaction very easily. Many terms get switched around interchangeably; user, administrator, client, customer. Try to use just one term depending on what you are referring to, and importantly make sure the whole company agrees, without this agreement the multiplicity of terms will slip into the product.

18: TL;DR (too long didn't read)

Try to make every word count. Too many words can introduce ambiguity, so always try to be short and concise. This requires careful attention and revisiting of old designs to make sure you adhere to this principle.

19: Speaking the language of your audience

Your language should be directed to your specific audience. As a user interface designer you probably know the term "radio button" but if your audience is not part of the programming community they probably do not. One of my favourite examples of this is when a friend of mine was dealing with a support call and he said over the phone "press the windows key". The response was that this did not do anything. As he was not progressing on the phone he went to the person's desk to see this for himself. He found out that "press the windows key" had been interpreted as "press the key that is tapped to the window". Not many people know what the windows key is despite every Microsoft based computer keyboard having one for ages.

20: Vague or misleading error messages

First on the programming cost saving list is error handling. It is sad but true, but clear error messages directing the end user in what they can do to fix the problem is essential. It is very frustrating to get an error message and have no real idea what to do next. What can be worse is a poorly programmed error which suggests the cause is one element, when in fact it is another. These are much harder to deal with and tend to only be picked up if you have a good test team with a good test plan.


Popular posts from this blog

IE9 Intranet compatibility mode in Intranet websites

Intersystems Caché performance, woe is me...

Multi-select with shift on HTML table