I did an interview with Rachel Been that posted over here. —JM
Rachel Been: Designers are often labeled as dreamers, and developers as pragmatists. What’s at the root of this shorthand?
John Maeda: I think the education system has created this dichotomy. While studying at MIT, I had the engineer’s problem of being able to build anything, but not knowing what to build. It was only after attending art school—and discovering what to build—that I could combine the two. It takes a developer who’s gone to the design side to appreciate what engineering can be, and it takes a designer who understands that the “religion” they were taught is slightly incorrect, because it was conceived when there weren’t high-end computational systems. If you think of designing a chair out of wood, that religion still works fine, because that’s something that creates a great chair. However, if you’re making something on the computer, that religion has to adapt and change.
RB: Does this new, updated “religion” follow a set philosophy?
JM: It does. First and foremost, understanding computation and how the medium works and behaves. Having more empathy for developers and how they came to be—because they don’t share this culture that’s so strong in design. And finally, including people on your team who come from the “other land” to create balance in the force.
RB: So this new philosophy calls for more collaboration between designers and developers, but what’s useful to remember in terms of how the two differ?
JM: In the same way that there’s all kinds of designers, there are only a few types of developers. There’s a broad range of developer methodologies, but they aren’t stuck in history. All variations of design are connected to an entity that’s been around for a few centuries, if not more. So a creative who comes from the traditional world—whether it’s a design thinker, typographer, or colorist—is going to cover more territory of imagination than what a modern developer might. But I caution that thought, because what really struck me about the Material Design team’s work was that you’re interweaving an array of design disciplines with development and not just approaching it from a single disciplinary angle. And I imagine that not everyone on your team understood the importance of these roles initially, especially if they’re classically trained. That’s an example of how the developer mindset has been augmented by the design mindset, and everyone’s winning.
RB: Yeah, and that adherence to thoroughness is really a benefit for the design system. This is a bit provocative, but do design systems ever inhibit creativity for design teams?
JM: It depends. There’s a kind of creativity rooted in unlimited scope and no constraints. And then there’s creativity within constraints. So, I would argue that design systems are able to push creativity within constraints, which improves quality. Whereas, on the other hand, if it’s wide open and dreamy, dreamy, dreamy all the time, you would end up with a million variations of things that don’t relate to anything.
RB: Is there a world where unlimited scope and constraints converge? And have you observed more success in one versus the other?
JM: Well, I think of the art world. I love that Material’s visual language is influenced by art. I like to think that artists make questions and designers solve problems. I think all digital product teams should be exposed to art. It sounds silly, but Monday, on my team, is called “st(art).” And Monday, st(art) day, I draw upon an artist and point everyone’s attention to that artist, so it’s like a 52-week calendar. This Monday was the artist Jenny Holzer and last week was the photographer Hiroshi Sugimoto. People ask, “Why do you do this? This isn’t useful.” And my point is that’s the point. When I had no constraints in the ’90s, I used to draw lines on everything I created and I made a square dance around when you talk to it. Why did I do that? I don’t really know, but it was interesting to explore. Whereas on the constraint side, I appreciate a great library. If you think of Apple versus Microsoft in the ’80s and early ’90s, the reason why Photoshop was so good was because it used the QuickDraw library in the Apple graphics toolkit, whereas DirectX—the Windows equivalent—wasn’t designed to support a Photoshop-like application. So good constraints make for great things to be made with it. Having fewer good constraints means Photoshop wouldn’t have been invented.
RB: Have you seen product strategy or design work that’s been inspired by st(art)?
JM: I don’t expect st(art) to immediately inspire strategy or design work. I’m a believer in the Lorenz butterfly effect—that a small shift in one area can result in a larger shift in another area—and that the butterfly wing will release a storm somewhere, at some point. Only because I see it happen, all the time. We’ve all experienced it, when an action or idea you voiced months ago catches up with you in another context and you’re like, “Oh, wait.”
RB: You worked within venture capital, where the methodology is to build teams that produce a good return on investment. What did you learn from the process of building teams with that end goal in mind?
JM: While working at Kleiner, I had the opportunity to advise over 100 startups at different stages of development. And the main value I added was communication between the CEO and the design team, because it’s such a different language. It’s not a business or developer language in many cases. I’d argue that return on investment (ROI) motivates an organization to move fast and reduce friction. And a creative team is a pain in the neck, because they’re professional divergers and they want to question things.
RB: You operate in both worlds—as a creative and a leader advocating for structure, clarity, organization, and consistency. How do you maintain that organizational clarity while fostering creativity?
JM: There’s a stereotype that creative people don’t make good leaders. They’re all the stereotypes you shared earlier: they’re imaginers, dreamers, non-executors. But we live in a time that needs extremely agile, creative people who can manage ambiguous situations and effectively collaborate in teams. Part of my work is pointing out that there are exceptional leaders who are hybrids—they are creative, they can speak Bauhausian and can understand the slide deck, but they can also speak about ROI.
RB: Speaking of teamwork, inclusivity in the workplace is a pressing and continual conversation, and you’ve said that “diversity is vital to a functioning team.” What exactly does that mean?
JM: The thing I love about getting involved in the dialogue around inclusion is that it forces you to learn things. Inclusion covers so many types of inclusion—gender, sexual preference, body type, age, ability, neuro-ability, economic diversity, etc. There’s so many things. I feel like every day I’ve failed at understanding what it means to work and think inclusively in products. So, just off the bat, it means you fail a lot, and it’s awesome. Because failure is learning.
Working inclusively is beneficial because it increases your total address of the market, or TAM. That’s a favorite acronym in venture capital circles, “What’s your TAM?” You can increase your TAM materially, if you work inclusively. When I first started working in Silicon Valley, my primary interest was in socioeconomic diversity, because I noticed that the companies were mostly populated by graduates from top colleges—which tend to be less diverse—and it made me wonder who else was missing. Now I only think of inclusivity from a business perspective, which opens me to criticism from people who feel that I should be advancing social justice concerns. But I’ve intentionally chosen to solely focus on the product impact—I want to know how to increase TAM. Since it continually raises the stakes for building better tools to support everyone.
RB: We’ve heard many things around specialization versus generalization for a successful design career. What do you think about that division and which one is more effective?
JM: If you’re in an early-stage startup, you don’t want a specialized person. It doesn’t make any sense. But if you’re in a late-stage startup or public company, you need an orchestra, because you need people that cover the entire range. When it comes to leaders who can lead the complex tasks in a technology company, you want people who are broadly skilled. But regardless of skill set, how you relate to other people is really important. There’s nothing more valuable than the people skill.
