My first real job was not in engineering. It was in Doha, at a desk in a law firm, where I was the graphic designer and the IT guy — sometimes in the same hour. I set type for letterheads in the morning and untangled a printer driver in the afternoon. Later I did the same dance for a school. Nobody on those teams thought of design and systems as the same discipline. I didn't either, not yet. But I was learning one thing in two languages, and it took me a decade of platform work to notice it.
People are sometimes surprised that I career-shifted from graphic design into full-stack and then into architecture. They treat it as a clean break, as if I left one trade for another. It wasn't a break. It was a translation. The questions a good designer asks — what does the eye land on first, what can be removed, where does the reader get lost — turn out to be the same questions a good architect asks about a system. I just had to learn to ask them about boundaries, contracts, and call graphs instead of grids and kerning.
Taste isn't decoration laid on top of engineering — it's the discipline of caring what something is like to use, and that discipline is the same whether the user is a member of the public or a developer reading your API for the first time.
Hierarchy, whitespace, and the user
Visual hierarchy is the art of deciding what matters most and making the design say so without a caption. The eye should know where to go. A system has hierarchy too, and most badly-built ones fail here first — everything is equally loud. Every service can talk to every other service, every module imports everything, and the reader of the codebase has no idea what's load-bearing and what's incidental. When I architected Good Law Software, a legal practice-management SaaS that ended up managing fifteen thous" worth of live cases, the hardest decisions weren't about VueJS or .NET Core or SQL Server. They were about hierarchy: what is the core domain, what is supporting, what should the rest of the system never be allowed to reach into. That's composition. That's deciding where the eye goes.
Whitespace was the lesson that took longest to respect. Junior designers fill the page; mature ones defend the empty parts. In systems, whitespace is everything you deliberately leave out — the feature you don't build, the abstraction you don't add, the config option you refuse. On the oil-and-gas mobile work, where I was setting micro-frontend conventions for a hundred-plus internal developers across multiple vendors, the temptation was to give them a framework that did everything. The right move was the opposite: a small, opinionated core with a lot of intentional emptiness, so teams had room to move without colliding. A best-practices framework that tries to anticipate every case is a poster with no margins. Nobody can read it.
And the user. Design beat into me, early and permanently, that the artifact is not for me. The brand I made for that law firm was not there to express my taste; it was there to make a client trust a stranger with their problem. When we built the frontend and the ticker for a COVID vaccination app that an Australian government put in front of five million residents, I thought about that constantly. The people using it were anxious, in a hurry, on whatever phone they happened to own. The system existed to serve them, not to be admirable to its authors. Architecture has the same humility built in, or it should.
Taste is a technical skill
People treat "taste" as the soft part, the garnish you add once the real engineering is done. I think that's exactly backwards. Taste is the compressed, fast judgment that lets you feel a bad API before you can fully articulate why. An endpoint that returns three different shapes depending on a flag, a function that takes seven positional booleans, a deploy pipeline where dev, qa, integration and prod each behave subtly differently — you can sense the wrongness the way a designer senses a misaligned baseline. That sense isn't mystical. It's pattern recognition trained by paying attention, the same muscle whether you're looking at a logo or a GraphQL schema.
Developer experience is where this lands hardest in my current work. On the DfT account, maintaining NaPTAN — a national public-transport dataset that's genuinely public, that real people and real services depend on — the audience for good design isn't only the end user. It's the next engineer, the contributor who's never seen the codebase, the consumer reading the schema cold. API design is interface design. A clean contract, a well-named field, a tested boundary, an error message that respects the reader — these are aesthetic decisions with technical consequences. When I push TDD, pairing, and desk-checks, I'm not enforcing process for its own sake; I'm defending legibility, the way I'd once defend whitespace on a page.
The throughline from designing a law firm's brand to architecting platforms is not a metaphor I reach for to sound interesting. It's the literal shape of how I work. I still have a keen eye for aesthetics, and I've stopped apologizing for it, because it turned out to be the most transferable engineering skill I own. Good design and good architecture are the same promise made twice: I thought about the person on the other side, and I cared what this is like to use.