The joy of being a Product Designer: at one company you are seen as an integral strategist and at another a pre-launch polish filter.
Alex Schleifer, Airbnb's VP of Design, touched on this lack of shared definitions in a recent post [1]:
Outside of design, some have knowledge of UI and UX, but, by and large, design doesn’t enjoy the same broad understanding as its product-oriented counterparts. Increasingly, there’s more of a grasp of brand and marketing design, but product design — and specifically interaction design — is not well-defined or understood. For a field that’s accountable for defining the experience of interactive digital products and platforms — products that are an increasingly big part of everyone’s daily lives — there should be more fluency outside the function. A broader understanding will help get design out of its echo chamber and into the greater narrative of a company-building.
I really agree with this. So in the interest of furthering the discussion at the industry level, I thought I would share how we define the role at Quora, as it's fairly unusual and, to me, exciting.
In the case of companies like Uber, Netflix, or Amazon there is a tangible product offering, and the user interface provides, well, an interface between the user and that offering. A central mantra for the designer on such a product is “don't make me think” — the interface should get out of the way of the offering as much as possible, and perhaps provide touches of “delight” along the way.
However, in a social network the “offering” is not a tangible good; it's the other users. The choices you make are not expressions of some underlying product, but mediations that govern how people interact with each other. In this context, the model of just “getting out of the way” doesn't make any sense. When you group people without boundaries, it’s pretty clear that you end up with abuse, trolling, low quality, relevance issues and more.
Consider the basic decision in a social product of who sees what you post:
These decisions are very distinct from each other and have massive implications for the user experience, heavily influencing how and why people use the product. At their best, the open nature of Twitter sparks revolutions and the private nature of Facebook fosters intimacy and safety. At their worst, Twitter's loose boundaries permit rampant abuse [2] and Facebook's cramped quarters produce an Endless Thanksgiving [3].
Additionally, these are not technical choices, in the sense that technology doesn't dictate which one to use. They are more like the rules of the product, conscious choices towards a desired behavioral end. This class of decisions is what our design team has termed mechanics design. Here's the official definition from our internal documentation:
Mechanics are the concepts and rules of a product as a user understands them. Namely:
The objects in the system, their attributes, and their relationships to other objects.
- Topics are applied to questions which have answers.
- Tweets show up in the timelines of the followers of the author.
The actions people can take, under which conditions, and their outcomes.
- When a user follows a topic, content from that topic will appear in their feed.
- If user A follows user B, user B can message user A, which triggers a push notification for user A.
The information users have access to, under which conditions.
- User A can see the topics user B follows on user B’s profile.
- A user can see who they have requested answers from, but they cannot see answer requests by other users.
In many companies, these decisions would fall under the realm of a functional spec or a requirements doc. I want to be clear that “mechanics” refers to a very specific subset of what might be specified in such a doc. For example, how Google search results are ranked has a major impact on the user experience and someone should define what that ranking should be trying to accomplish. But no matter how many ranking changes Google might make, the mechanics don't vary: keywords in, results out. So, mechanics design should be seen as a subset of all product decisions.
Along those lines, I believe that mechanics design is a distinct discipline separate from both interface design and product management. I believe it deserves its own terminology, principles, processes, deliverables, and bodies of knowledge. Our team has taken some stabs at what that might look like, which I will share in future posts. But we've gotten there not through the lens of interaction design but through adjacent disciplines such as game design, economics, and other social sciences (and a lot of our own experiments and mistakes).
To return to the original question: what is product design? At Quora, product design features mechanics design as a primary responsibility. This is in addition to interface design, a high technical bar (CSS, JS, Python, Git), and a fluency with metrics and testing. It is a broad and demanding role, and it is certainly not without its trade-offs. But it is holistic, autonomous, and principally concerned with behavioral outcomes over deliverables.
There's value in the external fluency that comes from standardized terms, but I also believe that roles and processes should be based on the problems a team is trying to solve. To that end, I believe our idiosyncratic approach is a better fit for Quora's challenges than a traditional UI design role. I don't believe this is the definition of “product design” that all companies should use, and perhaps our role should adopt a different title. But it took us a while to formulate the concept of mechanics design and it has provided valuable ways of solving problems, so I hope that over time this can become a meaningful contribution to how design fits into that “greater narrative of company-building” Schleifer describes.
I’ve since written a follow up post that examines the tough trade-offs inherent in Twitter’s mechanics.