UX design has no shortage of frameworks, tools, and methodologies - but underneath all of them, a smaller set of principles tends to do most of the work.

These aren't laws in the formal sense, and they don't prescribe specific methods; they describe the conditions that make good design more likely. Here are seven that consistently hold.

Foundations first

The temptation in any design project is to jump to the interesting parts early - the visual decisions, the interaction patterns, the edge cases that feel like puzzles worth solving.

But products built on unexamined foundations tend to accumulate problems downstream, and those problems are more expensive to fix the later they surface. Starting with the basics - who is this for, what do they actually need, what does success look like, and what constraints genuinely apply - is not a tax on the interesting work; it is the condition that makes the interesting work worthwhile.

This principle is less about a specific phase of the process and more about an orientation toward the work. It means resisting the pull toward premature specificity, asking foundational questions even when they feel settled, and being willing to return to them when something later in the project doesn't quite fit.

The products that age well tend to be the ones whose foundations were thought through rather than assumed.

Limit distractions

Feature creep is one of the more reliable ways to damage a product's usability over time.

Each addition feels justified in isolation - there's a user need to meet, a stakeholder to satisfy, a competitor feature to match - and so the interface accumulates complexity in increments too small to feel alarming. The cumulative effect, though, is an experience that asks more of users than it gives back.

The discipline of limiting distractions is partly about what gets built and partly about how what's built is presented. An interface can offer significant capability without overwhelming the user if it surfaces what's most needed at each stage and leaves the rest accessible but not prominent.

The question to ask at every design decision isn't "could this be useful?" but "is this necessary here?" - and the latter is considerably harder to answer honestly.

Follow the laws

The laws of UX - Hick's law, Fitts's law, Miller's law, the law of proximity, the serial position effect, and others - are not arbitrary rules; they are descriptions of how human attention, memory, and decision-making actually work.

Designing in ignorance of them doesn't make the effects disappear; it just means encountering them as problems rather than anticipating them as constraints.

Understanding these laws gives designers a language for explaining decisions that might otherwise be difficult to justify. It also gives teams a shared reference point for discussions that might otherwise become matters of preference.

If a navigation structure is too complex, Hick's law explains why and in what direction to address it; if elements aren't being perceived as related, the law of proximity explains both the problem and the solution. The laws don't eliminate the need for judgment, but they give judgment something to work with.

Provide context

Users don't experience products in a vacuum.

They arrive with a specific goal, a level of familiarity, a set of expectations formed by every other product they've used, and a limited amount of patience for working out where things are. Design that ignores this context - that treats every screen as if users will read it carefully and every feature as if it will be discovered eventually - tends to produce experiences that are technically complete but practically difficult to use.

Providing context means designing for the user's state at each moment in the experience: what they know, what they're trying to do, and what they're uncertain about.

It means writing copy that speaks to the user's goal rather than the product's logic, placing help content where confusion is most likely rather than in a separate help centre, and making the current position within a product legible at all times. Context is what closes the gap between what a product can do and what a user actually manages to do with it.

Know your user

It sounds obvious, and that's part of what makes it easy to skip.

Design work often begins with assumptions about users that feel well-founded - based on prior experience, on similar products, on a confident sense of who the product is for - and those assumptions are then built into the product without being tested. When the product meets real users, the gaps become visible, and they're often harder to close than they would have been to address earlier.

Knowing the user means doing the work: research, observation, testing, listening. It means treating user knowledge as something to be maintained rather than established once, because users' contexts, expectations, and behaviours change over time.

The products that remain useful tend to be the ones whose teams stayed curious about the people using them, rather than concluding too early that they already understood.

Speak plainly

Jargon in an interface is almost always a cost to the user.

It signals that the product was designed from the inside out - from the logic of the system or the language of the organisation - rather than from the user's perspective. Users encountering unfamiliar terminology have to either stop and work out what it means, guess and risk getting it wrong, or abandon the task.

None of those outcomes is preferable to writing that didn't require them.

The exception is genuine specialist contexts: medical platforms designed for clinical professionals, developer tools, or products serving communities with shared technical vocabularies where the jargon is actually the clearest available shorthand.

But even in those contexts, the principle holds at the level of structure and interaction copy, even if domain terminology is appropriate in content. Plain language is not a sign of a simple product; it is a sign of a product that respects the user's time.

Be consistent

Consistency matters at two levels, and both repay attention.

Within a single product, inconsistency - in the way similar elements behave, in the vocabulary used for the same concepts in different places, in the visual patterns applied to equivalent components - creates cognitive friction. Users build a mental model of how the product works, and inconsistency breaks that model, requiring them to relearn rather than apply what they already know.

Across a brand or product family, the relationship between consistency and variation is more nuanced. Some deliberate variation can serve a purpose: distinguishing between product lines, signalling a different mode or context, or evolving a design system over time without breaking backward compatibility.

But the foundations - the core visual language, the interaction patterns, the voice and tone - should remain legible as belonging to the same thing, because that continuity is what lets users carry their knowledge and trust from one touchpoint to the next.