Unless specifically mentioned, these guidelines apply to websites and web applications, and desktop, mobile and tablet versions and will be referred to as ‘application’.

While referring to these guidelines, keep in mind that usability is in relation to its context of use. These are guidelines and should apply in most cases, but will certainly not apply in all cases. 

The 118 usability guidelines are divided into 17 sections:

1. User interface consistency
2. User feedback (task completion, loading content indication, notifications, session timeouts)
3. Tasks (multiple-page tasks, error avoidance and recovery)
4. Navigation (breadcrumbs, persistent navigation, site structure, back button, navigation labels, links, tabs)
5. Layout (grid-based design, prioritizing information on pages, spacing, horizontal scrolling)
6. Forms (minimum fields, completion time, correct usage of input fields, creating logical groupings, multiple-page forms, tabbing through fields, mandatory and optional fields, error avoidance, errors, success)
7. Error pages
8. Confirmation dialog labels
9. Tables (sorting and filtering, highlighting the hovered row, formatting data in cells, aligning table data)
10. Help (instructional text, frequently asked questions, contextual help, human help)
11. User interface writing (plain language, summaries, page titles, acronyms, abbreviations and initialisms, exclamation marks)
12. Printing
13. Multimedia (audio and video, icons)
14. Search
15. Multilingual applications
16. Privacy policy
17. Newsletter subscriptions

1. User interface consistency

1. Every user interface component in the application should look and behave consistently without exception.

2. For desktop versions of the application, the hand icon should be shown when the mouse points on anything that is a link or triggers a visible action on the page.

3. The same header and footer should appear on all pages of the application.

4. If the height of the application page is less than the height of the viewport, the footer should stick to the bottom of the viewport.

2. User feedback

Task completion

5. Easy to understand feedback should always be provided when a user performs an action in the form of a success message, error message or notification.

Loading content indication

6. The underlying user interface and content should appear together and not one after the other.

7. Use skeleton screens or skeleton components if the user interface will take longer than 1 second to load.

8. If the user interface or content is going to take longer than 6 seconds to load, use a loading indicator.

9. If the user interface or content is going to take longer than 6 seconds to load, use a loading indicator.

10. If the user interface or content is going to take longer than 10 seconds to load, use a progress indicator, and ideally let the user know how long it loads up in.

Notifications

11. If the application is going to take longer than 10 seconds to complete a task the user has relayed the application to perform, the application should provide immediate feedback that the task is underway in the background, and that it will notify the user once the task is complete (and through what medium, e.g.- notification through application, email and/or text message). The application should also let the user know that they can safely navigate away from the page (assuming the application allows it, which is very much desirable) in the meantime.

Session timeouts

12. The application notify users much before automatically logging them off.

13. It is also recommended that at this point, users be given the option to extend their sessions or log out.

3. Tasks

Multiple page tasks

14. If a task extends across multiple pages, use a step indicator to let the user know what the steps of the process are. It should show the user how many steps have been completed, the current step they are at and how many steps are remaining to complete the process.

Error avoidance and recovery

15. As much as possible, eliminate the very possibility of the users to make an error in the first place. 

16. Users should have the option to undo critical actions.

17. Seek the users confirmation before carrying out actions that may result in severe errors (e.g.- deleting files).

18. Provide users the ability to recover deleted items. 

19. Provide users with the ability to version content and rollback if needed.

4. Navigation

20. High frequency topics and tasks should be accessible to users within a few clicks from their most frequent points of application entry or stay.

21. Navigation choices should be grouped and ordered according to the users’ logic. This will probably be different from how they would be logically grouped and ordered for an employee of the organization. 

22. It is recommended that the application provide contextual navigation that makes it convenient and obvious for users to move between pages and sections they will need to or might want to be at.

23. Try and keep navigation items grouped with up to 7 items per grouping and up to 7 groupings. 

Breadcrumbs

24. Breadcrumbs should usually be present on all pages but the homepage. 

25. The current page in the breadcrumb need not be a link.

Persistent navigation

26. The major sections of the website should be available from all pages through persistent navigation.

27. The homepage link should be apparent and available across the application.

28.It’s safe to use the application logo in the header as a homepage link. 

Site structure 

29. The navigation system should be broad and deep (broad and broad ideally) rather than deep and shallow. 

Back button

30. The back button should take the user back to the page they came from. 

Navigation labels

31. Navigation labels should be unambiguous. They should be descriptive of what the link they lead to contains.

32. Navigation labels should be harmonious. E.g. Labels should not be My tasks and Your notifications. They should be either Your tasks and Your notifications, My tasks and My notifications of Tasks and notifications. 

33. Clarity is key but try and do that limiting them to three words. 

Links

34. Use HTML links instead of Javascript links. 

35. Links should look like links. Usually underlined text signifies it as a link. 

Link labels

36. Assuming (as you absolutely should) you follow the previous guideline, then do not label or include in the link ‘Click here’. E.g.- Instead of saying ‘Click here to register‘, simply say ‘Register’. 

37. URL’s should generally not be used as link labels. Use a description of the page it leads to as a link label instead. 

Link actions

38. In general, links should open in the same window, unless it is more useful for the user to see the link in a new window. 

39. Links that open different file formats should be differentiated from navigation links. E.g.- a link to the print version of a policy document in PDF format should have a PDF icon as part of the link to indicate so. 

40. Links to documents should also Indicate their file size (a rounded figure should be fine in most cases).

Tabs

41. Don’t use tabs as elements for page navigation. Use them when showing different views of the same theme of information. E.g. You can use tabs in a be used when it is required to show different views of information or actions within the same context. E.g. – Use tabs to show hourly, daily and weekly data in a weather widget.

42. The active and inactive tabs should be sufficiently differentiated. 

43. There should be no confusion as to which is the active tab and which is the inactive tab, meaning the active tab should look like the active tab and the inactive tab should look like the inactive tab, and not vice versa.  

5. Layout

Grid-based design

44. The application templates should be based upon a grid for desktop, mobile and tablet devices. User interface components and containers should align to the grid as much as possible for the interface to be well structured and consistent in its appearance, which leads to greater interface efficiency. 

Prioritizing information on pages

45. The start of the most important information or tasks should be presented to the user ‘above the fold’, meaning in the visible area of the viewport without the user having to scroll to view them .

Spacing

46. Provide sufficient space between user interface components. This increases the ease by which a user can scan through a page. 

Horizontal scrolling

47. There should be no horizontal scrolling at the minimum resolution or width specified for the website.

6. Forms

Minimum fields

48. Keep the number of fields in a form to the bare minimum. These fields should be the ones required for the primary purpose of the form.  

Completion time

49. For longer forms, it’s recommended to mention the average time it will take to complete it.

50. Mention upfront things the user that the user will need to make a reference to will need to input into the form will most probably not be in the user’s memory. E.g.- attachments like bank statement details, authorization letters, etc or information that needs to be extracted from them. 

Correct usage of input fields

Text boxes

51. Text boxes should be used when the data to be inputted is to be of one short sentence.

52. The length of the text box should be around the average length of the data to be inputted in it. It will need to do this while aligning to a preset size based upon the application grid.

Text areas

53. Text areas should be when the data to be inputted is going to be a long sentence or more. 

54. If there is a text limit that is easy to exceed, use a text limit indicator that lets users know how many characters they are allowed to enter and how many more characters they can enter.

Checkboxes

55. Check boxes should be used when users can select more than one item from a given set of options. 

Radio buttons

56. Radio buttons should be used when users can select only one option from up to four options.

Toggle switch 

57. Toggle switches should be used when users can select one of two available options. They work well in mobile and tablet versions and should definitely be used if the options are ‘on’ and ‘off’.  

Combo boxes

58. Combo boxes should be used when a user can select a single option from more than four items and up to ten items.
If there are more than 10 items and all values must be visible for the user to make the correct choice, list them out in a modal layer with a text box filter. E.g.- Select your favourite deejay from the Top 100.
If the option to be inputted is known to the user, then simply use a textbox with auto suggest. E.g.- Which country did you last visit?

Buttons

59. Buttons should look like buttons. This means they should look clickable. 

Create logical groupings 

60. For forms with more than five fields, chunk form items into logical groupings. E.g. if you have a form with the fields- first name, last name, age, telephone number, email address and viewing preferences, group first name last name and age under personal details, telephone number and email address under contact details and viewing preferences under viewing preference.

Multiple-page forms

61. Use a step indicator for multiple-page forms as described under the ‘Tasks’ section.

62. Before the user can submit the form, present a clear collated review page that shows everything inputted across pages. This allows the user to review and correct any mistakes, just as they would scan a single page form before submitting it. 

Tabbing through fields

63. Users should be able to tab to the next and previous logical field to be filled in forms.

Mandatory and optional fields

64. If there are more mandatory fields than options fields in the form, indicate them with an asterisk (*). Mention this at the beginning of the form. 
If there are much more optional fields than mandatory fields, then consider mentioning at the beginning of the form that all fields need to be filled in unless indicated otherwise. You can then call out optional fields where they occur. 

Error avoidance

65. Perform field-level data validation. The application, when possible, should check the inputted data for errors immediately after the user moves on from that field to the next.

66. Perform form-level data validation. The application should check the form for errors when the user submits the form. 

67. For form-level data validation, provide an error summary at the beginning of the form. 

68. If there are errors in the form and the user has to make corrections, make sure that none of the data users entered is removed. 

69. Captchas, if used, should be easy to read rather than hard. 

70. Don’t submit a form automatically for the user when they complete entering the last required field. The user should be able to choose whether to submit the form or not, and when to submit it.

Errors

71. Error messages should let users know that an error has occurred, why it occurred and how to recover from it.

72. Input fields with errors should be clearly highlighted so it is obvious when and where an error has occurred.

73. Move the focus to the first erring input field in the form to ensure that the erring field is always visible. 

74. It is recommended that input fields with errors use a visual cue to highlight the error besides just colour. This ensures that color-blind users will be able to locate erring fields with ease.

Success

75. A success message confirming successful form validation should be displayed. This message should appear on the same page or a new page.

76. There is no need to end success messages with ‘successfully’. They add no value besides making the tone of voice sound mechanical and less human. E.g.- ‘Your address has been updated.’ is as effective as saying ‘Your address has been updated successfully’.

77. It is recommended to use an icon to indicate successful fixes of erroneous input fields that can be validated before form submission.

7. Error pages

78. Provide easy to understand explanations of the error on pages (404 and other error pages) and what’s the best thing the user can do at this point.

8. Confirmation dialog boxes

79. For confirmation dialog boxes, make the choices easy to follow. E.g.- Are you sure you want to remove this meeting? ‘Yes, remove it’ and ‘No, don’t remove it’ is quicker to comprehend and make a choice than simply Yes and No. Using simply yes and no is not useful for the user. It’s useful for the project to cut costs. How so? It means no one additional translations are needed for confirmation dialog labels besides yes and no. The larger the scale of the project, the more money is saved upfront, but lost later because of usability refinements needed after the application goes live. 

9. Tables

Sorting and filtering

80. Provide the ability to sort data in a table with more than four rows.

81. Provide the ability to filter data in a table with more than seven rows.

Highlighting the hovered row

82. Consider highlighting rows in a table when the mouse hovers over it.

Formatting data in cells

83. Use a thousand separator so it is easier to read large numbers. 

Aligning table data

84. The column header and column content should follow the alignment rules as each other.

85. Numeric data should be right-aligned.

86. However, ID’s and in general, other numbers that don’t have to be added should be left-aligned.

87. Icons should be center-aligned.

10. Help

Instructional text

88. For complex screens that the user might not understand how to use well, provide instructional text- text at the beginning of the page explaining in as short as possible (not more than three sentences) on how to effectively use the screen.

Frequently asked questions (FAQ)

89. Consider including a list of frequently asked questions on the help page or in the help site of the application. 

Contextual help

90. Provide contextual help for help for user interface components or containers that the user will benefit from assistance with. E.g.- A question mark icon next to the component or container that displays the help in a tooltip when the user hovers over it on desktop and taps on it in mobile or tablet versions. 

91. The contextual help should provide useful help and not simply from the component or container.

Human help

92. Make it easy for the user to get in touch with a human for assistance. 

93. It is desirable that you state when the user can expect to receive a reply upon initiation of a request for human assistance.

94. Make sure that if the user is asked to contact someone, details to contact that someone are provided. E.g.- Do not have error pages notifying users that an error has occurred asking them to contact the administrator without any link to or details of the administrator.

11. User interface writing

95. Chunk the content into logical groups. Use headings, sub-headings, short paragraphs and lists to make information easy to go through.

96. Allow roughly 75 characters per line for desktop applications, 55 characters per line for tablets and 35 characters for mobile versions.

97. Provide sufficient contrast between text and the background, ideally 4.5:1 for regular text and 3:1 for large text. 

98. Avoid using images as background for untreated text. 

99. Have programming rules for singular and plurals. E.g.- You uploaded a duplicate. You uploaded duplicates. As opposed to you uploaded a duplicate(s). 

100. Don’t underline texts for emphasis as they will end up looking like links. Use italics instead.

Plain language

101. Use words, phrases and concepts that the user is familiar with. Avoid jargon.

Summaries

102. Consider providing a summary for longer content .

Page titles

103. Every page in the application should have a title that is short and effectively descriptive of what the page is about.

104. Try and keep page titles up to 60 characters in length.

Acronyms, abbreviations and initialisms

105. Acronyms, abbreviations and initialisms should be defined when first used on a page.

106. Consider using the abbr or acronym tag when using acronyms, abbreviations and initialisms which will allow users to view the expanded form on hover.

Exclamation marks

107. The usage of exclamation marks should be avoided.

12. Printing

108. Application pages should be formatted for print using stylesheets. or should available be a printer-friendly version if applicable.

109. PDF’s are not a substitute for web pages. Web pages can and should use style sheets to optimize printing the web page. Provide PDF’s when the recommendation above cannot be done, e.g.-  a heavily illustrated book. 

13. Multimedia

Audio and video

110. Provide users with the ability to stop audio and video.

Icons

111. Icons should be visually distinct from each other and obvious in what they signify.

112. Icons across the application should be harmonious (clearly look like they belong to the same family).

14. Search

113. Provide users with the ability to sort and filter search results.

114. Show users what they searched for on the search results page and make it easy for them to edit or refine their search. 

115. In case there are no search results available, offer suggestions to the user that might help them find what they are looking for. 

15. Multilingual applications

116. Account for extra space for text while the application is going to be available in multiple languages. E.g.- Let’s say your application is going to be available in French and Spanish besides English, then keep 30% extra space for text in components and containers to account for the longer equivalent width of it in French and Spanish.

16. Privacy policy

117. The application should provide a privacy policy if it is being used to gather customer information in any way.

17. Newsletter subscriptions

118. When asking users to subscribe to a newsletter, consider mentioning the benefits and how frequently they will receive an email from you.

About the Cone Trees usability guidelines

I first created this exhaustive list of usability guidelines in 2010 and have since then used it to create usability guidelines for many organizations and clients I have consulted with. They have proven to provide great value in many ways such as being:

• used to evaluate the usability of an existing website or web application in checklist form.
• attached to Request for Proposals (RFPs) as usability requirements
• used to implement usability on new websites or web applications
• available to testers to test the usability of an application against. 

Need help?

Here the guidelines are, but how can you get the most out of them? Happy to help. I am available for consultation to train your team on implementing them and creating a governance process to help you implement them. For further details, you can email me at hello@conetrees.com.

Version 1.0