Making/Doing

I’ve come across some enlightening information from David Cole, lead designer at Quora.
My key takeaways from his article are:

  1. Design is an agglomeration of skill sets that facilitates the building and production of something that changes the world. These skill sets change over time. New ones are added, old ones are deprecated, just like life. Graphic design is an agglomeration of skills in typography, color theory, layout, visual hierarchy, etc. Industrial design is an agglomeration of skills in ergonomics, usability, aesthetics and more. These fields used to be quite hands on (some still are) and heavily relied on paper, wood, foam and other materials. Designers drafted with 4H pencils and metal rulers on large sheets of papers, quickly sketched out ideas with charcoal and later on markers. They modeled with wood, metal, foam and textile.
  2. Then the medium shifted to digital, pretty thoroughly on most fronts. Photoshop, Illustrator, SolidWorks, CAD, AfterEffects have become the de facto tools of design. With the emergence of the web, mobile, and ubiquitous inter-connectivity, a new Product Design medium is born.  Graphic and visual design skill sets and tools no longer suffice the new medium of digital product and experience design. “The medium is the message.” How can a designer conceive of great user experiences without being well versed in the languages of this digital medium,  in which these novel experiences take place? Producing static images of what your design that are supposed to convey the flow of experience, simply does not work. When you have to ask people to imagine an interaction,  you are not doing the job right. We as designers, cannot be married to the media / tools we work with. If one wants to produce great work that changes the world, then one must be well versed in the language of today’s world.
  3. Design that doesn’t get implemented is not real design.  When a mock is not implement, it stay as a mock. It does not become design — it has not been tested, it is not real. Design is simply not producing a mock and giving it to someone else to make. Design is iterative and cyclical in terms of its relationship with production/implementation. “Implementation reveals gap in design”. It is through implementation that poor assumptions are observed and hidden conditions are exposed. Only after going through this process can a mock be validated and then it starts to become design. So the key is that the feedback loop has to be there to for design to take place. When design and implementation are closely so integrated, to the extent that feedback loop closes itself, it becomes one momentous act of simply making/doing. Such a condition can produce great work. This is why it’s best that designers need to know enough code to allow that closely integrated feedback loop to happen.
  4. A design oriented business needs to enable such a condition to exist. Systems and tools unique to the business needs to be put in place to truly elevate the level of iteration and speed up the process of making & doing.

My thoughts for now. I may have more to add for #4.

The full article from David Cole is below.

The Myth of the Myth of the Unicorn Designer

David Cole

In his article, Why Can’t Startups Find Designers?Sacha Greifwrites:

If you’re looking for a designer who can come up with your identity, design your site, create UIs with great user experience for your web and mobile apps, and on top of that code his or her work in HTML/CSS (and why not throw in Javascript in the mix!), then I’m sorry to inform you that you’re hunting unicorns.

The “unicorn” label is not Sacha’s creation, but this quote neatly summarizes a pervasive meme in our industry: designers who excel at many skills are so rare that they might as well be mythical. The argument goes that designers must pick between being great at one thing or mediocre at many things.

This is wrong. You can observe many talented people who stand as counter examples: Shaun InmanKyle Neath, and Justin Ouellette are some of my favorites. More problematically, this argument is the result of numerous bad ideas about learning, definition, and process. Being a long-time generalist designer myself, I feel passionately that this myth is holding back our field and deserves to be debunked.

Learning isn’t a zero-sum activity.

These skills are not mutually exclusive. Picking up Python won’t make you forget how to kern. We all have many years ahead of us in our careers, and they can be used to learn anything.

The central counter-argument here is that any learning comes with opportunity cost. Learning Python might very well take up time that you would otherwise use for studying, say, product management. This is true, in theory. But in practice, most designers I know, including myself prior to joining Quora, arenot learning at their maximum rate. I have spent much of my career solving the same design problems over and over again with no substantive personal growth to show for it. I don’t think my situation is unique.

But even if you were learning at your maximum rate, the opportunity cost argument actually works in favor of the multi-disciplinary approach. Design and its component practices are like any other craft: you can always develop a deeper familiarity with the minutiae, asymptotically approaching mastery. But this is a process with diminishing returns. Would you rather carve a door 1% better than you did last year, or learn how to build the rest of the house in the same amount of time? As I argue below, the connective tissue between these skills may actually be more valuable than incremental gains in a single practice.

And keep in mind, this is more an issue of prioritization — what do you want to learn right now — than one of long-term skill development. You have the rest of your life to carve a better door.

Design is already not a single skill.

The notion that you can’t be good at more than one practice is silly because most practices are themselves comprised of more granular skill sets. Typography teaches you about kerning, font pairing, and legibility. But typography itself is just one component of what we call graphic design, which is the unified application of many additional skills like color theory, layout design, and so on. We may call them different things, but that’s an abstraction to aid study and discussion. Their utility, and our primary concern, is in their function as part of a holistic system, where they work together to achieve an outcome. This never stops being true, no matter how far up the chain you go.

A unified process fosters better work.

If you accept the holistic view, then you have to accept that design itself is just a piece of a larger effort, which is to build something that changes the world. Design work that never gets built is not real; you cannot truly separate design from implementation.

The product development process, then, must be built to ensure this holistic perspective is not lost. The best implementation reflects the designer’s intent, and the best design reflects the product’s goals. There’s a through-line that binds every step: the product needs to reflect a single vision, a consistent explanation (about human behavior, about the technology) for why it will succeed. The preservation of that through-line can be more important than any individual step, as a mis-aligned product competes with itself before it competes with the market.

I think this dynamic is why single developer products (think:InstapaperPinboard, etc.) can often be so successful despite their inherent constraints: fewer chances for misalignment. It’s just easier to align a small team than a large one, especially when the designer shares the same technical language as the engineer from working in the same codebase. It’s also easier for one person to harmonize aspects of a product when they can accurately reason about trade-offs between the various moving parts of the system.

The other implication of this perspective is the admission that this process is not inherently linear. Taken as an interwoven system, design and implementation can and should push on each other in equal measure. Implementation often reveals gaps in the design: undocumented states and conditions, bad assumptions about usage, and other realities hard to predict when locked in Photoshop. The designer who implements their own work experiences these feedback loops directly, and can incorporate the appropriate changes in their final context.

You don’t have to be great at everything to create great work.

The aim of developing your skills is not actually to have moreskill per-se. We learn in order to make, and its the quality of our output that is the ultimate measure of our efforts. These concepts are tightly related, but there are systems for producing stronger work independent of skill.

When people hear “designers should learn to code” they often take it to mean that designers should be as talented an engineer as someone who does it full-time. Thanks to technical advances, this is decreasingly the case. Here at Quora, we have a sophisticated infrastructure that empowers designers to build complex features with a rudimentary knowledge of programming (relative to an engineer). I wrote about this more extensively in my post, Designers Will Code. This is not unique to our culture here, GitHub’s Kyle Neath has also talked aboutthis phenomenon. This is currently overlooked because these systems haven’t become common-place, but that’s a chicken-and-egg process: investment in creating these tools is justified only if you actually have a generalist team.

Another example: one problem with discussing this topic in a theoretical light is that designers don’t actually work in a vacuum of their individual skill. As a member of a larger organization, your individual variation in skill is less important than the aggregate expertise of the team. I’m not the strongest programmer on our design team, but my peers can help me make informed decisions. Everyone on our team draws on the skills of everyone else, and the final work will be stronger than any individual would’ve been capable of. This may sound like specialization but it’s fundamentally different. The expectation is that every individual is growing towards independence, not developing dependencies. This is not abstract: by becoming a better programmer I have concretely absorbed the tasks that what would typically define a discrete role (front-end engineer) at most other companies.


It’s curious that designers are so eager to place limitations on their potential, but I’ve experienced those feelings first hand. Prior to joining Quora, I did not have a good reason to believe I could ever be a productive programmer. All of my attempts to learn in evenings and weekends were not particularly fruitful. But when placed in an environment where I’m both expected and empowered to develop these skills, I have indeed been able to. Perhaps it’s not for everyone, but I’m positive that the number of designers who would thrive in a generalist — a.k.a. multi-disciplinary a.k.a. holistic — design role is far greater than the number of designers who are actually encouraged to try. To my fellow jacks-of-all-trades: don’t give up.

I suspect I haven’t considered every angle of this, so I’m eager to get feedback on this post. You can reach me in the comments below or on Twitter.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s