Visibility of System Status

Always tell people what is happening whether it's a loading spinner, a progress bar or a toast message. They go beyond decoration and into providing functional updates when users don't know what's going on. Users assume the worst and start poking into things they probably shouldn't. Silence in the user interface communicates something is broken even when nothing is.

Match Between System and Real World

You are talking and providing for a human. Sure, you may know technical jargon which may feel normal to you, but your users may not be accustomed to this language. Using words, phrases and concepts your users actually recognise from real life will translate better with your user, keep attention and allow easier task execution which develops trust. If your app calls a folder a 'container' because some backend schema said so, you've lost a lot of people already.

User Control and Freedom

People have always clicked on the wrong thing. I know I have. Give them a clear way out (undo, cancel, back) without making them wade through a warning dialogue to get there. Yes, in the name of efficiency you should save users from themselves sometimes, but in the interest of freedom, this also means letting someone change their mind without consequences. Take this away and your users will become cautious, explore less and see less value from your product.

Consistency and Standards

Before you came along, most people are already spending their time on products other than yours. So they arrive with expectations already baked in so follow platform conventions, stick to patterns people are familiar with. Surprising someone with a novel interaction is cool, but it's not bold design and introduces friction. Jakob's Law: if everything else works a certain way, yours should too. Now that doesn't mean you can't innovate. This law is a general rule for things that are scaffolds; navigation, checkout flows, form patterns. Innovation lies in core value proposition and features that differentiate your product.

Error Prevention

A good error message is better than nothing. A design that stops the error happening is better than both. Eliminate error-prone conditions before they bite the user: confirmation steps for destructive actions, greyed-out options that aren't available, inputs that constrain bad values before submission. Don't apologise, do your due diligence in design, engineering and rigorous testing.

Recognition Rather Than Recall

Don't make people remember things. Make the relevant objects, actions and options visible. Users shouldn't have to carry information in their head from one screen to another. If they need it, show it.

Flexibility and Efficiency of Use

Shortcuts are invisible to beginners and essential to experts. The best interfaces are layered: approachable on the surface, powerful underneath. Keyboard shortcuts, saved filters, quick actions. None of these confuse new users, but they save experienced ones hours. Build for the person who'll use your product every day, not just the person using it for the first time. This is how you can also monitor if your designs are clean when new users start adopting these shortcuts.

Aesthetic and Minimalist Design

Every element on a screen competes for attention with every other element. Add something unnecessary and you've made the necessary things harder to find. This has nothing to do with making things pretty but rather it's about making things clear. Every time you add something, you're asking every user to process it.

Help Users Recognise, Diagnose, and Recover from Errors

Similar to point 2, error messages should indicate actual reasons for errors and what the user can do to fix or retry. Throwing up error codes or "unexpected error occurred" signals that you haven't tested the product properly. Suggest a fix, name the error. "Your session expired. Sign in again to continue" is an error message. Doing this correctly signals respect to the user enough to tell them what actually happened and what to do next.

Help and Documentation

The ideal is a product nobody needs to look up. However, the reality is slightly messier. When someone reaches for help, make sure it actually answers the question: searchable, focused on their task, with concrete steps rather than vague guidance. Documentation is the last resort, so when it gets used, it has to work.