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.
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.
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.
Comments