For a long time, I thought a website was “done” when it worked.
The pages loaded.
The buttons clicked.
The API responded.
So I shipped.
And yet… something always felt unfinished.
Not broken.
Not wrong.
Just slightly careless.
It took me a while to understand this:
Most websites don’t feel incomplete because of missing features.
They feel incomplete because of missing attention.
The Details We Skip Because They Feel Too Small
There are things we don’t prioritize because they don’t block progress.
Scrollbars.
Focus states.
Text selection color.
Hover transitions.
Keyboard navigation.
None of these will crash your app.
None of them will fail a build.
So we tell ourselves:
“I’ll come back to this later.”
Most of the time… we don’t.
But users notice.
Not consciously... emotionally.
A site either feels considered... or it doesn’t.
And that feeling affects trust more than we think.
When I Started Treating CSS as a User Experience Tool
The first changes I made weren’t dramatic.
They were quiet.
Things like:
- Matching
::selectioncolors to the brand - Adding a subtle custom scrollbar (nothing flashy, just aligned)
- Making hover states consistent across buttons and links
- Ensuring focus outlines were visible instead of removing them
- Adding smooth but restrained transitions
None of this made my site “cooler”.
It made it calmer.
And calm is underrated on the web.
A website doesn’t need to impress.
It needs to respect attention.
Scrollbars, Selection, and the Feeling of Care
Custom scrollbars are controversial.
And honestly? They should be.
This isn’t about decoration.
It’s about alignment.
When a scrollbar slightly reflects your brand color, without harming usability, it signals intention.
Same with text selection.
Users select text constantly: copying error messages, sharing snippets, highlighting sections.
If the highlight color clashes harshly with your palette, it subtly disrupts the experience.
It’s a small adjustment.
But small adjustments compound.
Lighthouse Didn’t Just Give Me Scores; It Changed My Habits
At first, I treated Lighthouse like a scoreboard.
Green = good.
Red = fix later.
But once I paid attention, I noticed something:
Most Lighthouse improvements weren’t about hacks.
They were about discipline.
- Compressing and properly sizing images
- Fixing contrast instead of overriding it
- Removing unused JavaScript
- Avoiding layout shifts
- Testing on mobile instead of assuming desktop is enough
My scores improved.
But more importantly... my sites felt lighter.
A small habit that helped: I always run Lighthouse in a fresh incognito window. That way, cached assets, extensions, or logged-in states don’t distort the results.
It keeps the feedback honest.
Accessibility Isn’t Extra Work; It’s Basic Respect
This realization changed everything for me.
Accessibility (A11y) used to feel like an advanced layer, something you “optimize for later.”
But most meaningful accessibility improvements are simple:
- Proper color contrast
- Visible focus indicators
- Semantic HTML instead of div soup
- Buttons that are actually
<button>elements - Supporting keyboard navigation
- Respecting
prefers-reduced-motion
None of this is complex engineering.
It’s thoughtful defaults.
Accessibility doesn’t make your site worse for anyone.
It makes it usable for more people.
And when you start thinking that way, it stops feeling optional.
Mobile Performance Exposes What Desktop Hides
Desktop performance is forgiving.
Mobile is honest.
The moment I started checking mobile Lighthouse scores consistently, patterns emerged:
- Oversized images
- Late-loading fonts
- Layout shifts from dynamic content
- JavaScript I didn’t really need
Fixing these didn’t just improve metrics.
It improved trust.
Fast sites feel reliable.
Slow sites feel careless, even when they technically work.
Users may not know why something feels off.
But they feel it.
What Changed When I Started Caring About the Small Stuff
Shipping felt different.
I stopped feeling like my projects were “almost done”.
I stopped apologizing for rough edges.
My sites didn’t scream for attention.
They quietly earned it.
And interestingly, when accessibility improved, performance often improved too. Cleaner structure. Less unnecessary code. Better defaults.
Care tends to cascade.
What I No Longer Ignore
❌ Focus states
❌ Color contrast
❌ Mobile Lighthouse scores
❌ Accessibility warnings
❌ “It’s good enough” moments
Small things compound.
Neglect does too.
Final Thoughts (From One Developer to Another)
You don’t need more frameworks.
You don’t need more features.
Sometimes, you just need to slow down enough to notice what users already feel.
Good websites aren’t loud.
They’re considerate.
They don’t show off effort.
They show care.
And care, quietly, builds trust.
Take your time.
Polish the small things.
That’s what makes a website feel finished.
Wishing you calm UI, thoughtful defaults, and pride in the details, friends 💙.
What’s one “small” detail you started paying attention to that made a bigger difference than expected?
| Thanks for reading! 🙏🏻 I hope you found this useful ✅ Please react and follow for more 😍 Made with 💙 by Hadil Ben Abdallah |
|
|---|




Top comments (25)
The Lighthouse-in-incognito tip is one of those things that seems obvious once you hear it but I bet most people don't actually do it. Cached assets and extensions can easily add 500ms+ of phantom performance to your scores.
I run Lighthouse checks as part of my deploy pipeline for a multilingual data site with thousands of pages, and the thing that surprised me most was how much semantic HTML alone moved the needle. Replacing a few nested divs with proper section/article/nav elements didn't just improve accessibility scores — it actually helped search engines understand the page structure better too. The SEO and a11y improvements were almost identical fixes.
To answer your question: the detail that made the biggest difference for me was adding visible "Last Updated" timestamps. Such a tiny thing, but it immediately made pages feel maintained rather than abandoned — especially for data-heavy content where freshness matters.
the lighthouse in deploy pipeline part stood out. are you actually failing builds on score drops or just tracking trends? i tried something like this once and mostly ended up chasing network noise
Glad that part stood out!
For me, it’s mostly about tracking trends rather than failing builds. Running Lighthouse in a fresh incognito window keeps the feedback honest, and I focus on patterns over single drops; otherwise, like you said, it’s easy to get lost in network noise.
Tracking trends, not failing builds — learned the same lesson you did. Network noise makes hard-fail thresholds unreliable, especially for Lighthouse performance scores. A CDN blip or a slow third-party script can swing the score by 15+ points between runs.
What I do instead: run Lighthouse in CI but only flag if the score drops below an absolute floor (85 for performance, 95 for accessibility). Above that, I log the score to a file and review the trend weekly. If I see a consistent downward drift over 3+ builds, that's a real regression worth investigating. A one-off drop is almost always network noise.
The accessibility and SEO scores are much more stable though — those are mostly deterministic (missing alt tags, heading order, meta descriptions). I'd actually recommend hard-failing on those if you revisit the idea.
Running Lighthouse in the deploy pipeline is next level.
And yeah, the semantic HTML point is spot on. It’s one of those changes that feels small, but it improves a11y, SEO, and structure all at once. Hard to beat that kind of impact.
Also love the “Last Updated” detail. It’s simple, but it instantly builds trust, especially on content-heavy pages.
Really appreciate you sharing this; there’s a lot of good insight in here.
100% agree on the "Last Updated" timestamps — we added dateModified schema markup alongside the visible date on our content pages and it made a noticeable difference in how Google treats the freshness signal. Small detail, big trust signal for both users and crawlers.
The semantic HTML point is one I keep coming back to. Swapping generic divs for proper landmarks (nav, main, article, aside) costs almost nothing in development time but the compound benefits across a11y, SEO, and screen reader navigation are real. It's the highest ROI refactor you can make on most codebases.
So true! On our Next.js landing page, the Spline 3D hero looks flashy but it's the GDPR cookie consent with 3 toggles, the i18n in 6 languages with localized routes, and the micro-interactions that make the difference between 'wow' and 'professional'. Accessibility is often overlooked — semantic HTML + proper aria labels cost almost nothing but improve the experience for everyone.
Totally agree. The flashy parts catch the eye, but it’s the small details like cookie consent, i18n, micro-interactions, and proper accessibility that make a site feel solid and professional. Those things really do make the experience better for everyone.
Exactly! Cookie consent is a great example — it's one of those things where getting it wrong doesn't break the site, but getting it right signals "these people care about details." We spent a full sprint on GDPR compliance with 3 toggle categories (necessary/analytics/marketing) and Google Consent Mode integration. Not glamorous work, but it's the kind of thing that builds trust silently.
The i18n point really resonates too — we localized our Next.js site in 6 languages, and the surprising result was that 60% of our traffic now comes from non-French speakers. Those "small details" became our biggest acquisition channel.
Great article — it captures something most devs feel but rarely articulate!
This is a good line. Even if you think it is small, there will always be a user that is internally grateful that your small adjustment exists.
If you think about it, the more small adjustments you make, the more users would "feel" that the site is polished and complete. This is a win in quality!
That’s exactly it.
Each small adjustment might go unnoticed on its own, but together they shape how the whole product feels. That sense of “this is well put together” doesn’t come from one big thing; it’s the accumulation.
This hits close to home. My current struggle is the opposite problem — I keep polishing details instead of shipping, and every Lighthouse run reveals something new to fix.
The balance I've landed on: pick 3 metrics as your "done" bar (Performance > 90, Accessibility > 95, SEO = 100) and stop touching anything that doesn't move those numbers. Everything else is procrastination disguised as quality.
The mobile Lighthouse point is underrated. Desktop scores are flattering. Mobile scores are honest. Running both changed how I prioritize work.
That’s a very real trap. I’ve been there too.
I like your “done” bar idea a lot. Having clear thresholds is what keeps polishing from turning into endless tweaking.
And yeah, mobile Lighthouse is humbling in the best way. It forces you to focus on what actually matters instead of what just looks good on desktop.
i've been using megallm for a side project and spent way too long on the loading states turns out people actually notice when spinners feel intentional vs just slapped on the polish compounds good skeleton screens make the api latency feel faster even when it's not
Exactly! A well-thought-out loading state or skeleton screen doesn’t just look nicer; it actually feels faster to users. It’s crazy how much these small touches shape the perception of your whole app.
Alright, fair 😄
Man… this hit a bit too close. That “it works but still feels off” phase is so real. I’ve shipped stuff like that and couldn’t explain why I wasn’t fully satisfied with it.
The “calm UI” part is honestly gold. Most people try to make things flashy, but that quiet, polished feeling is what actually makes a site feel legit.
Really good read. This is the kind of stuff you only start caring about after you’ve built a few projects.
Haha 😅 I know exactly what you mean; that “it works but something’s off” feeling is hard to ignore once you notice it.
Really glad the “calm UI” idea resonated. Flashy gets attention, but that quiet, polished feel is what builds trust.
And yeah, it definitely comes with experience; you start seeing what actually matters after shipping a few things. Appreciate you taking the time to share this 😍
This was a great read. I am just starting to dabble in UX a bit and the idea of calm ui really resonates.
Really appreciate that. Glad it clicked.
“Calm UI” is one of those things you start to notice once you slow down a bit. It’s less about adding more and more about removing friction.
You’re starting in a really good place with that mindset.
Nice, unconsciously, people always feel this! Do you have some examples of websites that got this proper treatment from you?
Appreciate that 😍 you’re right, people feel it even if they can’t explain it.
Yeah, I’ve got a solid example from a frontend challenge I worked on. I shared the full breakdown here
You can check the landing page I built for it inside the article.
Quick note: I’m sharing the article instead of the direct site link because Dev usually flags external links in comments. The hosted version is included inside the post.
Hi, Hadil, How are you?
I am a recruiter at techstacks-creator solution.
Currently we are looking for a contract developer for an existing project development.
Looking forward to discuss about that position with you.
Best, Ashlyn
This article nails something I have been struggling with. I launched a digital product store last week and the products were solid, but the store page felt unfinished. Turns out adding loading states, consistent spacing, and proper alt text made visitors stay 3x longer. The details ARE the product. Bookmarking this as my design checklist. Great work @hadil!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.