UI/UX Design Principles for Software Products

Good interface design is largely invisible. Nobody finishes a task and remarks on how well the spacing was calibrated — they simply finish the task. Bad design is highly visible: the button that was not obviously a button, the form that discarded ten minutes of input, the error message that said something went wrong without saying what. The distance between the two is rarely artistic talent. It is a set of principles that can be learned, checked and argued about with evidence.

This guide covers those principles: how attention works, how to structure information, why feedback matters more than aesthetics, how to design forms and error states properly, and how to make interfaces usable by everyone. It is written for engineers and product people who make interface decisions without a designer in the room, which is most of them.

• The small number of principles that account for most usability outcomes
• How visual hierarchy actually works, and how to build one deliberately
• Layout, spacing and typography as systems rather than judgement calls
• Forms, errors and empty states — where most products lose people
• Accessibility as a design activity, not a compliance checkbox
• How to test a design cheaply and act on what you learn

1. What design is actually for
2. The principles that carry the weight
3. Visual hierarchy
4. Layout and spacing
5. Typography
6. Colour
7. Feedback and system status
8. Forms
9. Errors and edge states
10. Navigation and information architecture
11. Motion
12. Accessibility
13. Design systems
14. Testing a design
15. Twelve mistakes
16. A worked example: redesigning one screen
17. Frequently asked questions

1. What design is actually for

Interface design has one job: help someone accomplish something with the least friction and confusion. Everything else — brand expression, visual delight, novelty — is secondary and occasionally in conflict with it.

That framing resolves most arguments. A design is better if more people complete the task, complete it faster, make fewer mistakes, and need less help. Those are measurable. "It looks more modern" is not, and when it competes with the measurable properties it should lose.

Three ideas underpin nearly everything below:

• People do not read; they scan. They look for something resembling what they want and click it. Design for scanning, not for reading.
• People bring expectations from elsewhere. Conventions exist because they are learned. Violating one costs the user attention they would rather spend on the task.
• Attention is finite and expensive. Every decision you ask someone to make consumes it. The best interfaces ask for as few as possible.

2. The principles that carry the weight

These are not aesthetic preferences. Each describes a mechanism by which people succeed or fail at tasks, and each can be checked by watching someone use the product.

3. Visual hierarchy

Hierarchy is the arrangement that tells the eye what to look at first, second and third. It is the most consequential thing on any screen, because a screen without hierarchy forces the user to construct one themselves.

Five tools create it, in rough order of strength:

• Size. Larger elements are seen first. The most important thing on a screen should be visibly the largest meaningful element.
• Contrast. High contrast draws attention; low contrast recedes. This is why secondary actions should be visually quieter, not merely smaller.
• Position. In left-to-right reading cultures, the top-left is seen first and the bottom-right last. Primary actions belong where the eye ends up after reading.
• Space. Isolation creates emphasis. An element surrounded by space is more prominent than a larger element in a crowd.
• Colour. A single accent colour used sparingly is a powerful signal. Used everywhere, it signals nothing.

The most common hierarchy failure is everything being emphasised. Three equally weighted buttons, six headings at the same size, four colours competing — the result is that the user's eye has nowhere to land, and the screen feels harder than it is. The fix is nearly always subtraction: choose the one thing that matters most and let everything else be quieter.

A useful test: squint at the screen until detail blurs. What remains visible should be exactly what you intended to be most important. If everything blurs into an even grey, there is no hierarchy.

4. Layout and spacing

Spacing is where amateur and professional work diverge most visibly, and it is entirely systematic rather than intuitive.

Use a scale, not arbitrary values. Choose a base unit — commonly four or eight pixels — and use multiples of it for every margin, padding and gap. This produces visual rhythm and removes hundreds of individual decisions. Interfaces that look subtly wrong usually have spacing values chosen one at a time.

Proximity means relationship. Elements close together are perceived as related; elements far apart are not. The most common error is a label that sits equidistant between two fields, so the eye cannot tell which it belongs to. Tighten the space to its own field and loosen the gap to the next group.

Alignment is not optional. Every element should align to something. Misalignment of a few pixels registers as sloppiness even when the viewer cannot say why. A grid makes this automatic rather than a matter of care.

Line length has a comfortable range. Text lines that are too long make the eye lose its place returning to the next line; too short and reading becomes choppy. Roughly sixty to seventy-five characters is the well-established comfortable range, which is why full-width paragraphs on a wide screen are tiring to read.

Whitespace is not wasted space. It is what makes content legible and hierarchy visible. Requests to "use the space better" by adding content usually make the screen worse.

5. Typography

Type carries almost all the information in most software, which makes it worth more attention than it usually gets.

Two families at most. One for the interface and one for anything requiring monospacing. More than that rarely helps and usually looks unresolved.

A type scale, like the spacing scale. Four to six defined sizes covering headings, body text, secondary text and small labels. Sizes chosen individually per component produce an interface that feels inconsistent without an obvious cause.

Weight and colour for emphasis, not size. Making something bold or darker emphasises it without disrupting the size hierarchy you established.

Line height by role. Body text needs generous line spacing to be readable; headings need tighter spacing so they read as single units rather than separate lines.

Body text should not be small. There is a persistent tendency to shrink text for aesthetic density, and it directly costs readability for a substantial share of users. If the design requires small text to fit, the design has too much content.

6. Colour

Colour is the most over-used tool in interface design and the one most likely to create accessibility problems.

A functional palette needs less than people expect: a neutral range for backgrounds, borders and text; one primary colour for actions and emphasis; and semantic colours for success, warning, error and information. That is sufficient for almost any product.

Three rules prevent most problems:

• Never use colour as the only signal. A red border indicating an error is invisible to a meaningful share of users. Pair it with an icon and text.
• Check contrast against the standard thresholds. Body text against its background, and interface elements against theirs. This is measurable and takes seconds, and low-contrast text is one of the most common accessibility failures.
• Use the accent sparingly. If everything is the primary colour, nothing is emphasised, and the user cannot find the action you want them to take.

Dark themes are worth doing properly rather than by inversion. Pure black backgrounds with pure white text produce uncomfortable glare; slightly lifted dark greys with slightly softened text read considerably better. Shadows do not work in dark themes — use lighter surfaces to convey elevation instead.

7. Feedback and system status

The most frequent source of user frustration is not knowing whether something happened. Every action needs a response, and the response should be proportionate.

Optimistic updates are worth the effort for frequent actions. Update the interface immediately, send the request in the background, and revert visibly if it fails. The perceived speed difference is substantial, and the failure case is rare enough that handling it well costs little.

Skeleton placeholders beat spinners for content loading, because they communicate what is coming and reduce the perceived wait. A spinner says "wait"; a skeleton says "your list is arriving".

The failure to avoid at all costs is the silent action — a click that produces no visible response. Users click again, and now you have two submissions.

8. Forms

Forms are where most products lose people, and the rules are well established.

• Ask for less. Every field costs completions. Question each one: do you need it now, or could you ask later, or infer it, or not need it at all?
• One column. Multi-column forms cause people to miss fields and produce an ambiguous reading order.
• Labels above fields, always visible. Placeholder text as a label disappears when typing begins, which means anyone who pauses has lost the question. This is one of the most damaging patterns still in common use.
• Group related fields with visible spacing, so a long form reads as a few short sections.
• Match input to data. The right keyboard on mobile, a date picker for dates, a select for a known set. Fewer keystrokes and fewer invalid entries.
• Validate at the right moment. On leaving a field, not on every keystroke — telling someone their email is invalid after two characters is unhelpful. Revalidate as they correct it.
• Mark optional fields, not required ones, when most are required. Less visual noise.
• Never clear the form on error. The single most reliable way to lose a submission.
• Preserve input across navigation and refresh. Long forms should survive an accidental back button.
• Disable submit only with an explanation. A greyed-out button with no reason given is a dead end.

9. Errors and edge states

Most designs cover the state where everything works and everything is populated. Real products spend a great deal of time in other states, and designing them deliberately is what separates a polished product from a demo.

Empty states are the first thing a new user sees, which makes them an onboarding opportunity rather than a blank space. Explain what belongs here, why it is useful, and provide the action that fills it. A well-designed empty state measurably improves activation.

Loading states should reserve the space the content will occupy, so nothing jumps when it arrives. Layout shift causes mis-clicks and feels broken.

Error states need three things: what went wrong in plain language, what the user can do about it, and a way to recover or get help. Include a reference identifier for anything a support conversation might follow.

Partial failure deserves explicit design. If one section of a page fails, that section should show an error while the rest works, rather than the whole page failing. Silent omission is worse than a visible error, because the user does not know something is missing.

Permission states. When someone cannot do something, say so and explain how to get access — rather than hiding the option, which produces a support conversation asking where the feature went.

10. Navigation and information architecture

Navigation answers three questions continuously: where am I, where can I go, and how do I get back.

Structure by user tasks, not by your internal organisation. A menu mirroring your team structure or database schema forces users to learn your model before finding anything.

Keep it shallow. Three levels of hierarchy is usually enough. Beyond that, people cannot form a mental model and rely on search — which is fine if search is good and disastrous if it is not.

Show current location clearly. An active state in the navigation, and breadcrumbs for anything nested.

Make search excellent if the product is large. Beyond a certain size, search becomes the primary navigation method regardless of what the menu offers. Typo tolerance, sensible ranking and a useful empty result all matter.

Put state in the URL. Filters, tabs, selected items and pagination should be reflected in the address, so views are shareable, bookmarkable and restored by the back button. This is a design decision with a technical implementation, and it is one of the highest-value habits in web product design.

11. Motion

Animation has three legitimate purposes and one illegitimate one.

Legitimate: showing relationships — a panel sliding from the button that opened it makes the connection obvious; directing attention — a subtle highlight on a newly arrived item; and masking latency — a well-judged transition makes a wait feel shorter.

Illegitimate: decoration. Motion that exists to look impressive costs time on every interaction and becomes irritating by the twentieth repetition.

Practical guidance: keep interface transitions short — roughly one-fifth of a second for most, slightly longer for large movements. Use easing that starts quickly and settles, since linear motion feels mechanical. And respect the system preference for reduced motion, because for some users animation causes genuine discomfort rather than mild annoyance.

12. Accessibility

Accessibility is design for the full range of people who will use the product, and in many jurisdictions it is a legal requirement rather than a quality goal. It is also dramatically cheaper to build in than to retrofit.

The issues that account for most real problems:

• Non-semantic controls. A styled element with a click handler cannot be reached by keyboard or announced correctly. Use real buttons and links.
• Missing labels. Every input needs a programmatically associated label. Placeholder text is not a label.
• Insufficient contrast. Measurable, common, and trivially fixable.
• Keyboard traps and lost focus. Opening a dialogue should move focus into it and return focus on close. Focus indicators must be visible — removing them is a common and damaging aesthetic choice.
• Dynamic changes not announced. Content appearing after an action needs to be announced to screen readers, or it does not exist for those users.
• Colour as the only signal. Pair it with text or an icon, always.
• Small touch targets. Interactive elements need enough physical size to hit reliably, particularly for users with motor impairments.

The cheapest useful test is putting the mouse away and completing a core task with the keyboard alone. It takes minutes and finds a large share of real problems. Automated checkers catch perhaps a third of issues, which makes them worth running and insufficient alone.

13. Design systems

A design system is a shared set of components, tokens and rules that make consistency the default rather than an achievement.

The parts that matter: tokens for colour, spacing, type and radius, referenced rather than hardcoded; components covering the common patterns with their states defined; patterns documenting how components combine for recurring situations such as forms and empty states; and guidance explaining when to use which.

The failure modes are consistent. A system built before anyone uses it solves imagined problems. A system with no owner decays as teams add variants. And a system that is difficult to use gets bypassed under deadline pressure — the test is whether following it is genuinely easier than not.

Start small: extract the components you already use repeatedly, define the tokens they depend on, and grow from real needs. Ten well-made components used everywhere are worth more than sixty nobody adopts.

14. Testing a design

Design opinions are cheap and frequently wrong, including expert ones. Testing is how you find out.

Usability testing is the highest-value method and is far cheaper than people assume. Five people attempting a real task, thinking aloud, will surface most significant problems — the same issues repeat almost immediately. Give them a task rather than a tour, and resist explaining; watching someone struggle is the entire point.

Analytics tell you where people abandon, which screens are never visited, and which actions are never taken. They tell you what happens, not why, which is exactly what usability testing supplies.

Session recordings sit between the two, showing rage clicks, repeated attempts and hesitation.

Experiments are appropriate when you have enough traffic and a specific hypothesis. They are poor for discovery, because they tell you which of two options performed better and nothing about the third option you did not think of.

The habit that matters most is watching real people use the product regularly rather than only before a launch. Problems accumulate continuously, and teams become blind to their own product within weeks.

15. Twelve mistakes

1. No clear hierarchy. Everything emphasised, so nothing is.
2. Placeholder text as labels. The question disappears the moment typing begins.
3. Clearing forms on error. The most reliable way to lose a submission.
4. Colour as the only signal. Invisible to a meaningful share of users.
5. Silent actions. No feedback, so people click twice.
6. Arbitrary spacing values. Subtle wrongness with no visible cause.
7. Undesigned empty states. A blank screen at the moment of first impression.
8. Removing focus indicators. Keyboard users cannot see where they are.
9. Deep navigation hierarchies. Nobody forms a mental model.
10. State not in the URL. Nothing shareable, back button broken.
11. Decorative animation on frequent actions. Delightful once, irritating by the twentieth time.
12. Testing only at the end. Findings arrive when changing anything is most expensive.

16. A worked example: redesigning one screen

Consider a settings screen that support has flagged: users cannot find how to change their notification preferences, and a third of those who reach the screen leave without saving.

Start by watching, not sketching. Five short sessions with real users attempting the task reveal three distinct problems. Two people never find the screen because it is nested under a heading using internal terminology. Two more find it, change a setting, and leave — because the save button is at the bottom of a long page and they assumed the change applied immediately. One person changes the wrong setting because two similar toggles sit adjacent with the label spacing equidistant between them.

Each problem maps to a principle. The first is a match-to-the-real-world failure in navigation labelling. The second is a visibility-of-status failure — no feedback that a change is pending. The third is a proximity failure in spacing. None of them are aesthetic, and none would have been found by looking at the design.

The fixes are small. The navigation label changes to the words users actually said. The toggles save immediately with an inline confirmation, removing the save button entirely — which is both less work for the user and eliminates the pending-state problem rather than communicating it. Label spacing is tightened to its own control and loosened between groups, so each label unambiguously belongs to one toggle.

Two further changes come from the same sessions. The empty state for a section with no configured channels previously showed nothing; it now explains what channels are and offers the action to add one. And a section that occasionally failed to load previously blanked the whole page; it now fails in place with an explanation while the rest of the screen works.

The result is measured, not asserted. Task completion and the share of users who change a setting and return within a week both move, and support contacts about notifications fall. Nothing about the screen looks dramatically different in a screenshot, which is characteristic of most genuinely effective interface work.

The pattern generalises. The problems were found by watching, each mapped to an established principle, and the fixes were mostly subtraction and clarification rather than addition. That is what interface improvement usually looks like when it works.

17. Frequently asked questions

How do we design well without a designer?

Adopt a mature component library rather than building from scratch, use a spacing and type scale, check contrast, test with the keyboard, and watch five people attempt a real task before shipping anything significant. That combination gets an engineering team to a genuinely good standard. Bring in design expertise for the hard problems: information architecture, complex workflows, and anything where the right structure is not obvious.

How much usability testing is enough?

Five participants per round finds most significant issues, because the same problems repeat quickly. More valuable than a larger single study is testing repeatedly — a small round every few weeks catches problems as they are introduced, rather than accumulating them until a launch. The sessions do not need to be formal; a colleague from another team attempting the task is far better than nothing.

Should we follow platform conventions or our brand?

Conventions for anything functional — navigation, controls, gestures, system behaviours — because users have learned them elsewhere and violating them costs attention. Brand belongs in the things that do not affect operation: colour, type, imagery, voice, illustration. Products that express brand through unconventional controls trade usability for distinctiveness, which is almost never a good trade.

How do we handle a stakeholder who wants a change we think is wrong?

Convert the disagreement into a question with an answer. Test both versions with five users, or run an experiment if the traffic supports it, or find the analytics that describe the current behaviour. Design arguments settled by seniority produce resentment and frequently the wrong outcome; the same argument settled by watching two users struggle takes an afternoon and ends the discussion.

Is accessibility expensive?

Building it in is cheap — semantic elements, labels, contrast and keyboard support cost almost nothing during development. Retrofitting is expensive, because it touches every component and frequently reveals structural problems. The most common expensive discovery is a custom component that reimplements a native control without its keyboard behaviour, which usually needs replacing rather than patching.

Should we build a design system?

Extract one from what you already use repeatedly, rather than designing one in advance. The trigger is when inconsistency starts costing real time — the same component built three ways, or a colour change requiring edits in forty places. Below that threshold, a shared component library and a documented spacing and type scale deliver most of the benefit for a fraction of the effort.

How do we keep quality as the product grows?

Make the good path the easy path: components that are accessible by default, tokens rather than hardcoded values, and linting for the rules that can be automated. Add a lightweight review for anything user-facing, and keep watching real users regularly. Quality decays through hundreds of small individually reasonable decisions, so the defence has to be continuous rather than periodic.

What is the single highest-value improvement for most products?

Fixing the forms and error states. That is where people abandon, where frustration concentrates, and where the fixes are well understood and cheap — visible labels, one column, no clearing on error, validation at the right moment, and errors that say what to do. Most products have several easy wins sitting there, and nobody has looked because forms are not interesting to design.

Key takeaways

• Design is for task completion. Measurable outcomes beat aesthetic preference when they conflict.
• Hierarchy first. If everything is emphasised, the screen has no hierarchy at all.
• Use systems, not judgement, for spacing, type and colour. Consistency stops being effortful.
• Design the other states. Empty, loading, error and permission states are where products feel unfinished.
• Accessibility is design, not compliance. Semantic elements, labels, contrast and keyboard support.
• Watch five people. The cheapest and most reliable way to find out whether any of it worked.

None of this requires artistic ability. It requires deciding deliberately, applying a small number of principles consistently, and being willing to watch someone struggle with your interface rather than explaining it to them — which is uncomfortable, and is where nearly all the useful information lives.