Article summary
In an ideal world, the development team would build a component and pattern library around the designs identified by designers’ knowledge, industry standards, and research. Often, however, we see clients leverage Google’s Material Design, Bootstrap, or the like to expedite the process. There are often hidden costs to this route, which mainly surface as communication issues.
The biggest key to success with this approach is a clear and open line of communication between the design and development teams.
How Confusion Arises
Theme tooling has hidden implementation costs. Let’s use Material Design as a use case; there are two main characters in this story:
- The development team (using Angular and the Angular material theme)
- The design team (using Sketch and its material theme)
These groups are working together to implement new software. Each group’s tooling is different, even though both are based on Material Design principals. This is the root cause of much of the confusion.
Sketch’s material symbols and Angular’s material components don’t have the same number of components.
Designers often select from the symbols available to them without checking the availability of those same components in the developers’ library. The design team works under these expectations, and challenges arise during implementation.
Styling is often different for components.
For example, Sketch offers designers a choice from lists with one, two, or three lines of content, plus a slew of configurations for each content layout. Developers, on the other hand, are basically given a container in which to develop their own list items. They have significantly more flexibility, which is the opposite of what you want when looking to control the consistency of a user interface.
Deviations often occur in the layout.
Inexperienced implementors often have a challenging time with how components fit together to meet the Material standards. This gets compounded when you factor in using a grid to standardize spacing and responsiveness, then add in different surface colors, padding densities, and active or selected states. Your team has one big headache.
A Better Way
So how do we go about creating a more streamlined approach?
1. Train your team on how Material Design works.
Make sure they understand how the components should be laid on the page. Getting them familiar with the common patterns, as well as depth and elevation, will go a long way.
2. Make sure you’re on the same page.
Have a few heads-down sessions to make sure the design and development components and patterns are identical. Then identify how changes to the now-aligned components and patterns should take place. Don’t let the hard work you just did unravel when changes inevitably come.
3. Add transparency to your team’s tooling.
Tools like Sketch Cloud and Zeplin give the development team insight into the design team’s components and patterns. Storybook gives designers the same visibility into what the developers have to work with.
4. Make alignment a goal.
Now that transparency is there, create an atmosphere where the team’s aim is to align on patterns. Get the developers to point out issues or inconsistencies with their component library, and have designers do the same. This will ultimately lead to them owning their design system and aligning on process and language.
Like all tools, Material Design and Bootstraps can be incredibly useful if used properly. It’s essential to keep a close eye on component and pattern libraries throughout the project. This is hard work, but it pays dividends through fewer bugs, less technical and design debt, limited re-work, and more consistent interfaces for your users.