How to fix my UI when I am not a designer

A UI that feels wrong usually has a few specific faults, and they are rarely the ones the team argues about. Find them first. Ask five people who resemble your users to complete two or three real tasks while you watch in silence. Jakob Nielsen's model of usability testing estimates that five users reveal about 85 percent of the usability problems, and he recommends several small rounds over one large study.

Add two sources you already have. In analytics, find the step where most people abandon a flow. In support tickets, count the questions that begin with where or how. A free recording tool such as Microsoft Clarity flags rage clicks and dead clicks: repeated clicking on one spot, and clicks that produce no response. Both point at elements that look clickable and are not, or the reverse.

1. Write each problem as an observation, for example: three of five people did not find the export button.
2. Rank by how many people hit the problem and how badly it blocked them.
3. Fix the top five. Leave the others on the list for the next round.

Most screens that look cluttered have a hierarchy problem. Everything has the same size, weight and colour, so nothing leads. Squint at the screen, or blur a screenshot. Whatever still stands out is your real hierarchy. It should be the page title, the main content and one primary action.

Before: a settings page with five filled blue buttons, bold labels everywhere and three heading sizes. After: one filled button for Save, the remaining actions as outlined or text buttons, labels in regular weight and one heading level per section. Nothing was removed. The page now tells you where to look.

• One filled, high-contrast button per view. Secondary actions get an outline, tertiary actions plain text.
• Rank elements with size, weight and colour, and change one of the three at a time.
• Make destructive actions visually quieter than the safe choice, and keep them away from the spot where the primary button normally sits.
• Tone down supporting text with a softer grey that still passes contrast, instead of shrinking it.

Uneven spacing is the most common reason an interface looks amateur, and the cheapest to repair. Pick a scale and allow no other values. A scale built on 4 pixels suits most products: 4, 8, 12, 16, 24, 32, 48, 64. Frameworks already work this way. Tailwind CSS, for example, derives its spacing utilities from a base unit of 0.25rem, which is 4 pixels at the default browser font size.

Then apply one rule: the space inside a group is smaller than the space between groups. A label sits 4 or 8 pixels from its field, fields sit 16 apart, and sections sit 32 or 48 apart. Related items look related because they are close, so you need fewer boxes and divider lines.

Before: a card with 13 pixels of padding on the left and 20 on top, a title 7 pixels above the text and a button that almost lines up with the image. After: 16 pixels of padding on every side, 8 between title and text, 16 above the button, and every element starting on the same left edge.

Too many sizes and weights make a product look noisy. One typeface is enough for an interface. Limit yourself to four or five sizes and two weights, regular plus semibold or bold. A workable set is 14, 16, 20, 24 and 32 pixels, with 16 for body text.

Set line length and line height on purpose. Baymard Institute's article on line length recommends 50 to 75 characters per line for body text, which you can enforce in CSS with a max-width of about 70ch. For line height, 1.5 for body text and 1.2 to 1.3 for headings are safe starting values. The AAA criterion 1.4.8 Visual Presentation in WCAG points the same way: lines no wider than 80 characters and line spacing of at least 1.5 within paragraphs.

Before: a help article running the full width of a 1,440 pixel screen in 13 pixel grey text with tight lines. After: 16 pixel text in a column capped at 70 characters, line height 1.5, left-aligned, with headings two steps up the size scale. The words are the same, and people now finish reading them.

• Left-align body text. Avoid justified text, and avoid centred paragraphs longer than three lines.
• Create emphasis with weight and size before you reach for colour.
• Keep body text at 14 pixels or more, and prefer 16 on phones.
• Check that the layout survives 200 percent text zoom, as 1.4.4 Resize Text requires at level AA.

Low contrast is the one fault you can measure. WCAG 2.2 level AA sets three numbers. Normal text needs a contrast ratio of at least 4.5:1 against its background. Large text needs at least 3:1, where large means 18 point or more, or 14 point bold or more, which is roughly 24 and 18.5 CSS pixels. Both come from criterion 1.4.3 Contrast (Minimum). Criterion 1.4.11 Non-text Contrast asks for at least 3:1 against adjacent colours for the parts of interface components and graphics that people need to perceive, such as input borders, icons, focus rings and chart lines.

Check every text and background pair with the WebAIM Contrast Checker. Ratios are not rounded, so 4.49:1 fails. Placeholder text counts as text. Inactive controls, pure decoration and logos are exempt.

Then reduce the palette to one scale of greys for text, borders and surfaces, one brand colour for primary actions and links, and fixed colours for success, warning and error. Before: #999999 text on white, a ratio of about 2.8:1, and a pale input border that vanishes on a cheap monitor. After: #595959 text on white, about 7:1, and a border dark enough to reach 3:1.

• Pair colour with a second signal such as an icon, a label or an underline. 1.4.1 Use of Color says colour must not be the only way information is conveyed.
• Keep a visible keyboard focus indicator on every interactive element (2.4.7 Focus Visible).
• Reserve the brand colour for things people can click.
• Test dark mode separately. Ratios do not carry over from the light theme.

Inconsistency makes people stop and wonder whether this grey button does the same as that grey button. Take screenshots of every button, input, card and dialog in the product and place them side by side. Most teams discover several button heights and more shades of blue than anyone chose on purpose.

Reduce the collection to one small set and delete the variants. If your framework ships a component library, adopt its defaults instead of fighting them. WCAG asks for consistency at level AA too: navigation that repeats across pages keeps the same relative order (3.2.3 Consistent Navigation), and components with the same function are identified the same way (3.2.4 Consistent Identification).

Forms are where a confusing interface loses people. Give every field a visible label above it. Nielsen Norman Group advises against using placeholder text as the label, because it disappears as soon as someone starts typing. Use a single column, group related fields, mark the optional ones and remove every field whose answer you never use.

For errors, follow NN/g's error-message guidelines: show the message next to the field, say in plain language what is wrong, offer the fix and keep what the person already typed. WCAG covers the same ground. An error must be identified and described in text (3.3.1 Error Identification, level A), fields need labels or instructions (3.3.2, level A), and known corrections should be suggested (3.3.3 Error Suggestion, level AA).

Before: a red banner at the top that says Invalid input, above a form that has been emptied. After: the form keeps its values, the date field shows a red border, an icon and the text Enter the date as DD.MM.YYYY, for example 05.03.2027, and keyboard focus moves to that field.

• Validate when the person leaves a field or submits, not on the first keystroke.
• Set the correct input type and autocomplete attributes, so phones show the right keyboard and browsers can fill in known details.
• Label the button with what it does: Create account, not Submit.
• Do not ask for the same information twice in one process (3.3.7 Redundant Entry).
• Offer a confirmation or an undo for anything that deletes data or spends money.

Teams design the screen full of perfect data and ship the other states by accident. Users meet those other states first: a new account is empty, a slow connection is loading and a typo produces an error. List the states for each key screen and design every one of them.

For loading, Nielsen's response-time limits are a useful guide: about 0.1 seconds feels instant, about 1 second keeps a person's train of thought intact, and about 10 seconds is the limit for holding attention. NN/g's skeleton screen guidance follows similar thresholds: no indicator under a second, a skeleton or spinner for waits of a few seconds, and a progress bar with a time estimate beyond ten.

WCAG 2.2 added criterion 2.5.8 Target Size (Minimum) at level AA. Targets for pointer input must be at least 24 by 24 CSS pixels. There are exceptions. A smaller target passes if it is spaced so that a 24 pixel circle centred on it touches no other target, if the same function is available through another control on the page that does meet the size, if it sits inside a sentence, if the browser determines its size, or if the presentation is essential or legally required.

Treat 24 pixels as the floor, not the goal. The AAA criterion 2.5.5 Target Size (Enhanced) asks for 44 by 44 CSS pixels. Apple's Human Interface Guidelines list 44 by 44 points as the default control size on iOS, and Google's Android accessibility guidance recommends touch targets of at least 48 by 48 dp. A practical rule for touch screens: make the tappable area 44 to 48 pixels even when the visible icon is 20, and leave at least 8 pixels between neighbours.

Next, check the layout at a width of 320 CSS pixels. 1.4.10 Reflow expects content to work at that width without scrolling in two directions. Once the fixes are in, repeat the test from the first step with five new people and the same tasks. Compare how many finish and where they hesitate. Keep what improved, and put what did not back on the list.

• Place primary actions within thumb reach, in the lower half of the screen.
• Replace hover-only menus and tooltips with something that works on tap.
• Use 16 pixel text in inputs. Smaller sizes are widely reported to trigger automatic zoom in Safari on iPhone.
• Test on a real mid-range phone in daylight, not only in the browser's device mode.