Design Heuristics

Design heuristics are broad rules of thumb that guide design decisions. They provide a framework for evaluating and improving the usability of a product or service. Think of them as the missing manual, for humans and AI agents.

Here are some heuristics we think are useful for designing in i.AI:

Accessibility: All of our products should meet WCAG 2.2 level AA. This is the government standard for internal as well as external products, and it's one of the things that makes us stand out from commercial alternatives to our products.

Aesthetic: Our interfaces should be surprisingly simple, but very easy to use. Minimal, functional, legible, uncluttered, calm, clear. Avoid unnecessary decoration. Use whitespace to create a sense of balance and clarity.

Colour: Use the colour palettes defined in the i.AI Design Kit. Use colour intentionally rather than purely for decoration, but don't rely on it to convey meaning because many people are colourblind.

Content: Content should be free of jargon and written for a reading age of about 9 years. Write in short, unambiguous, declarative sentences. Try to fix usability issues with good content before you resort to more complex interfaces.

Context: Consider your product's context of use. Are people using your product regularly or only occasionally? Are they familiar with the tasks they are performing or not? What's more important to them - accuracy or speed?

Decoration: Avoid unnecessary decoration. Our interface elements should rarely use drop shadows, gradients or rounded corners. Images and illustrations should always convey relevant meaning.

Delight: Our products delight their users by being surprisingly useful, reliable, accessible and easy to use. We do not need to delight users with unnecessary widgets, animations or other gimmicks.

Friction: Not all friction is bad. You might need to introduce friction at various points in your product's user journeys, to slow users down and help them make good decisions.

Icons: Avoid icons unless they are essential in making the interface more usable. Try to use words instead. Only use the most widely recognised icons, like save, download, print, share.

Information: Create a very clear information hierarchy. Use whitespace to denote different regions. Use borders sparingly and intentionally. Ensure layouts linearise well on smaller screens.

Innovation: Our products are innovative in terms of how they are built, the technologies they use and what they do, rather than in how they appear. Don't be afraid to provide a simple and basic interface if that is all that is needed.

JavaScript: Use JavaScript sparingly. Try to make your product usable even when JavaScript isn't available. This makes for more robust, maintainable products that work on old devices and poor connections.

Layout: Start with the standard width page layout and header as defined in the Design Kit. Only make the page wider if the content requires it, for example in a mapping interface, or for side-by-side document comparison.

Minimalism: Every element on a page competes with every other one for attention. Therefore, every element should be there for a reason. Consider whether each element is necessary. What would happen if we removed it?

Readability: Surround content with ample white space. Line lengths should not exceed about 12 words on average. Long lines are harder to read, especially for people with dyslexia.

Spacing: White space can make all the difference between a janky interface and one that feels just right. Use the spacing scale in the Design Kit, and use your judgement to override the default spacing of components if you have to.

Sticky: Careful use of sticky positioning can help to keep an interface usable, by ensuring that important controls are available even if the user has scrolled down the page. But test at smaller window sizes to ensure content is not obscured.

Tone: Content should be informative, clear and concise. Avoid jargon, jokes or bad language. Use the active voice rather than the passive voice. Write conversationally, but with the authority of someone who can actively help.

Trade-offs: Optimising a design for one use case or user group is often at the expense of another. Try to ground your decisions in data about the relative size and importance of those use cases and user groups.

Unavailable actions: Avoid showing controls that people can't use. Disabled buttons and links are hard to see, often can't be reached by keyboard or screenreader users, and don't explain what's wrong. If an action isn't available yet, hide it. Tell the user what they need to do to make it available, for example "Upload a file to start analysis."