Taste as Operational Judgment

What taste decides now

Taste used to be treated as the finishing pass. The designer with taste made the product feel right. The engineer with taste wrote code that did not need a comment. The PM with taste killed the wrong feature. It was real, but it often arrived after the product direction had already been set.

That is too late now. The screens can look fine. The code can compile. The roadmap can fill. The mistake can still be that the product is doing the wrong thing, or doing the right thing with the wrong amount of power.

Taste now has to arrive before the work hardens. It decides where the product should act, where it should slow down, and where it should refuse itself.

Taste in this world is not how the product looks. It is the operational shape of the calls the product is willing to make on the user's behalf. That is the part that decides what the product is, not how it dresses.

This is different from strategy. Strategy chooses the pattern of problems a product takes on over time. Taste makes the local product call inside that strategy: whether this particular behavior should exist, how much power it should have, and where the product should refuse itself.

The six questions

The cleanest way to make taste arguable is to turn it into questions you can answer about a specific decision.

Take a writing assistant that proposes to auto-send routine replies after drafting them.

The tasteful answer is not simply yes or no.

Automation may make sense for low-stakes acknowledgements. Anything public, emotional, legal, or relationship-heavy deserves friction first. The product has to show why the draft was classified as routine, and it has to hold back when confidence is low or the recipient is unusual.

The taste call sitting underneath the call sounds like this:

The auto-send feature itself may not deserve to exist if a better product would prepare the reply and leave the final act human.

That is taste as an operational artifact: not a vibe, but a set of conditions under which the product is allowed to act.

Does this deserve automation? Not "can this be automated" — almost everything can. The question is whether the automation makes the user's life better or only makes the product feel modern. Some work the user wants done for them; some work they want to do themselves and resent the system for taking. A tasteful product knows the difference and is willing to leave work in the user's hands when leaving it there is the right call.

Does this deserve friction? The default assumption is that friction is a defect — every reduction in steps is a win. That assumption is wrong wherever the user is about to do something irreversible, expensive, or out of character. A tasteful product slows the user down at the moment a slower decision is the better one, and gets out of the way the rest of the time.

Does this need visibility? A product that hides what it is doing is a product the user cannot trust; a product that surfaces every action is a product the user cannot use. Visibility is a budget. Tasteful products spend it on the actions that matter — what the system did on the user's behalf, what it is about to do, what it changed in the background — and stay quiet on the actions that do not.

Does this need restraint? The system that always answers, always acts, always finishes the sentence, is the system the user eventually stops trusting. Restraint is taste expressed as a refusal to take action when the system is not certain enough that the action is what the user wanted. Holding back is harder to ship than acting; it has no animation.

Does this simplify the user's work, or only move it? Many features marketed as simplifications are displacements — the work the system removed shows up later as a different kind of work. Configuration, correction, recovery, explanation. A tasteful product is honest with itself about whether the simplification was real or whether the user's job got harder somewhere out of view.

Should this exist at all? The question every roadmap evades. Every feature has a cost — to build, to maintain, to teach, to deprecate, to defend. Most products would be better with fewer features more carefully chosen than with more features less carefully chosen. The most tasteful answer is sometimes "no," and the team that cannot say it has lost taste before the build has started.

A worked deletion

Take a feature that should not have shipped, walked through the six questions in the order they want to be asked.

A team building a writing assistant ships a "Smart Reply" surface in the inbox. It detects a thread, drafts a one-line reply in the user's voice, and offers a button that sends the reply with one click. Adoption is high in the first month. Open rates on auto-replied threads are healthy. The team is preparing to make the reply send on a schedule if the user does not act on it within an hour, and to expand the surface to drafted long-form replies. The expansion is on the roadmap. The taste call sits underneath it.

Does this deserve automation? The user's hands are saved a small amount of typing on a thread the user could have answered in fifteen seconds. The work the system removed was not the work the user wanted removed. The user wanted the deeper email moved out of the queue, not the trivial one auto-sent. The automation is real, and it is in the wrong place. Honest answer: not at this confidence, not on this surface.

Does this deserve friction? The reply leaves the inbox in the user's name. The recipient cannot tell whether a person read the thread or whether a model classified it. If the model was wrong about tone, urgency, or context, the user finds out from the reply on the recipient's side, often hours later. The action is closer to "out of character" than "low-stakes." Honest answer: yes, it deserves friction.

Does this need visibility? When the system auto-sends, the only legible record is in the sent folder. The user has no banner, no draft history, no quick-undo, no clear marker on the thread that the reply was machine-generated. The product is telling the user nothing about what it did on their behalf until they go look. Honest answer: more visibility than the product is offering, and more than the surface can carry without becoming noisy.

Does this need restraint? The confidence model behind the reply is a recency heuristic, a sender check, and a length classifier. None of those distinguish a routine "sounds good" from a brittle relationship moment. The system is acting at the same posture across both. Honest answer: yes, restraint is missing, and the missing layer is in the model, not in the UI.

Does this simplify the user's work, or only move it? The user saves the typing. The user pays for the typing later, in inbox archaeology, awkward follow-ups, occasional damage control with the recipient, and a slow loss of trust in the inbox as a record of what they actually said. The system removed visible work and added invisible work. Honest answer: it moved the work.

Should this exist at all? No.

The deletion is not the easy decision it sounds like inside the chapter. The Smart Reply surface has month-on-month adoption growth. There is a launch announcement on the homepage. A senior leader has cited it in two all-hands meetings. The team has a roadmap item to expand it. None of that is the question. The question is whether the feature is the kind of thing a product the team wants to be associated with would ship.

The team kills the auto-send. They keep the draft suggestion as an explicit prompt, not an action. The release note describes what is no longer happening. The dashboard for the surface goes away. The next quarter's roadmap drops the expansion. Internally, the team writes the deletion note: "This was the wrong work to automate. The work the user wanted automated lives one layer deeper, in inbox triage, and we have not earned the right to act there yet either."

That note is the artifact. It is the chapter's six questions, answered honestly, on a real feature, ending in a deletion the dashboard would not have produced on its own.

Where taste actually shows up

If you go looking for taste in the part of the product that gets the screenshot, you will not find it. The hero shot is where teams spend their visible attention; almost every team gets it close enough to passable. Taste shows up in the parts of the product nobody photographs.

The empty state. What does the product say to a user who has nothing yet — no data, no context, no reason to come back tomorrow? The empty state is where the product reveals what it actually believes it is for. Most empty states are defensive. Tasteful empty states are confident; they make the absence of content useful, not embarrassing.

The default. What does the product do when the user has not chosen? Defaults are the most leveraged design decision in the product, because most users live inside them. A tasteful default is one that an honest product team chose on purpose, not the one that was fastest to ship.

The silent action. What does the system do without telling the user? Silent saves, silent retries, silent migrations, silent inferences. Each of these is a taste call about how much of the work the system is willing to take responsibility for, and whether the user will be told what happened.

The deferral. What does the product refuse to decide for the user, and how does it refuse it without making the refusal feel like a failure? The product that surfaces a decision honestly — "this one is yours; the system is not going to guess" — is the product the user trusts more, not less, because the line was drawn out loud.

The deletion. What did the team take out of the product on purpose? Deletions almost never get presented as features, but they are the part of the product the team had the most discipline to ship.

Taste as a discipline you can argue for

Taste calls feel hard to argue for because they sound like preferences. The work is to convert them into the operational language the rest of the team is already speaking — not by abandoning the call, but by making the call legible.

A taste call about restraint is, operationally, a confidence-threshold call: at what level of certainty is the system allowed to act without asking? A taste call about visibility is, operationally, a notification budget: how many times per session is the product willing to interrupt the user, and which actions are allowed to spend the budget? A taste call about whether something deserves to exist is, operationally, a roadmap-cut argument with a real cost-of-keeping number behind it.

Naming the call out loud is the discipline. The team that calls a confidence-threshold decision a "taste decision" makes the call sound subjective. The team that names the threshold gives the room something real to argue about — and the call itself, when it lands, will have been the same taste call all along.

The other half of the discipline is being the person willing to hold the call when it is unpopular. Taste in product is rarely the loud option. It often looks like the smaller feature, the slower default, or the deletion shipped. Those calls produce less to point at and more to defend. Teams that hold them earn taste as a track record, not as a vibe.

Most taste in product creation is invisible because it is exercised correctly: a feature that did not get built, a confirmation that got removed, a default that was set by someone who thought about it for an hour. The work of authoring a product whose calls are taken seriously is the work of making those invisible decisions on purpose, over and over, while the rest of the room is arguing about the visible ones.