Design

Why Good UI Takes More Than Just Writing CSS

For a long time, I thought being ready came before building.

I thought I needed a better plan, more knowledge, a cleaner architecture, better designs, and more confidence before putting something into the world.

Eventually, I realized that this creates a problem.

There is always another thing to improve.

The first version is supposed to be imperfect

When you are building something yourself, it is easy to become attached to the idea of getting everything right.

You see every rough edge because you built it.

You know which component was rewritten three times. You know which feature still needs work. You know which part of the code you aren't completely happy with.

Users don't have that context.

They see the result.

That doesn't mean quality doesn't matter.

It means perfection is a moving target.

Building teaches things planning cannot

You can spend days planning a feature and still discover problems within the first hour of implementing it.

Maybe the data structure doesn't fit the UI. Maybe the interaction is awkward. Maybe a screen needs more context. Maybe the original idea isn't as useful as you thought.

Those discoveries are not failures.

They are information.

The earlier you get real feedback, the earlier you can make better decisions.

Projects change

One of the hardest lessons for me has been accepting that projects evolve.

The first idea isn't necessarily the final product.

A feature that seemed essential might become unnecessary. A small experiment might become a major part of the application. A design can look perfect in theory and feel wrong when implemented.

That is normal.

The mistake is treating every change as proof that the original plan was bad.

Sometimes changing direction is simply part of building.

Perfectionism can disguise itself as productivity

This one is uncomfortable.

Sometimes polishing is genuinely useful.

Sometimes you're just avoiding the moment when the project becomes real.

Changing a button for the tenth time can feel productive. Adding another feature can feel productive. Rebuilding the same screen with slightly different spacing can feel productive.

But if none of those changes help the project move toward users, feedback, or launch, they can become a loop.

I have had to learn to recognize that.

Shipping creates a different kind of pressure

There is something powerful about knowing another person might actually use what you built.

Suddenly documentation matters more. Error states matter. Performance matters. Broken links matter. Accessibility matters. Authentication matters.

Small bugs stop being theoretical.

That pressure can be uncomfortable, but it is useful.

It turns development from an isolated exercise into a real product process.

Confidence comes after evidence

I used to think confidence was something you needed before starting.

Now I see it differently.

Confidence often comes from evidence.

You build something. It works. You fix a bug. You solve a problem. Someone uses it. You receive feedback. You improve it.

Each step gives you evidence that you can handle the next problem.

You don't need to feel completely confident before beginning.

You need enough confidence to take the next step.

Finishing is a skill

Starting projects is exciting.

Finishing them is different.

The early stage is full of possibilities.

The final stage is full of decisions.

You have to stop adding. You have to prioritize. You have to accept tradeoffs. You have to fix boring issues. You have to test. You have to publish.

That is why finishing is not simply the end of development.

It is a separate skill.

What I would tell another developer

If you're waiting until you feel completely ready, you're probably going to wait forever.

Learn enough to start. Build enough to discover the next problem. Solve that problem. Repeat.

Don't use "I'm still learning" as a reason to avoid building.

You can learn while building.

At the same time, don't use "I just want to ship" as an excuse for careless work.

There is a balance.

Build seriously. Polish what matters. Know what can wait. Then release.

The goal isn't to prove that your first version is perfect.

The goal is to create something real enough that reality can teach you what to do next.