Why I Changed My Portfolio UI Into a Systems Journal

One of the results I most want readers to see is a query on a financial platform for public transportation that used to exceed a 60-second database timeout and now runs in under 600 milliseconds. My old portfolio had no good place for a sentence like that. It presented work through cards, short project summaries and controls that took more space than the content, so a reader had to infer engineering judgment instead of seeing it.

The site worked. It had projects, writing, contact pages, two languages and a polished enough presentation. But its structure said "here is a person and their tools", and the work I want to be trusted with is designing reliable systems and explaining why specific technical decisions mattered. The interface was not showing that.

So I wrote a redesign brief with one thesis: the portfolio should read as evidence of engineering judgment. The direction got a name, Systems Journal: restrained, closer to technical publishing than to a startup landing page, with real engineering evidence at the center. This post explains what changed and how I intend to check whether it helps.

A project is a decision, not a card

The largest change is how featured work is presented. The public transportation financial platform is now a case study: system context, the operational problems, the engineering decisions and the measured outcomes, in that order. A reader should come away knowing what was hard about the system and what I chose to do about it, not just which framework it used.

That principle shaped the rest of the homepage:

• The homepage leads with proof points. The hero states positioning, current context and calls to action, backed by figures such as weekly processed volume and active users. The query result, from timing out at 60 seconds to under 600 milliseconds, sits in the featured case study.
• The header became quieter. Navigation uses numbered labels (01 Work, 02 Notes, 03 Profile, 04 Contact). Theme and language are small utilities. The old preferences panel is gone, replaced by a compact language toggle next to the theme toggle.
• Sections are not all equal. The strongest evidence comes first. The biography comes later.

What I deliberately left out

The visual language moved toward warm editorial surfaces, thin borders, compact labels and rectangular panels. The brief also listed what to avoid: glowing gradients, fake terminals, glassmorphism, floating cards, large badge clouds, and placeholder preferences or unfinished UI controls.

None of those is wrong in itself. The test I applied was whether an element helps a reader understand a piece of engineering work. A terminal animation says "developer" without saying anything about my decisions, and a badge cloud lists tools without showing what I did with them. Removing them left more room for the things that do.

A thirty-second test for your own portfolio

I do not think every engineer should copy this style, and a portfolio does not need to look like documentation. I would suggest one exercise, though: open your homepage and ask what a reader would remember after thirty seconds. If the answer is the color scheme or a list of frameworks, the interface may be underselling the work behind it.

How I will know whether it works

The redesign makes the site's intent more explicit. That is not the same as showing that visitors understand my work better. I have not run a reader study or measured anything since the change.

The check I plan to use is simple: ask someone unfamiliar with my work to spend a few minutes on the site, then tell me one technical decision I made, the constraint behind it and the evidence of its outcome. If they can, the structure is doing its job. If they remember only the technologies or the visual style, it needs more work.

I want to apply the same criterion to every future change to the site: a section earns its place if it helps a reader reconstruct an engineering decision.