Heuristic Evaluation: Understanding the Biggest Usability Challenges
In a heuristic evaluation, usability experts — that’s where we come in — review a site’s interface and compare it against accepted usability principles.
Why heuristic evaluation?
Designers can obtain feedback in the early stage of the design process. Assigning a heuristic can help determine the best corrective measures. It can be done very quickly and without recruiting external users. You can use it together with other usability testing methods.
Jakob Nielsen’s Heuristics
Though many groups have developed usability heuristics, one of the best known is the set developed by Jakob Nielsen in 1995. Our team has conducted a heuristic evaluation — based on these heuristics developed by the founder of the consulting firm Nielsen Norman Group — of the specification section of the W3C site.
Visibility of system status
Heuristic: The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
Because https://www.w3.org/TR/ is not a digital product, it has no associated system status. If the user were requesting an action, we would include recommendations to ensure they know what’s going on.
Match between system and the real world
Heuristic: The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
Status of Draft: After accessing any of the dozens of specification topic areas, the user is directed to a table with a list of completed work. This list cannot be reordered (sorted, filtered or searched) and uses language to describe the status that is unclear on first glance. As a user, I need to know what I’m looking for (and likely use the Ctrl+F function) to find a specification. This organizational schema is system specific and not designed for the user.
User control and freedom
Heuristic: Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
Browsing between specifications: There is no indication of how the different version of specifications differ from one another. They all look the same even if the content is different. There is no proper introduction. It is deceiving to the user, especially if they’re using the specifications for the first time.
Browsing between drafts of same specifications: The user may find it difficult to navigate between specifications, especially different drafts under the same specification.
Consistency and standards
Heuristic: Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
Link Behavior: When the user clicks on links within the document, some links open in a new tab while some open in the same browser window. This creates a situation where the user is not oriented to the action before it happens.
Contact Information: The names under the editor section in each document are links. Some of these links open web sites, others open a new email addressed to that recipient and it is unclear which is which.
Error prevention
Heuristic: Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
Outdated Versions: When the user clicks on the “previous version” link of any specification, it redirects the user to a different page as well as shows an error message that says “This version is outdated!” The user can get confused because they don’t know if the current page is outdated or the page before.
Recognition rather than recall
Heuristic: Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
Consistency of Contents: In some specifications, the table of contents is on the left and others have the contents within the text. When the user clicks on a topics within the specification, they’re taken to that section of the specification. But there is no sense of place as the table of contents is not consistently there with the user. It results in increased motor load as the user has to scroll to get back to the table.
Availability of Contents: In some left side table of contents, all the topics are shown on the documents, while in some, only the boilerplate, abstract and status of the document is mentioned. The user has to click on the other topics to see that section. The experience is not consistent.
Search: Most of the document has a lot of text and, at times, the user needs to reach one section of the specification really fast. But there is no intuitive search option. This again leads to longer scrolling and excessive motor and mental load as they have to skim through a lot of content to get to where the they want.
Flexibility and efficiency of use
Heuristic: Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
Lack of Tools for Superusers: Sometimes, expert users want to search for some specific information within the document. Unfortunately, there are no quick tools to assist them in their search.
Lack of Between or On-Specification Search: When the user wants to search for a certain specification for reference or search within a specification, it results in motor and mental load as they search and scroll to get to the desired information.
Lack of Tools for Code Snippets: While users agree that code snippets are incredibly helpful, there is no consistent tool for easy use of the snippet.
View Selector: The other pages of the W3C site have the option to view the site on different devices (website/tablet/mobile). But when you go to the specification, this option is not available.
Aesthetic and minimalist design
Heuristic: Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
Boilerplate: The current design of the boilerplate is using up a lot of real estate. Also, the content is not consistent across specifications and some of the content feels redundant.
Link Styling: There are lot of links in each specification. Often, these links will include the whole text instead of a hyperlink, which is not aesthetically pleasing.
Print Layout: Some users might want to print a specification. But there is no print version of the specifications available.
Notes / Code Snippets / Tables: Users prefer to scan. It is usually better to present them with small, visually differentiated chunks of information. The user might find it difficult to read the whole document or go through the table of contents as there is lot of information without any breathing space. Additionally, the code snippets do not provide an improvement to the aesthetic design or achieve minimalism.
Help users recognize, diagnose, and recover from errors
Heuristic: Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
Specification Status: When the user clicks on the “previous version” link of any specification, it redirects the user to a different page as well as shows an error message that says “This version is outdated!” The user can get confused because they don’t know if the current page is outdated or the page before.
Help and documentation
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.
Status of Draft: For a first time user, it’s difficult to understand terminologies like “nightly draft,” “recommendation,” etc. Also, within the specifications, the non-intuitive search makes it harder to navigate in the document. It would be helpful if there was a guide to how to use the specification.
As we move into design in the coming weeks, these are just a few of the problems we will address. Noticed anything else? Be sure to write a comment below or get in touch.
