Johnson Controls, an HVAC company, offers a suite of software products to manage buildings. Despite the software being generated by the same organization and many of the software tools being used by the same customers, their look and feel varied drastically. As a result, users had to relearn how to interact with Johnson Controls’ tools with every new application.
For this project, I acted as a designer and lead UX writer.
The problem to solve: Unifying the Johnson Controls suite of products through a visual language and component library.
To kick off this effort, we looked at some of the top design systems in the field right now, including Material (Google), Carbon (IBM), and Fluent (Microsoft) to determine which might be the most useful as a framework for our design system.
Additionally, we had an existing internal design system for the design side only which had been made ten years prior and had not been updated since. However, it held a lot of useful documentation on how to design for the large applications that Johnson Controls makes.
We decided to use Material Design as the framework for our system as it is familiar to most people and they offer libraries for a variety of tools that can be easily downloaded and edited. At the time of the project, our team was making a transition to Adobe XD for the entire design team, so we were able to easily build off the Material library for Adobe XD.
The biggest challenge we faced when designing the assets, was the fact that Material design is mobile-first and offers very simplified layouts. Most of the Johnson Controls software presents dense data and a large dashboard of information to help users make decisions. Due to this, most of the changes deviating from the standard Material toolkit were done to accommodate the high-content nature of the applications.
One example of this disconnect is wizards. Many Johnson Controls products use wizards for setup and adding new equipment. Since Material design is structured more for simple uses, there is no wizard pattern for cards.
When speaking with product owners and development teams, the number one reason cited that they did not use the current design system was that it slowed them down to have to consult the design system for every decision when not working with the UX team. Therefore, they chose to ignore it to keep things moving.
To house the design system, we created an internal Sharepoint site for the component documentation and to house the links for the libraries. It was my responsibility to create the SharePoint site and generate the documentation for all of the images. I developed a template for the documentation and designated component requirements based on Material’s framework as well as considerations for our tools.
The complete rollout of this project is still in the works, but it has been adopted by two development teams who are currently using it to build out applications. Feedback from their experiences will be added as they continue through the process.
An internal team of designers, including myself, has been identified to manage the upkeep of the design system and make changes. There is a form on the SharePoint site to submit requests for edits or additions. It is our hope that putting an action-oriented plan in place will ensure the continuous use and upkeep of this design system iteration.