Material Design Decisions
by Alicia Bergin and Ryan Gates — Method San Francisco
It’s amazing how many projects we’ve worked on lately where our partner has attempted to shore up their product development gaps by injecting the Google Material Design standards into their design process without fully considering the impact on the product or brand. Generally this decision is made because they don’t have a design team to complement their engineering team, or someone decided their design team needed a ready-made common set of components to work from.
While the choice to utilize Material is not a disastrous one, it should be an informed choice, and there are definitely some advantages and big disadvantages, depending on what you’re trying to achieve.
First: Material “Design” or Material “Code”?
When selecting Material Design, you’re opting to construct an experience based on an established design toolkit, with guidelines, principles, and assets. However, it’s not simply a visual approach. With it comes an inherent implementation structure in the form of a front-end component library which draws from that design toolkit. So we first ask, “Are you using Material as an accelerator of design or development? Or both?” It’s important to know that you’ll be investing in the adoption of a large set of conventions.
Good: Bootstrapping Product Development
Let’s assume you have a clear product vision, are comfortable with the look of Material, and want to move fast. There are a wide range of front-end libraries that are available to implement the Material Design standards. There’s the somewhat official Angular Material version, a more vanilla JavaScript Material Design Lite version, and a whole host of libraries by different groups, one being Material-UI, that say they offer the complete Material package.
The selection of an appropriate library shouldn’t be taken lightly. The styling and customization of components is sometimes more difficult than advertised, with inherent systems to either overwrite the style or configure before the components render (inline styles are not my preference for flexibility reasons). Also, very few of these libraries have a comprehensive set of components when compared to the design specifications put forth from the Mountain View Mothership. Recognize that the code libraries are growing somewhat organically in response to the expansion of Material Design, and you may need to close gaps in your own build.
Key issues to consider:
- Angular Material has certain built-in controls that allow customization (within Material color/style boundaries) at an individual component level, but broader customization is more difficult.
- Material Design Lite is easier to work with for relatively simple implementations, but requires a bit more markup to attach certain functionality and for better or worse does not rely on any particular JavaScript framework.
- Material-UI takes a different component-centric approach, injecting all the styles into the markup, which makes it good for quick setup but doesn’t allow easy customization and makes for messy markup.
- All three libraries are advancing independently and have different “complete” components. If a particular interaction is critical to your experience, confirm that the library you select has it.
Bad: Design Differentiation
While it’s acceptable to bootstrap your product this way in the beginning, utilizing the Material Design framework without understanding your need for brand differentiation will likely lead to extensive future rework — and at worst a dead-end for the product itself.
The Material Design standards are essentially an evolving collection of greatest UI hits from Google’s product development. There have been many very talented groups and individual contributors (including Method) that advocated for, and revved on, these components over the last few years. Because of this, Material Design is an excellent common palette for Google products to be built with and audited when you’re building your own standards. But do you want your product to be confused with a Google product?
If we’re talking about creating Android apps, the Material Design standards (akin to iOS conventions) has more value as a unifying agent within the operating system. In the browser, though (across mobile, tablet, and desktop sizes) there’s more room for unique expression of brand.
Recently, Google has even published the Material Awards to highlight some of the best implementation of the Material Design standards. While there’s no shame in having high-quality attention to implementation detail, if you cover up your logo and can’t tell which company or product you’re looking at, you may have a problem. Is your company or product goal to be generic? Most likely not. If you have a brand that you’re trying to grow into maturity, Material should only be a stop along the way. Letting it define your user experience is to have your brand fade into ubiquity. Great for user interface familiarity. Kiss of death for brand differentiation.
Desired: A Thoughtful Design Process
Lastly, for all its utility, Google Material Design components are high-quality ingredients for a website or product interface, but one can’t (well, shouldn’t) cook with all of these ingredients at the same time and expect the dish to come out tasty. As mentioned previously, the Material Design standards came from Google’s product development. Google has a huge portfolio of products (and associated interaction paradigms) that serve many needs. Just as they do, you should instead be asking “What’s the experience I am trying to lead the user through?” and “What information or action is appropriate for this component?”
Taking the time to understand how the common components you employ, whether Material Design or another standard, contribute to a purposeful interaction model for your user experience.
With this investment, you’ll be able to navigate the future growth and iteration of your product gracefully, avoiding patching together components that conflict with each other, even if they are provided in the same set of standards.
