Developing taste

Emil Kowalski opens Developing Taste with a car. When the first one appeared, nobody cared about its colour or silhouette, because the competition was a horse. Now that cars are commoditised, quality and details matter more than ever. Software, he argues, has reached the same point: shipping something that works is no longer a differentiator, “especially now with AI,” because people expect things to work. What makes a product stand out is the brand, the design, how intuitive it is, the whole experience. He borrows a line from Anu Atluru to put it in one sentence: “In a world of scarcity, we treasure tools. In a world of abundance, we treasure taste.”

So what is it? Emil’s definition is the one this chapter rests on. Taste is commonly mistaken for personal preference, but it is more than that: a trained instinct, “the ability to see beyond the obvious and recognize what elevates.” It is why some designs feel effortless. The word trained is doing the work in that sentence. If taste is trained, the real question is how to train it, and the rest of his essay is three answers.

The first is exposure. If you are a designer, look at great designs; if you are a writer, read great books. Expose yourself to great work and you learn how greatness looks and feels. He quotes Steve Jobs on trying “to expose yourself to the best things that humans have done” and then bring those things into what you are doing. The practical version, which Emil credits to Julie Zhuo’s On taste, part 3, is to find people who are respected in their field, look at who they admire, and build a curated list of tastemakers. Then surround yourself with their work: look at their designs, use their apps, read their books.

The second is analysis, and it comes with a rule: while calibrating your taste, do not label things good or bad. Instead of a gut reaction, rationalise why something feels great; analyse and understand patterns rather than relying purely on intuition. A designer should not just use apps but study them, asking why a specific interaction feels good. He points to Brian Lovin’s App Dissection as a model of this kind of study, and extends the habit past software: a filmmaker should not just watch movies but think about why the director made the choices they did. “Go beyond the surface level. Be curious.”

The third is practice. Create things: a designer should design, a writer should write. Doing so makes you “not only a good judge of taste, but also, with time, a tastemaker.” While practising, seek feedback, because good critique from the right person accelerates the process more than trial and error alone. And then the line that most people need to hear: the things you create probably will not be good at first, “but that’s a good sign.” Your taste is already good enough to tell that your work is not on par yet. That gap between what you can recognise and what you can make is the taste gap, and Emil’s footnote for it points to Ira Glass. The phase is normal. Do not quit.

Rauno Freiberg reaches the same place from the other direction. The closing thoughts of Invisible Details of Interaction Design admit that, for him, understanding and articulating why something feels right does not come as intuitively as designing it to feel right. But he calls them two sides of the same coin: “There must be a reason. It can be as simple as a particular spring curve or something more innate, like metaphors.” Analysing design details beyond “it feels nice,” he writes, helps nurture taste, amplify level of execution, and grow appreciation for how hard the pursuit of excellence is. Earlier in the essay he names recreating interfaces as one way to build intuition and the reflection itself as another. Emil’s second answer and Rauno’s closing thought are the same instruction: the why is not decoration on top of the work, it is how the work gets better.

Paco Coursey is useful here because he wrote about the gap from inside it. In Creative Output (2019) he says plainly that he is consistently unhappy with his creative output, that his title includes designer but he is not good at designing from scratch, and that everything he creates feels like a remix of his past work or the work of others. He then argues that anything new in design is old stuff reworked in new ways, and quotes Mark Dalgleish: developers who find design difficult are probably skipping the inspiration phase, which roughly translates to looking at other designs and taking the good ideas. Paco calls that a totally valid way to work, probably the most efficient, and still asks to what degree we can claim such work as our own. Two months later, in Good Writers, he is doing exactly what Emil prescribes for a different craft: noticing that some people write extremely well, pulling apart an opening sentence that glued him to an article, and concluding “I’m learning to recognize good writing.” His Write it down policy, every idea, every time, wherever it arrives, is the low-tech end of the same habit.

What to take into your own work is mostly scheduling. Keep a list of people whose work you trust and look at it on purpose, not when the algorithm shows you. When something feels good, stop and write one sentence about why before you move on; Paco’s rule about writing it down applies to observations as much as ideas. Make things and show them to someone whose critique you respect. And when the thing you made is worse than the thing you admired, read that as evidence that your judgement is ahead of your hands, which is the order you want.