We’re currently (Oct 2014, for people reading this in future) looking to hire for product design at GitHub, and in that context, someone recently asked me:

How do I accurately represent my experience with product design on paper?

It’s a great question, and I didn’t have an obvious answer to start with. After some thought though, I believe being great at product design boils down to one thing: taste.

At GitHub, taste one of the things we value the most in people, whether they’re designers or engineers or anything else. We care deeply about this, because in addition to taste being critical to product design, taste is also what defines the culture within your organisation. Culture is collective taste, but that’s something for another blog post…

It’s not important to us that people have taste that agrees with other people at the company—in fact it’s the opposite, we’d far rather bring new and diverse perspectives into the company. What’s most important is that people are able to both recognise and communicate the quality (or lack thereof) they see in things. That’s what I believe taste is at the end of the day—the ability to perceive and articulate quality.

The problem with taste is that it’s subjective. You can’t prove definitively that taste is something you possess, in the same way you might convey other more concrete things in a resumé. In terms of the original question, I’m not sure there is a way to show on paper that you’re a good product designer.

The only option I see is to lay your cards on the table for people as best you can, and let the context you present collectively show that you have the right kind of taste.

It’s not enough to just say you worked on with client W on project X, or worked closely with group Y on building a whiz-bang new Z. You have to dig deeper so people can appreciate why the things you built and shipped worked out he way they did. Help people understand the factors you took into account when making choices. Explain the intricacies involved in the tricky bits. Share the decisions you’ve made, big or small. Tell people why you made those specific decisions, or reached those specific conclusions instead of the available alternatives. Show the end result too, and talk through what you’d do differently next time. And then ultimately, you have to sit back and let people judge for themselves (using their own taste!) whether or not they feel comfortable saying “yes, this person has good taste for product design”. The last step is to let go.

Sure, there’s more to being a product designer at GitHub than just some arbitrary definition of having taste. You have to write well. You have to be able to empathise with people who are radically different from yourself. You have to habitually question your assumptions, and admit when you’re wrong. You have to be able to deliver and receive feedback maturely. You have to be able to code your designs as well as defining the visuals and interactions between states. You have to be able to ship your ideas instead of just talking about them, and so on and so forth.

Without taste though, all those qualities lose their value.