Everyone’s talking about taste. Almost nobody writes it down.
5 min read
“Taste” has become the word of the year in product.
AI made building a screen cheap, so the expensive part moved to the decision before it: which screen should exist at all.
But most of the talk stops at admiring it. The practical question rarely gets asked: how does taste survive past the person who has it?
The problem with software like ours#
At Artifact we build software for accounting firms. A firm runs dozens or hundreds of clients, each with their own books, deadlines, documents and people to chase.
Software like this tends to be built around its own objects: a page per record type, a module per capability. When that structure leaks, the user ends up rebuilding their job by visiting the right pages in the right order. We learned that as our product grew.
One decision, start to finish#
Every month, an accounting firm closes the books for each client: reconcile, chase what’s missing, review, sign off.
In the earlier version of our product, close was split in two. The templates lived in firm settings, because they’re firm-wide. The checklists lived inside each client, because they belong to a client. Each placement made sense for the product we had then.
Then try describing what running a close looks like: “settings, then Client A, then Client B, then back to settings”. That’s a route through our navigation. And a controller asking the one question that matters, which clients will miss the deadline?, had nowhere to stand to see it.
That became a test we now run on every flow: if the navigation changed tomorrow, would this workflow still make sense? As close grew, it stopped passing.
The fix came from asking a different question. Not “how important is this?” but “what’s the unit of work?”
- Meaningless without a client selected? It lives inside the client.
- Firm-wide configuration you set once? Firm settings.
- Acts across the whole client roster in one sitting? It gets its own place.
Close is the third kind. It became its own workspace, and “which client” became a filter inside it instead of a reason to leave. An accountant who works inside one client all month still gets a link straight into that client’s slice of it.
Navigation follows context. Workflow crosses contexts.
What close taught us#
The fix holds a few more calls we now make everywhere:
- A number belongs where someone can act on it. The deadline view lives in close, because that’s where you fix it.
- Two pages shouldn’t answer the same question. That’s why the client page only links into close.
- A page has to earn its place. If a list already answers the question, a summary page on top is just the navigation drawn as cards.
The same instincts work at the scale of a panel or a button.
“Ask what it’s about, not how big it is.” Something about the user, like a chat, follows them everywhere. Something about one selected record closes when they leave the page. It’s the unit-of-work question, one level down.
“A page has to earn its place” becomes “a value has to earn its place”. Every colour, space and size comes from a design token. A one-off value is the frontend version of a page nobody asked for.
“Don’t make the user reconstruct the workflow” becomes “don’t make the next person reconstruct the state”. Interface states should be explicit, not hidden inside styling conditions. The same clarity we expect from a workflow should exist in the code that implements it.
The same judgement reaches what nobody sees. A data model decides which questions the product can answer: had the data behind close stayed split like its screens, no layout could show which clients would miss the deadline. How a system fails is a product decision too. An expired connection should reach the user as something to fix, not “something went wrong”.
Product, design, frontend and backend share one way of thinking, applied at different distances.
None of it is new. Jakob Nielsen wrote in 2006 that “the very fact that something appears on the initial display tells users that it’s important”. 2006. Before the iPhone.1. The iPhone was announced in January 2007, about five weeks after Nielsen published that article. And every product, ours included, still ships pages that exist because someone asked for them.
We don’t lack the principles. We keep losing them.
Where the taste lives#
Keeping them starts with choosing what to write down. When we rebuilt close, the new structure mattered less than the question behind it. “What’s the unit of work?” is written down now, with close as its worked example.
Every call above is written that way: as a judgement, not a rule. A rule gets ignored the first time it doesn’t fit. A judgement still works on a case nobody imagined, because it carries the reasoning.
The hard part is getting it in front of whoever is deciding, at the moment they decide. That matters more now that much of our code is written with AI agents. An agent has no taste of its own. Left alone, it follows the structure instead of the work.
So the taste lives in four layers, each stricter than the last:
- A one-page summary everyone reads. Every agent at the start of every session, every new person on day one. Each line is a decision and a pointer to why.
- Skills, one per kind of judgement: product and workflow, design system, domain. Plain markdown in the repo, versioned like code, so changing our taste is a pull request someone can argue with.
- Guardrails at the moment of decision. Before an agent creates something new, it’s shown what already exists. And settled rules, like the token and state rules above, fail the build.
- An audit for what tooling can’t catch. Is this in the right place? Does this screen need to exist? It reports drift and leaves the fix to a person.
Judgement stays in prose, where it can carry nuance. Only what’s settled becomes a rule a machine enforces.
So, how does taste survive?#
Not on its own. The decisions that shape a product are made by different people at different times. A data model, a panel, a page: each one decided by someone who wasn’t in the room for the last.
What connects them isn’t a shared set of rules. It’s a shared understanding of why those decisions were made.
That’s what we’re building at Artifact: a way for product, design and engineering to carry that reasoning forward, so every person and every AI agent builds on what the team has already learned.
Good taste starts with judgement. Great products make that judgement transferable.
Thoughts? Let’s talk on LinkedIn.