UI Design Best Practices for Effective Interfaces

The best practices for UI design are not about making screens pretty. An effective interface makes four things obvious at a glance: what matters most right now, what state the product is in, what the user can do next and what will happen when they do it. Hierarchy, contrast, typography, spacing and components are the tools for showing those four things. They are not a replacement for them. When the logic underneath is missing, no amount of polish will put it back.

At ANODA, we fix product interfaces from the task outward, and the plot never changes. A team spends a quarter on a redesign: new colours, new icons, a fashionable font. The launch post is gorgeous. Three weeks later the support queue looks exactly the same, because users still cannot tell whether their invoice was sent or what “Process” does. You cannot make a silk purse out of a sow’s ear, and you cannot make a broken flow effective by giving it a nicer button.

Meanwhile the money keeps leaking. Every user who signs up, gets lost on the second screen and leaves is a user you paid to acquire: ads, sales calls and onboarding emails spent to deliver a person to an interface that does not tell them what to do. AI has not changed the plot either. It now takes an afternoon to generate forty polished screens, every one of them missing the same empty state. Here is how to design user interfaces that stop the leak instead.

What effective UI actually has to show

User interface design best practices get sold as commandments: be consistent, be simple, use white space. All true, and useless without the reason. Every screen exists to answer four questions for the person looking at it.

• Priority. What on this screen matters most to me right now?
• State. Where is my work: draft, pending, failed, done, locked, waiting on someone else?
• Action. What can I do next, and which of those actions is the main one?
• Consequence. What will happen when I press this, and can I take it back?

An interface that answers all four is effective, even if it is plain. An interface that answers none of them is decoration, however many design awards it collects.

Picture a freshly tiled bathroom: Italian stone, designer taps, a gorgeous rain shower. The drain is on the wrong side of the floor, so every shower ends with a puddle by the door. Nobody praises the tiles after the second puddle. That is what a visual redesign on top of missing product logic looks like: expensive surfaces, and the water still goes the wrong way.

So the first UI design principle is uncomfortable for anyone selling visual polish, agencies included: check the floor plan before you touch the surface. And empty, loading, error, permission and success states are part of that plan, not garnish. A screen designed only for the happy moment is not designed. It is a photo of the one day nothing went wrong.

Is it a UI problem, a flow problem or an engineering problem?

Most teams that ask us for “a UI refresh” do not have a UI problem, or not only one. They have a symptom and have picked the cheapest-sounding cure.

A limp can come from a stone in the shoe, a bad knee or a problem in the spine. A new pair of trainers fixes the first, does nothing for the second and makes the third worse, because now the patient walks further before anyone looks at the X-ray. Interfaces are the same. The symptom tells you where it hurts, not which layer is broken.

Here is the first pass we run before anyone opens a design file:

Each layer has a different owner and a different price tag. A UI fix is days of design and front-end work. A flow fix means research and new logic. An engineering fix may not need a designer at all. Send the wrong team and you pay twice for the same screw-up, while acquisition spend keeps pouring users into the same hole.

The review that replaces taste: goal, state, action, response, recovery

“I don’t like it” is not a review. Reviews driven by taste end with the most senior person in the room winning, and the user is never in the room.

Look at an airport departure board instead. Nobody calls it beautiful, and it works. It knows your goal (catch a flight). It shows the state (on time, boarding, delayed, cancelled). It tells you the action (go to gate B12). It responds when things change (the row flips to “Gate closed”). And when the flight is cancelled, it points to recovery (“See agent at desk 4”). Five jobs, no gradients.

That is the framework we review every screen against, and each question can be checked rather than argued about:

• User goal. Can a first-time user say, within five seconds, what this screen is for and what they came to do?
• Current state. Does the screen show where the user’s work stands — and does it look different when the state is different?
• Available action. Is the main action the most visible thing, and are unavailable actions explained instead of silently missing?
• System response. After every action, does the interface show that something happened, what happened and where the result went?
• Recovery path. When something goes wrong — wrong input, no permission, failed request, changed mind — is there a visible way back?

Run them on one screen and “make the button pop” becomes “the reminder was sent, but nothing on the screen says so”. That is a defect with an owner, not an opinion with a job title.

Visual hierarchy: make priority impossible to miss

Visual hierarchy is the order in which the eye reads a screen. Size, weight, contrast, position and space decide what gets noticed first, second and never. When everything is equally loud, nothing is.

Imagine a weather forecast where “light drizzle” and “hurricane warning” use the same small grey icon in the same row. Technically all the information is there. Practically, someone is going to leave their windows open. Interfaces do this constantly: the overdue total sits in the same tile as “Invoices this year”, and the one number that needs a decision is lost among six that need nothing.

The fix is not “make it bigger”. It is deciding what matters, then spending visual weight like money:

• One primary action per view. One filled button. Everything else is secondary or a link. Two primary buttons means the team did not decide, and the user now has to.
• Size and weight for priority, not for decoration. The number that drives a decision gets the headline treatment. Totals nobody acts on get small type.
• Contrast for importance. Muted text for supporting detail, full contrast for what the user must read. Never mute something the user needs to act on.
• Space to group. Items that belong together sit closer to each other than to anything else. Spacing does the job borders usually do badly.

A test we use in every audit: blur the screenshot and see what survives. If the blur leaves a logo and a webinar banner, your hierarchy is advertising, not helping. Typography does most of the lifting and does not need to be clever: two typefaces at most, a few sizes with clear steps, real headings instead of bold paragraphs.

Navigation and information architecture: signposts for the task

Information architecture decides where things live and what they are called; navigation is the signage. Both fail the same way: they mirror the org chart instead of the user’s task.

Walk into a hospital with a bleeding hand and the signs say “Whitfield Wing”, “Harcourt Building” and “Level 2 East”. Every sign is accurate. None tells you where A&E is. Now look at a typical sidebar: “Ledger Core”, “AR Hub”, “Docs Engine”. These are the names of the teams that built each area. The user wanted to send an invoice.

Good navigation answers three questions on every screen: where am I, where can I go, how do I get back. In practice:

• Label by task or object, in the user’s words. “Invoices”, “Expenses”, “Clients”, “Reports”. If you need a glossary for your menu, the menu is wrong.
• Show the current location. Highlight the active section, match the page title to the menu label, add breadcrumbs for deep hierarchies.
• Keep the top level short. A sidebar with 19 items is not navigation; it is a sitemap. Group, and move rare destinations into settings or search.
• Put the next step where the task ends. After “Invoice sent”, the user wants to see it in the list or send another, not hunt for the section again.

If you do not know how users group the things in your product, card sorting and tree testing will tell you faster than another workshop. And if the navigation must change because the product’s jobs changed, that is a flow problem in a UI costume, and it needs discovery, not a new icon set.

Labels, content and affordances: say what happens, look like what it is

Words are interface. Many UI problems we find in audits are not layout problems at all: labels that describe nothing, confirmations that explain nothing, controls that do not look like controls.

Think of a spice rack where every jar carries the same handwritten label: “Spice”. You can cook with it. You will just find out which jar was chilli the hard way. A product full of “Submit”, “OK”, “Process” and “Continue” buttons is that rack, and the dish that comes out is usually crap. The user cannot predict what happens, so they guess, and guessing on a screen that emails customers is how support tickets are born.

The rules for UI content are short and routinely ignored:

• Buttons say what they do: verb plus object. “Send invoice”, “Save draft”, “Delete client”. The label on the button should match the result the user sees afterwards.
• Confirmations name the consequence, not the feeling. “Are you sure?” asks the user to be confident. “Delete INV-0142? The client’s payment link will stop working” asks them to decide, and gives them what they need to do it.
• The safe option is not the one you are trying to get rid of. In a destructive dialog, the button that keeps the data reads “Keep invoice”, not “Cancel”, which could mean either.
• Use the user’s vocabulary. “Remittance advice” is correct in accounting and baffling to a two-person design studio sending its third invoice.

Affordance is the other half: whether something looks like what it is. Everybody has met the door with a big handle that you have to push. Interfaces build those doors all day. Links look like plain text. Status chips look like buttons and do nothing. Row actions appear only on hover, so on a touch screen they do not exist, and on desktop they are out of sight, out of mind.

Chekhov had a rule for playwrights: if a gun hangs on the wall in the first act, it must go off by the third. Interfaces need the reverse rule too. If something looks like a button, it must do something. If it does something, it must look like it.

Consistency and design systems: same problem, same answer

Consistency is not everything looking the same. It is the same problem getting the same answer, so users learn a behaviour once.

A stop sign looks the same in almost every country. Nobody reads it; drivers stop, because they learned the shape once and it never lies. Now picture a city where every district designs its own stop sign. That is a product where “Delete” asks for confirmation in one module, deletes instantly in another and quietly archives in a third. Each team made a reasonable choice. Together they made a mess nobody can predict, and the damage is death by a thousand cuts: a hesitation here, a wrong click there. Unifying modules like that was the core of our Superstream work.

But consistency is not a religion. Fire engines are not painted like buses, because they must stand out. An irreversible action or a security warning should break the pattern deliberately, so the user notices. Deliberate variation has a reason written next to it. Accidental variation is drift.

That is the job of a design system: not a library of pretty buttons, but shared decisions that keep the product predictable as it grows:

• Foundations (tokens): colour, type scale, spacing, radius, elevation, motion timing. One source, used by design and code.
• Components: buttons, inputs, tables, dialogs, toasts — each with every state designed: default, hover, focus, active, disabled, loading, error.
• Patterns: recurring situations — destructive actions, empty lists, bulk edits, form errors.
• Rules and governance: when to use what, who can add a component and how exceptions get approved.

The money case is blunt. Without shared components every team rebuilds the same date picker and table, with its own bugs, and you pay for each version in design, engineering, QA and support. With them, one fix ships everywhere. We go deeper into how components, patterns and rules fit together in our guide to design system components, and into the principles behind them in UI/UX design principles for better digital products.

States are the interface: loading, empty, error, permission, success

Most design files show one moment: a full account, every permission, a fast network. Real products spend most of their life in other states, and that is where users decide whether to stay.

A washing machine with no display is a box that hums. Washing? Finished? Stuck? You open the door to check and get a wet floor. A screen without designed states is that machine: the user presses a button, it hums, and they guess.

Here is the minimum set of states we design for every screen that shows data or accepts an action:

• Loading. A skeleton of the layout, not a spinner on a white page.
• Empty, first use. The most expensive screen in your product. “No invoices” and nothing else is a blank page handed to someone who is paying you. Say what will appear here and offer the first step.
• Empty, no results. The user has data but the filter found nothing. Say which filter and offer to clear it.
• Error. What failed, whether the data is safe, what to do next. Never lose input.
• Permission. Explain why the user cannot act and who can, instead of hiding the button.
• Partial and stale. Say what loaded, what did not and when.
• Success. What happened, where the result went, the natural next step.
• Role-specific. An admin, an accountant and a viewer see the same screen differently. Design each version, not just the admin’s.

Each state costs little to design and a lot to leave out. The empty state alone decides whether a paid-for sign-up becomes an active user or a line in next month’s churn report. A permission state without a name becomes a support ticket, paid for with a person’s time.

Feedback, waiting and performance: every action gets an answer

Every action deserves a response the user can see. Without one, people press again, and your support team gets to explain the two invoices that went out.

A forecast that says “weather is coming” is never wrong and completely worthless. A spinner is that forecast: something is happening, no idea what or for how long. Users can live with waiting. They cannot live with not knowing.

Response-time thresholds are old enough to vote. Jakob Nielsen described them in 1993, and Nielsen Norman Group still publishes them: about 0.1 seconds feels instant, about 1 second keeps the train of thought intact, and about 10 seconds is the limit of attention before people need progress feedback. The web has since added its own yardstick. As of 2026, Google’s web.dev guidance treats Interaction to Next Paint (INP) of 200 milliseconds or less, measured at the 75th percentile, as good responsiveness; INP replaced First Input Delay as a Core Web Vital on 12 March 2024.

So the design rules follow the clock:

• Instant feedback on every press. The button changes state immediately, even if the work takes longer.
• Progress for anything over a second or two, with real numbers when you have them (“1,240 of 3,000”), not a bar that loops forever.
• Background jobs for long work. Let the user leave and tell them when it is done.
• Confirmation with a time and a place. “Saved at 14:32” beats a toast that says “Success!” and vanishes before anyone can read it.

Perceived performance is partly a design decision: skeletons and instant button states make the same product feel faster. But design cannot hide a slow back end. A list that takes six seconds to load belongs in the engineering backlog, not in a prettier loading animation.

Forms and mistakes: prevent, explain, keep the input

Forms are where products take something from the user: data, money, time. They are also where most avoidable mistakes happen, and most products respond like a bad examiner.

Imagine getting your exam back with “FAIL” stamped across the top and no marks next to any question. Now sit it again from memory, because the paper has been shredded. That is a form that shows “There were errors with your submission” at the top, highlights nothing and clears half the fields.

Error handling in forms comes in three layers, in this order:

• Prevent. Ask only for what you need now. Use sensible defaults, formats shown before typing (“GB followed by 9 digits”) and choices instead of free text where options are known. Do not ask for the same thing twice: WCAG 2.2 (success criterion 3.3.7, Redundant Entry) expects information already entered in the same process to be filled in or available to select.
• Explain. Validate at the right moment — usually when the user leaves a field, not on every keystroke and not only on submit. Put the message next to the field, say what is wrong and how to fix it, and use the user’s words: “You typed 8 digits; a UK VAT number has 9”.
• Keep. Never clear valid input because another field failed. Save long forms as drafts. After a failed submission, move focus to the first problem and list the issues at the top with links to each field.

For destructive actions, prefer undo over “Are you sure?” wherever the action can be reversed. A confirmation on every action trains users to click “Yes” unread, and then it protects nothing on the day it matters.

The money here is direct. A sign-up form that loses input on error loses the user. A checkout that rejects a valid postcode loses the sale, and with it every ad that brought that buyer in.

Data-heavy interfaces: tables, filters and bulk actions

B2B products live in tables, and most tables are designed as if the user will read every row, when they are looking for three.

A coach reviewing Saturday’s goals should not have to watch all 90 minutes on fast-forward; someone tags the goals and he jumps straight to them. A table with no default sort, no visible filters and fourteen equal columns is untagged match footage. Every answer is in there. Finding it costs an afternoon.

What makes data-heavy UI work:

• Choose columns for the decision, not for completeness. Client, amount, status and due date answer most questions about invoices. Internal IDs and timestamps can live in the detail view.
• A sensible default sort, visibly marked. Overdue first, newest first — whatever serves the most common task — with the sort direction shown in the header.
• Filters as visible chips with a result count. “Status: Unpaid · 5 of 412 invoices” tells the user where they are and how to get back.
• Readable numbers. Right-aligned amounts, consistent decimals, currency stated once.
• Sticky headers for long tables, so users never lose track of what a number means.

Bulk actions are where tables get dangerous. Voiding 48 invoices with one click is powerful and, without a preview, reckless. Show what will change, skip what cannot change and say why, and give the user a way back.

Responsive layouts and platform conventions

Responsive design is not squeezing the desktop layout onto a phone. It is deciding what matters on each screen size.

A recipe for twelve does not become a dinner for one by serving it on a smaller plate. You change the portions, and sometimes the menu. A 12-column table on a 390-pixel screen is dinner for twelve on a saucer: all there, and unreadable. On a phone the invoice list becomes cards with the four facts that matter and one clear action.

Platform conventions matter as much as screen size. Feed a cat dog food and it will eat it, grudgingly, and look at you as if you have lost your mind. iPhone users served Android patterns, or web users served a fake mobile app inside a browser, react the same way. Back gestures, date pickers and share sheets are learned behaviour. Break them and every user relearns something they already knew, for no gain.

Touch changes the physical rules too. Fingers are less precise than cursors, and the platform owners publish numbers for it. As of 2026, Apple’s design tips recommend controls of at least 44 × 44 points, Android’s accessibility guidance recommends touch targets of at least 48 × 48 dp, and WCAG 2.2 (success criterion 2.5.8, level AA) sets a floor of 24 × 24 CSS pixels for pointer targets, with some exceptions for spacing and inline links.

Accessibility is UI quality, not a compliance layer

Accessibility is usually sold as compliance: a checklist run before release by someone who missed the design meetings. By then the problems are baked into every component.

A shop with a step at the door does not only lose wheelchair users. It loses parents with prams, travellers with suitcases and the courier with a trolley. Low contrast, colour-only status and keyboard traps work the same way: they hurt people with disabilities most, and also the user in bright sunlight, the accountant with tired eyes at 11 p.m. and the power user who never touches the mouse.

The core requirements are well documented. WCAG 2.2, the W3C Recommendation (current edition dated 12 December 2024), asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, at least 3:1 for the visual parts of interface components and meaningful graphics, text that can be resized to 200 percent without losing content or function, and — our favourite, because it is broken in almost every product we audit — colour never being the only way information is conveyed.

There is also a harder commercial edge now. The European Accessibility Act has applied since 28 June 2025, and the European Commission lists banking services and e-commerce among the services that must be accessible. If you sell into the EU, inaccessible UI is no longer only lost users. It is legal exposure.

Built in from the start, most of this costs almost nothing. Bolted on at the end, it means touching every screen twice. Our full take on inclusive products is in the guide to accessibility in UX design.

Motion: a signal, not a show

Motion earns its place when it explains a change: where something went, what caused what. Everything else is choreography the user sits through.

Watch a goalkeeper make a full flying dive for a ball rolling straight into his hands. It looks spectacular in the highlights and adds nothing to the save. Interfaces do it with a bounce on every card and confetti after saving a draft. Charming once. Too clever by half on the fortieth time that day.

Rules we apply to motion in product UI:

• Every animation has a job: showing where something came from or went, linking cause and effect, or drawing attention to a change the user would otherwise miss.
• Short and quick to settle. Motion in frequent interactions should be over before the user notices waiting for it.
• Never block input. The user should be able to act while an animation runs.
• Respect reduced motion. Browsers expose the operating system’s reduced-motion setting through the prefers-reduced-motion media query, documented on MDN. Honour it with instant or gentler alternatives.

Motion is also where design intent gets lost first: timing that looked right in a prototype stutters on a mid-range phone. Specify it and check it in the real build.

Handoff and verification: where good UI goes to die

One system across the task

The costly UI problem is often a broken agreement: the list uses one status, the details another, and the confirmation never tells the user what happened. A colour refresh preserves that confusion. ANODA works through the complete task and makes the hierarchy, states and component rules agree before they reach development.

In SEOSpace, we designed the web app and Chrome extension around consistent scores and prioritised SEO tasks, then carried the decisions into Figma handoff, Loom walkthroughs and release design QA. Users get a clear next action across connected surfaces. Explore the SEOSpace redesign and design a coherent interface with ANODA.

A design is finished when the product behaves right, in every state, on real devices, not when the file looks right. Between the two sits handoff, where we see the most expensive losses.

On a building site, handover comes with a snagging list: a walk through every room noting the sticking door and the crooked tile. Nobody moves in until the snags are fixed. Most software is handed over with a picture of the living room and nothing about the fuse box or the fire exit. The engineer fills the gaps with guesses, and many guesses become support tickets.

A handoff that survives implementation includes:

• A state inventory for each screen: loading, empty, no results, error, permission, partial, success, and each role’s version.
• Behaviour, not only pictures: what happens on click, on failure, on slow network, on double submit, on back.
• Content rules: real labels, error messages and edge cases like the 60-character client name and the £1,000,000.00 amount.
• Acceptance criteria the developer and QA can check: “focus moves to the first invalid field”, not “errors are handled nicely”.
• Components from the design system, named the same way in design and code.

Then verify in three passes: design QA on the real build, with the designer walking every state on real devices; accessibility and performance checks on that build, not the prototype; and usability testing with target users on the critical tasks, because the team that built the interface is the least qualified group on earth to judge whether it is obvious. The proof of the pudding is in the eating.

This is also where the split between design and engineering stops being useful. If approved designs keep losing their states and accessibility on the way to production, the problem is the build, and it needs frontend development that treats those details as requirements rather than nice-to-haves.

A UI design checklist you can run this week

Every “no” below is a defect with an owner, not a matter of taste.

Where your problem belongs

Best practices for UI design only help once you know which problem you have. Here is how we route the work:

The screens are fragmented and the flow underneath is unclear. Users drop out and every screen was designed separately. That is interface and flow work together, which is what our UI/UX design team does: logic and visual system fixed at once, so the result is coherent and testable.

The same UI decisions are made again and again across teams or products. Inconsistency is the symptom; the missing shared rules are the cause. A design system with components, patterns and governance is the fix.

The designs are good but the product is not. States, accessibility, responsiveness and interaction quality get lost between the file and production. That is frontend development work.

Nobody knows whether users understand the interface. Then stop debating and watch them. Usability testing on the critical tasks will tell you which screens are the problem before you pay to redesign all of them.

Pick the right one. A full redesign to fix three confusing labels is repainting the building because a sign is misspelled. A new button style on top of a broken flow is new tiles over a drain on the wrong side.

Build from a validated flow. Use a coherent component system. Design every state that has consequences, and test accessibility and behaviour in the real build, in context. Effective UI is not the prettiest screen in the portfolio. It is the one where the user always knows what matters, where their work stands, what to do next and what will happen when they do it — and where every user you paid to acquire actually gets to the point of paying you back.