Why your UI looks unprofessional: 9 details to fix before launch

A UI looks unprofessional when its small decisions disagree with each other: three corner radii on one screen, icons from two different sets, a price that slides sideways every time it updates. None of these is a bug. Together they tell the person using the product that nobody checked, and people form that impression before they've tried a single feature.

The impression has been measured. In a Stanford study where people compared the credibility of live websites, the design look was the factor mentioned most often, in 46.1% of all comments, ahead of how the information was structured. The study dates from 2002 and the web has changed since. The finding still matches what we see in reviews: people read polish as a sign of care, and care as a sign the product will work.

This list is the pass we run on a screen before we call it shipped. The larger craft topics have their own articles: the typographic scale, hierarchy without color and optical alignment. The nine details below are the ones that slip through when those are already right.

How we picked the nine

Each detail meets three conditions. Someone outside the team notices it within seconds, even if they can't name it. It can be checked on a finished screen, by eye or with the browser's dev tools. And the fix is a rule, a token or a CSS property, so it stays fixed once a component carries it. Where a public standard sets a threshold (WCAG 2.2, Core Web Vitals), we give the number and the source.

Which details make an interface look unfinished?

1. Spacing that's off the scale

Measure the gaps on a draft screen and you'll often find 13, 14, 15 and 18 pixels doing the same job. Each value looked right when someone typed it. Together they make a rhythm the eye reads as uneven, even when it can't say why.

The fix is a spacing scale, usually on a 4 or 8 pixel base, exposed as tokens so nobody types a raw number. Then one rule on top: related items sit closer together than unrelated ones. A label belongs to its field, so it sits nearer to that field than to the one above. When a gap needs an exception to look right, that's an optical correction. It goes into the component, written down, instead of into a one-off margin.

2. Corner radii that don't nest

Put a button with a 16 pixel radius inside a card with a 16 pixel radius, 8 pixels from the edge, and the corners look slightly wrong. The two curves don't run parallel, so the inner shape looks swollen.

The rule designers use: the outer radius equals the inner radius plus the padding between them. A 12 pixel button inside 8 pixels of padding wants a 20 pixel card. Treat the formula as a starting point and check by eye, because with very small inner radii the result can look too round. The other half of the fix is a short radius scale, three or four values, so a single screen can't collect six.

3. Icons that don't match the text

Icons taken from two libraries bring two stroke weights, two corner styles and two ideas of how much of its box an icon should fill. Next to text the mismatch is obvious. A 24 pixel icon beside 14 pixel text shouts. A 2 pixel stroke beside a light typeface looks heavy.

Use one icon set. Size icons to the line height of the text they sit with, and match the stroke to the weight of that text. Then check the vertical alignment by eye: icons are centered on their box, text is centered on its x-height, so an icon that's mathematically centered often reads a pixel too high. It's the same kind of correction covered in our article on optical alignment.

4. Numbers that wobble

Most interface typefaces use proportional figures by default: a 1 is narrower than an 8. Inside a sentence that's fine. In a table column, a running total or a countdown it's a problem. Digits don't line up, and a number that updates in place jumps sideways on every change.

One CSS property fixes it. font-variant-numeric: tabular-nums switches to figures of equal width, and it has worked in every major browser since January 2020. Apply it to tables, prices, timers and any number that changes while someone is looking at it. Then right-align numeric columns so units sit under units. It's one line, and a dashboard reads as finished because of it.

5. Missing interaction states

A draft usually designs each control at rest and stops there. A shipped control needs more: hover, pressed, focused from the keyboard, disabled, loading. A button that doesn't react when clicked looks broken. A form that loses its focus ring looks unfinished to everyone who navigates with a keyboard.

WCAG 2.2 sets the floor. Keyboard focus has to be visible, and the focused element can't be entirely hidden by the page's own content, such as a sticky header or a cookie banner. Pointer targets need to be at least 24 by 24 CSS pixels, or have enough room around them that a 24 pixel circle centered on each doesn't touch its neighbors. Both are Level AA. Design the states as part of the component, so every instance gets them at once.

6. Text that wraps badly

A heading that leaves one word alone on its second line. A card title that takes one line in English and three in German. A long customer name that pushes the button beside it off the card. Draft screens use copy of the length the designer chose. Real copy comes in every length.

For headings, text-wrap: balance evens out the line lengths, and all major browsers support it. For paragraphs, text-wrap: pretty avoids a lonely last word; where a browser doesn't support it, the text wraps as before, so it's safe to add. For anything that comes from data, decide the rule in advance: truncate with an ellipsis and show the full value on hover, allow two lines, or let the layout grow. Then test with the longest real value you have, never the average one.

7. Layout that jumps while it loads

The page appears, someone reaches for a button, an image loads above it and the button moves. Few things make a product feel cheaper. Google measures this as Cumulative Layout Shift, and a good score is 0.1 or less at the 75th percentile of page loads.

Three causes account for most of it: images without dimensions, content inserted above what's already on screen, and web fonts that swap in at a different size. Give every image and video width and height attributes, or an aspect ratio, so the browser reserves the space. Give loading states the size of what they'll hold, such as a skeleton row as tall as a real row. Reserve room for banners before they arrive. Our guide to Core Web Vitals on Next.js covers the framework-specific fixes.

8. Grey text nobody can read

Light grey secondary text looks refined in a design tool on a calibrated monitor. On a laptop in daylight it disappears. So do input borders so faint the field is hard to find.

WCAG gives numbers for both. Body text needs a contrast ratio of at least 4.5:1 against its background, and large text 3:1. The visual parts that identify a control, such as an input's border or a checkbox outline, need 3:1 against the colors next to them. Build the grey ramp with those ratios decided in advance, so a muted-text token passes by construction. Fewer greys help as well. A screen with seven slightly different greys looks unplanned, and three or four steps cover most interfaces.

9. Placeholder copy and placeholder data

"Untitled", lorem ipsum, a button labeled "Submit", a table where every row has a tidy name and exactly three items. Draft screens are full of content that was never meant to ship, and some of it ships. Data is the subtler case: the design shows 3 items, production shows 0, 1 and 4,000.

Before a screen is done, run it through the edge cases: no data, one item, a very long list, a very long name, a missing image, an error. Each one needs a designed answer, which is what empty state design is about. Then read every label as the user would. "1 items" and a generic "Submit" are small, and people notice both. For counts, Intl.PluralRules picks the right plural form in every language the product ships in.

Which fixes come first?

The nine don't cost the same. Grouped by how much they change the impression per hour of work:

• One line of CSS: tabular figures, balanced headings, image dimensions. These can go out today.
• One token change: the spacing scale, the radius scale, a grey ramp with contrast built in. Once components read the tokens, every screen improves at once.
• One component change: interaction states, icon sizing, truncation rules. Fixed once in the component, inherited by every instance.
• One review habit: edge-case data and real copy. Code can't fix these. They belong in the team's definition of done.

The pattern behind the grouping: a detail fixed by hand on one screen comes back on the next. A detail fixed in a token or a component stays fixed. It's also why these problems pile up over time in products without a system, the component drift we've written about before.

How do you check a screen in ten minutes?

We run this pass on every screen before it ships. It needs a browser and nothing else.

1. Zoom out to 50% and squint. Uneven gaps and stray radii show up before the content does.
2. Click the address bar and press Tab through the whole page. Every control should show focus, and none should disappear behind a sticky element.
3. Throttle the network to a slow mobile profile in dev tools and reload. Watch for anything that moves.
4. Swap one name for the longest real value in the database, and one list for an empty one.
5. Run a contrast check on the lightest text and the faintest border.
6. Read every button label out loud.

Six checks take about ten minutes, and they catch most of the nine details before a user does.

Sources

• Fogg et al., How Do People Evaluate a Web Site's Credibility? (Stanford, 2002)
• Frontend Masters: The classic border radius advice
• MDN: font-variant-numeric
• W3C: Understanding SC 2.4.11 Focus Not Obscured (Minimum)
• W3C: Understanding SC 2.5.8 Target Size (Minimum)
• MDN: text-wrap
• web.dev: Cumulative Layout Shift (CLS)
• W3C: Understanding SC 1.4.3 Contrast (Minimum)
• W3C: Understanding SC 1.4.11 Non-text Contrast
• MDN: Intl.PluralRules
• AccessibleEU: The European accessibility standard EN 301 549 has been updated