I bought things because I like design.

That became obvious when my desk started looking like a museum and my work process looked like chaos.

I had good intentions and too many gadgets.

The clearest example was a smart lamp I bought because it looked advanced.
It looked good on paper, and better than my existing lights in every demo video.
But once it got to day-to-day use, it became the opposite of useful: I had to manage it all the time.

That is how this framework formed, in the exact order I learned it:

Function precedes Convenience precedes Aesthetics#

I call it FCA, and I use it as a design and engineering filter.

1) Function#

Function is the floor.
It means a product, page, or feature does the job it is meant to do at the moment someone needs it.

If something does not work, all the polish in the world is irrelevant.

I sometimes explain it with cars because it is easier:

You can put a luxury badge on a car. You can make it look gorgeous.
If it won’t start, it fails the problem before it has any chance to feel “good.”

So I start every decision by asking:
Does this work reliably for the core use case?

2) Convenience#

Convenience is function with friction removed.

A feature can work and still be bad if it forces constant effort just to stay usable.

My lamp example was still a lamp with features. It just shifted work onto me.

The right move is not “more controls.” It is:
does the system reduce routine burden over time?

In product terms, convenience is where you test:

  • maintenance overhead
  • setup cost
  • interruption rate
  • error recovery

If users keep paying hidden costs to keep something running, it is function in name only.

3) Aesthetics#

Aesthetics matter, but they are only honest once the first two layers hold.

I am not anti-beauty. I just don’t want beauty to be an alibi for weak utility.

When two options are equally solid on function and convenience, then design clarity, type, spacing, rhythm, and emotion become meaningful differences.

In that order.

Why this changed how I build this site#

I did not set out to make a “clean design template.”
I set out to make a dependable surface for thought, reading, and work.

That means this site’s first rule is: no novelty for novelty’s sake.

That means minimal defaults, restrained controls, and fast paths to content.

That means: if a feature does not improve completion, it should be removed.

The result should not feel sterile. It should feel stable.

What this gives me#

When I post using FCA, I avoid a lot of noise:

  • flashy features that won’t be used
  • complexity that changes with every mood
  • and interface choices that depend on perfect conditions

And I get something better in return:

  • clearer priorities,
  • cleaner editing,
  • fewer excuses,
  • and work that ages better when I use it later.

What this is for me right now#

I’m early in my path.
That helps me: this is not a finished doctrine, it is a rule I can actually practice and improve.

So this is the first published manifesto because I am intentionally building public evidence of how I work.

Not as a polished performance.
As a working system.

If this framework is the right one for me, it should survive:

  • time,
  • mistakes,
  • constraints,
  • and review.

That is what I want this site to be.

Thanks for reading.