5 Web Accessibility & Design Best Practices Using Heuristic Principles

Hub & Spoke

In case you are unfamiliar with the Heuristic Principles and Heuristic Evaluations, they are a useful evaluative tool in any designers’ toolbelt. Originally developed by Jakob Nielson to provide designer’s with broad usability guidelines, you can find more information about conducting heuristic evaluations here. Whether you are conducting evaluations or not, it is essential that designers are familiar with the principles when making design decisions for user interfaces. 


While understanding the individual heuristic principles is easy enough, it can take time to understand the best ways to apply the principles to your designs. Here are five examples of methods to increase the usability of a highly technical website/service based on five of the ten heuristic principles. 


#1 Visibility of system status

This is essentially the heuristic of communication. As a designer or developer, ask yourself “How does the user know where they are in a process? Do they know what comes next? How do they exit and return?”  If the answer to any of these questions is unclear, then it is your job to add clarity for the user through your design. 

Group 25 (3).png

The Example: A popup that originally did not include easily recognizable ways to exit the screen prior to task completion.


If you are a developer, remember that users may not see the same thing you do with errors, so they need additional instructions on what the error is and how to resolve it.


#2 Match between system and the real world 

This heuristic is all about creating systems that match the existing mental models of the users; your system should match a user’s mental model as much as possible. The reason you should look to match the “real world” in your systems as much as possible is that the physical world is where many mental models are developed. 

If you are unfamiliar with the term “mental model,” it’s a user experience concept about people’s pre-existing ideas about the organization of the physical and digital worlds. 


Network Icon 1   Network Icon 2

The example: A common example of this in design is iconography. When possible, icons should match a physical item associated with an action/adjective, such as a flame signaling heat. Icons that are based on less physical concepts are much harder for users to interpret without prior exposure. Often such icons are still rooted in physical imagery, such as the two common icons for networks (see image), which are based on hubs and spokes. 


#3 Flexibility and efficiency of use 

This is all about making tasks quicker and more efficient to do repeatedly. Frequent users are going to want the ability to take less time completing an action; it doesn’t matter whether that action is transferring money on an app or blocking internet security threats, people desire shortcuts for well-known tasks. 


I recently had a dialog about the differences between internal and external software (and the focus of designers when creating and updating these tools), and we discussed how, in general, efficiency of use can be especially important for internal tools that are built for constant, daily use by workers. This is one of the reasons why internal tools tend to be less visually appealing, visual appeal is not as important to the users as function. Of course, this is not a hard and fast rule for internal vs. external tools, but it is worth considering this heuristic of extremely elevated importance in any system that qualifies as both internal and built for daily use.


Hot keys are one of the most common ways to create shortcuts in digital applications, as advanced users can press a key, or a combination of keys, instead of going to a menu and selecting a tool. 


#4 Consistency and standards 

This heuristic is very straightforward; follow and maintain your design library and have your designs match industry standards. Ideally, your developers have tested the code for each element in your design library. 


Users don’t want to spend extra time figuring out how to accomplish tasks or find information on your website or product. As a user once told me, “I just want it to work.” Frustration inevitably arises when the product design doesn’t match that expectation. 


In other words, this is essentially Jakob’s Law; “Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.” Aka, if it’s the standard practice on most websites, it should be standard practice on yours. 


This also means that even if you see some really cool new-fangled design element, you should think twice (and test with users) on whether the new design element is actually more usable. Sometimes software giants like Google and Meta will try something new on platforms that billions of people use; what works for software with large pools of existing users doesn’t always work for smaller, newer programs, as people don’t want to invest the time to learn or change their mental models. 


The example: This can be seen in one feature in a recent update to Gmail’s UI. The new interaction with the hamburger menu in the upper left corner of the page felt awkward for many users as they have been conditioned over time to expect the menu expansion to be inline with the hamburger menu icon (either vertically or horizontally). People are getting used to it because it’s a feature in an application they already heavily rely upon, and it would take far more effort to change email providers, but it’s definitely less than ideal, and likely wouldn’t work in a new/unknown application. 


#5 Recognition rather than recall 

In short, don’t make people remember stuff. They seriously don’t want to, and will resent the mental exercise. Users will inevitably remember incorrectly or get annoyed trying to find information that could easily be presented on the interface. 


Such is the truth behind navigation; always show users “breadcrumbs” or a way to see where they are in the systems information architecture. Make sure that the navigation items are where people expect them to be. There can be multiple ways to find the right navigation. 


If you have a particularly complex information architecture, there are a couple potential ways to test if the navigation matches the user's expectations, such as navigation tree tests, to answer the question of “where in the information architecture would a user expect to complete this action?” You can find information on how to conduct a tree test here.


It’s definitely useful to know these heuristics well; in many ways they seem like common sense for designers, but they can also act as a checklist for an initial evaluation of the usability of your design. If you are struggling with usability in your product, Key Lime Interactive can assist by running usability tests and design recommendations using these heuristics (among other usability standards) to improve the usability of your website, SaaS service, or app. We have 13+ years of experience helping our clients build irresistible user experiences, and we would be happy to lend our expertise - just contact us.


Works Cited

More by this Author
Natalie Schade

Nat is an award winning designer with a passion for helping people bring their projects to life by designing digital tools and interfaces that make remote collaboration feel natural. She also works hard to add moments of delight to all of her designs. Originally from the suburbs of Philadelphia, Nat obtained her BFA from the Savannah College of Art and Design in Industrial Design. Nat also holds a Masters degree from Carnegie Mellon University in Human-Computer Interaction. Before joining Key Lime Interactive, Nat worked as a user experience designer at Johnson & Johnson, with a focus on enhancing remote and hybrid work collaboration for internal teams. In her free time, you can find Nat scuba diving, skiing or ice skating. Luckily, Nat maintains an abiding love for sci-fi and fantasy which influences her work by presenting unexpected perspectives on technology and its cultural/legal potential.


Add Comment