Why Good UX Isn’t About Making a Website Look Beautiful

My site opens with a loader that fills a portrait silhouette, then a curved 3D ribbon of images arcs across the hero. It’s the showpiece. The good UX detail I’d defend hardest is far less photogenic: on the blog, after you search and filter, the Back button still takes you where you expect.

That gap is the whole argument of this piece. Good UX is whether people can do what they came for without thinking about the interface at all, and most of the decisions that get you there are invisible when they work.

Beautiful is the entry fee to good UX

A polished visual design buys a few seconds of trust. It tells a visitor the business is real and that someone cared. I’m a designer; I’m not going to pretend that doesn’t count.

But looks have become cheap to produce. Templates, page builders and AI design tools can all turn out something attractive quickly, so a good-looking site no longer tells you much. Looks are not what separates an AI-generated website from a well-designed one.

Once a site looks credible, the things that decide whether it works are plainer:

• Clarity: you can tell what this is and what to do next.
• Findability: you can get to the thing you came for.
• Feedback: when you act, the site tells you what happened.
• Trust: it behaves the way you expect, every time.

None of those show up in a screenshot. All of them show up in the first minute of real use.

The best decision on my blog is one nobody will notice

My blog has 220+ older posts, mostly short WordPress, WooCommerce, ACF, PHP and JavaScript snippets. People don’t browse an archive like that; they hunt through it. So the search box and the category filter update the results live, without a page reload.

Live search is easy to get subtly wrong. The lazy version swaps the cards and leaves the address bar alone. You open an article, press Back, and land on the unfiltered blog with your search gone. Send the link to a colleague and they see something different from you.

On my site the URL follows along. Typing updates the current history entry instead of adding one per keystroke; picking a category or a page adds a real step that Back can return to. A shared link opens the same results, and without JavaScript the same links and form simply load normal WordPress pages. The browser’s History API does the heavy lifting:

// Typing: update the current entry, don't add one per keystroke
history.replaceState(view, '', url);

// Picking a category or a page: a new step Back can return to
history.pushState(view, '', url);

// Back / Forward: redraw the results for that step
window.addEventListener('popstate', (event) => {
  if (event.state) showResults(event.state);
});

A smaller, single-purpose example of pushState() is in updating the URL without reloading the page.

The search also waits for a second character and a short pause before it asks the server for anything. When all of this works, nobody thinks about it. When it doesn’t, everyone who uses the filter pays for it, usually without knowing why the site felt annoying.

Say what happened, even when the answer is nothing

Feedback is the least glamorous part of UX and the part people feel most.

When a search on my blog finds nothing, the page says “No articles match your search.” When a category is empty, it says “No articles yet.” Two short sentences, two different truths: one tells you to change your query, the other tells you not to bother. A blank grid tells you neither. It just looks broken. Screen reader users hear the result count too, through a polite live region, because a silent swap of cards is invisible if you can’t see it.

Every code block has a Copy button. Press it and the label changes to “Copied” for two seconds, while screen readers hear “Code copied to clipboard”. If the browser blocks clipboard access, the button asks you to copy with the keyboard and selects the code for you, so the task still gets done.

That fallback will rarely be seen. It’s still the most honest bit of interface on the page: it admits the first attempt failed and hands you the next step.

Don’t protect the layout at the content’s expense

Code on my site wraps long lines instead of hiding them behind a horizontal scrollbar. In a mockup the scrollbar version looks tidier: a clean right edge, no ragged lines. On a phone it hides the end of every long line, which is often the exact argument or closing bracket you came to copy.

Wrapping has a cost. A wrapped line can look like two lines of code. Line numbers settle it: each number sits on the first row of a real line, so a wrap reads as a wrap. Small trade, big gain in readability.

The same rule reaches well past code. Headlines cropped to fit a card, names cut off with an ellipsis, descriptions clamped to two lines: sometimes that’s the right call. When the hidden part is what the visitor needed, the layout won and the user lost.

Where beauty gets in the way of good UX

Some UX problems are caused directly by the pursuit of looking good:

• Low contrast. Grey text on a dark background looks refined in a design file and turns hard to read on a glossy laptop by a window. A dark editorial site like mine needs more discipline here, not less.
• Tiny type. Small uppercase labels with wide letter-spacing look elegant and ask a lot of tired eyes.
• Motion without an off switch. Smooth scrolling, parallax and scroll reveals are part of my site’s character. They also stand down when a visitor’s system asks for reduced motion, because for some people that movement causes real discomfort.
• Effects that assume a mouse. The custom cursor only runs on devices with a precise pointer. On a touchscreen it would be dead weight.

Heavy effects also cost speed, which is a UX problem of its own (more in designing websites that feel fast). Beauty and usability aren’t enemies. But every visual effect should come with a question attached: who does this leave out, and what’s their fallback?

Review tasks, not screens

Most design reviews walk through pages: home, about, services, blog. Each gets judged on its own, as a picture. That’s how a site ends up beautiful page by page and clumsy in between.

Tasks are a better unit. Write down the handful of things visitors actually come to do, then do them on a phone, with a keyboard, on a slow connection and with real content. For my site that means finding a snippet and copying it, filtering the portfolio and loading more without losing the category, getting from a Contact link to Upwork without a detour, and following an old link to somewhere honest.

The rebuild’s verification made the same split. Screenshots compared the pages against the static design at desktop and phone widths, which checked that it looked right. Scripted tests clicked through the filter and “load more”, live search, copy buttons and redirects, which checked that it worked. Both mattered, but only the second kind tells you whether someone can get something done.

A task has a finish line. A screen doesn’t.

So make it beautiful; that part isn’t optional. Then stop looking at it and try to use it. The best UX on a site is the stuff nobody compliments, because nobody had to notice it. The details that add up to that feeling are collected in the small UX details that make a website feel premium.