You can tell when an interface feels right. Saying why is the hard part.

It looked fine. It didn't feel right.

After completing a screen everything looked perfect. Everything aligned properly, colors were balanced, nothing stood out as incorrect. But something was not working. There was something in a button, the transition appeared slightly too late or the list felt fine in the mockup but cheap when animated.

The worst part is that I couldn't figure out what the problem was. I just knew it is not what I appreciated in the applications I use daily. Close, but not it.

For some time, I thought I am just not good enough. Some people have taste and I don't.

I did the usual things.

I read a ton of design books. Studied grids and type scales. Saved screenshots into folders that never got opened. Followed designers who made me jealous.

Most of those materials taught me the obvious principles: layering, layout, colors, hierarchy. All the things you can include in a presentation. They helped. But only partially. It stopped where my problems started.

Nobody discussed the part I couldn't see.

The good stuff was never written down.

The things that made interfaces feel alive were hiding in between. Few pixels nobody talks about. Easing of a menu to make it feel natural and not robotic. The ability of the good software to do everything slowly in a proper place and super fast in another.

I would spot one of them by accident, recognize how much it meant and realize how obvious it was the whole time.

There was no course for it. No checklist. Just a bunch of people who were able to do it but didn't know how.

That is why I decided to write it down myself.

I wrote down every detail until it added up to something.

Initially, it was my personal project. Whenever anything felt good, I would stop and ask why. Then rebuild it to understand the reasoning behind the choice.

The archive grew rapidly. Eventually, the patterns appeared. It turned out the invisible things were not random at all - there was always a reason behind them. Timing. Weight. Awareness of what to avoid.

All those things combined together became Invisible Details. It is the resource I was looking for years ago and couldn't find.

You've felt all of this already. You just haven't been shown it.

If you have ever shipped an app that worked great technically, but felt flat, this is what was missing. This is the difference between an interface that works and one that feels like it has been done with passion.

You don't need more talent for this. You just need to know where to look. Once you see these details, you will never stop seeing them. And eventually start using them yourself.

What you'll learn.

There are two chapters: Notes, then Practice.

First, the theory. Then watching it getting applied. Designed to be read carefully and revisited later.

Notes

The ideas. Every lesson focuses on one topic - states, feedback, inputs, speed - showing how I think about them. Each includes practical examples. These apply to any interface component you will ever design.

Practice

The application. Breaking down a single interface component and examining every single decision, the trade-offs behind it and alternatives of doing it in other places.

Start with a single observation.

The best way to understand Invisible Details is to experience it. Read a few chapters for free and see how an everyday interface is broken down into small, deliberate decisions.