Rachel Been: Designers are often labelled 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.”