Material Components / Kunal Patel Q&A

John Maeda: So there’s a lot of life-size things here in this exhibition. How does that feel for you overall as more of a screen-based designer?

Kunal Patel: Scale as a method for creating emphasis. Right? It’s interesting to see what blowing something up to a larger-than-life scale does to make you pay attention to the building blocks of an application that most of the time we don’t think about.

JM: What components are on display here? And why are components important?

KP: The components on display here are some of the most commonly used elements of applications. So things like text fields for input or navigation drawer tabs to help people get around an application. Or lists and cards to display content for all the things you would encounter in most of the applications you use.

As for why components are important, it’s because as the fundamental building blocks of applications, we don’t want to put users in a position where they’re constantly relearning how to use the things they’re going to interact with every day. We want there to be standards for ease-of-use and for consistency across applications. They speed up user understanding and make the unique elements of your app stand out even further

JM: A developer might find a component and realize it doesn’t do everything that they need. So their immediate action will be to make a new one. True or false?

KP: Part of being a developer, I think, is wanting to tinker to be creative. We can easily fall in love with our own solutions in search of other problems. So instead, what we have tried to do with our code is make it open source, so that for the people who want to extend or remix components for their needs, we make that process easier for them. And we try to offer actionable design guidelines when they end up extending a component so they know what kinds of things to avoid.

JM: So it sounds like instead of your looking for the perfect set of components for every possible case, you’re totally open to people taking what you have and changing. That breaks the stereotype of a “control-my-system” approach designer. What’s that about?

KP: I think solving every possible case, even for a single large company, is impossible. It’s a bit Sisyphean to attempt to do that. So what we strive for instead is having a really clear set of guidelines and principles for how we intend components to be used. And we try to set appropriate guardrails for modifications while allowing for customization of visual style or extending the functionality to meet the needs of particular applications.

JM: Sorry to push further on this point, but I imagine that the design of these components has been extremely well thought out and researched and covers maybe 80% of the possible use cases. When people deviate from shopping that could be used, how do you feel?

KP: Personally I am all for deviations to come into existence for the right reasons. For example, if there is a certain type of brand expression that’s not coming across from the baseline component we provide. If a deviation does not interfere with the usability of said component, I am all for the customization. But we don’t want to see just different for different sake in a way that ultimately negatively impacts the user’s experience.

JM: Sometimes I see both designers and developers wanting to do “different for different sake” because that’s a kind of expression of creativity. What’s your recommendation as someone who has probably seen this happen time and time again?

KP: I think what we consistently fail to underestimate when doing “different for different sake” is the cost of then maintaining the difference. We have limited time, you know. Designers, developers, and product teams don’t want to be maintaining a difference in a button or a tab that’s not providing real functional value to a user. It would be much better to maintain that difference for a key custom feature of an application. So to me, that really comes down to a prioritization of your own team’s time and resources. Is it really time well spent rethinking a text field or rethinking a checkbox? Or is it better to spend time rethinking your checkout flow instead?