Spark Design System

Multi-platform, multi-brand design system, Canada

It was very clear upon joining the ecobee team that they could benefit from a design system. Partnering with another newly joined design leader, we set out to make it happen however our challenge had more detail—it would be a multi-brand Design System with ecobee being acquired by Generac. At first, there was no support from the rest of the organization, we earned it all from the ground up. A few months later and we were already part of Product Goals and OKRs at the highest levels.

My involvement was as follows:

  • Founder/advocate
  • Established token management and production strategy with engineers
  • Partnered with core members in establishing all processes across Design System including the component contribution, developer communcation and workshop strategies
  • Component contribution including management and review
  • Mentored cross-functional teams on adopting the system 
  • Contributed back to the system by recurring revision of our processes 
  • Maintenance and management of design system (since key members left)
aaaGenerac-Ecobee

Partnering with brand was a key aspect in establishing foundational elements for our Design System. This involved understanding all needs from creative teams across Generac, not just ecobee. The result was four brands that needed to be supported in total. Generac's PWRview app, Fleet management web app, MobileLink app and ecobee apps. Across all, we would need to support mobile iOS, Android, web and desktop web. 

File Structure

For the system set up, it was decided that we would have a foundational Figma file, named Spark Core. That would be feed agnostically into any brand's file that we needed to support. We tested this set up so it could adhere to any number of brands we threw at it. As a brand decision, we boiled it down to two: ecobee and Generac (at the time, Generac's overall branding would satisfy all platforms other than ecobee).

engineering

Engineering partnership, with any Design System is key. Establishing a proper Design System-based relationship with them requires more than just showing and directing them on what to build. It's setting up a way of working that provides the most valuable, accurate outcome and the least amount of friction. In this case, engineers were partners in setting up a token system through Figma and Supernova that worked for them.

As a short summary, designers managed tokens through Figma variables -> they then would pass these variables through to the token management system in Supernova (a web-based Design System management tool). We then set up exporters that allowed these tokens to be output for each different platform.

On top of that, engineers take part in all our design reviews; not only to give feedback but to gain a valuable preview of what they will be building out. This helps us anticipate any platform limitations or concerns immediately. Components then get built like clockwork because the Lego pieces are well-defined. 

All of these processes were and continue to be regularly reviewed with our respective engineering leaders from each different platform and business unit. 

DS-Workshop

For our designers, a lot of care and attention was paid to adoption, and ensuring they had a say in design direction. This manifested in the form of multiple audits, workshops, conversations and working Figma files shared over what we felt was the right fit.

Multiple audits were done on all apps across Generac/ecobee brands by the entire function of designers as opposed to just the Design System key members doing it.

ccp

As a mandatory step of the component contribution process, stress tests were ran intentionally with varying members of design in order to get unbiased results. The purpose of the stress tests were to use the components in a closer-to-real setting where designers could test them out and provide feedback.

Additionally, we moved towards a community contribution model to align more with our business goals (we needed to accelerate). This meant more training and assistance on the process we had established. 

DS-Documentation

With this project, I gained a lot of experience setting up communication to the rest of the product organization. Regular announcements in Slack channels, town halls, relevant shout-outs during related topics/meetings. This also included regular dedicated Design System syncs with product, design and engineering teams to ensure they are part of the process.  

DS-Requests

For maintenance and growth, I helped establish and review a Design System Request process and board through Jira for anyone on our product team to make Design System requests. This was used as a single hub to tackle any and all feedback for Design System. I was the key member responsible for managing all requests with core Design System team members and provided decision-making strategies (e.g. accept/reject requests) and design direction.    

accept-reject

Overall, Spark Design System measurable impact has shown through both design and engineering improved work efficiency as well as a large amount of code reduction. 

If you want to learn more about all the efforts that went in to my work with Spark Design System, feel free to contact me.

Connect with me.

Based in Toronto, Canada
phone (or text) me: 647 621 5520
email me: cheungydesign@gmail.com

© Cheungy Design 2021