Chameleon is the design system at GoTo. Even though Chameleon is not a product in the strict meaning of the word - it is a design system - we do treat it as a product. It is a collection of foundational (like colors, typography and other tokens) and complex components (like navigation bars and full views) elements that live in centralised and documented design files and also developed and available in code repositories.
I was working on the design system from the very start with another colleague. At the beginning it was just a library file of colors, typographic styles and a bunch of icons. Over the years it has evolved into a massive library that is used by pretty much every relevant product in all business units at GoTo. The Chameleon team now consists of 3 designers and 3 developers under a product owner.
My main responsibilities are the following:
- mobile components (both iOS and Android has their own library)
- illustrations
- iconography
- documentation resources (I created a blueprint template and a contribution guide that is used for all components)
I also work on our colors, typography and web components when needed.
Design
Our design resources live in Figma utilising the library feature - the product designers are using instances of the components we design and whenever there is a small update (like a fix or an icon change) or a major update (like a complete rebrand) their designs are automatically updated with the new version of whatever component they were using.
Tokens and theming
Since we have separate products with their own "product colors", we needed the design system to adopt to each endpoint. We are using "tokens" or variables to define certain properties - with the use of Figma's library swap we can use these to easily serve all needs. The same functionality helps us also to design for light and dark mode without duplicated effort.
Example: If we have a button that uses the product brand color, it is not hardcoded, but it is using a token ($brand-color-01). So if a designer for product "blue" is using the "product blue" library that we provided, this color will appear as their brand color (blue), but the same button will appear as red for a designers that is working with "product red". They can also switch their library to the dark mode library and all the colors will be switched to that - no need to provide two separate designs for development, since the developers are using the same tokens in their code.
Iconography and variants
We use variants for lots of purposes in our files, but the simplest example is the Iconography file. Every icon has a filled (active) and an outlined (inactive) version - these are paired as variants and one can be easily switched to another with a toggle.
Since we have more than a 1000 icons at this point we also added some alternative keyword in the icon's description so our consumers can easily find them. I have also changed the names to more generic ones with on of our updated (ex.: formerly there was a "commuter mode" icon that was used in our meeting experience, but it was changed to simply "car" - if a designers from a different product is searching for it, this is the most likely keyword they would put in).
Documentation
Every component is thoroughly documented before implementation... all the edge cases need to be explored and used tokens, dependencies and other details need to be properly defined. It is easy to miss one of these details, so I created a "Blueprint" template and a guide that helps our contributors to not miss anything.
An additional benefit of these blueprints is that it includes a section and guidance for accessibility and editorial requirements, which is often missed by designers who are not involved in those areas.
Development
Whenever we are updating our designs in the foundation files (colors, typography, iconography and other styles) a script is run and our repository is automatically updated without any coding needed. In the upcoming build of any product we have, the resources are fetched from the updated library and the live product is updated with the improvements.
With more complex instances we work as any other development team - we hand over the designs to our own developer team and they implement the changes or add the new component based on the documentation. Whatever we create is added in our repository and is available for anyone in the company to use.