🚧 This mini project case study is currently being written, please request more information directly about this project.
Design Tokens
A deep dive into how we structured the design token schema and implemented within the Chameleon design system.
Role
Design System Designer and Design System Lead
Team
2 Designers, 4+ Developers
Design tokens requirements
. . .
Abstraction
Our token structure needed abstraction ranging from “generic”/”broadly applied” to “specific”/”specifically applied”.
Brand must be customizable
Design tokens need to be redefined for different brands and influence at scale.
Design intent must be captured
Design tokens need to capture design intent and be easily understood cross disciplines.
Design tokens must be flexible cross platform
Consistency in design intent and alignment must be supported cross platform, Android and iOS
Early design system tokens were close
Conceptually, what we found in the initial approach was really close to what could flexible in implementation.
The team had captured the idea of collecting a scale of color as reference tokens that informed early semantic tokens based on Material Design.
Requirements for
design tokens
Abstraction
Our token structure needed abstraction ranging from “generic”/”broadly applied” to “specific”/”specifically applied”.
Brand must be customizable
Design tokens need to be redefined for different brands and influence at scale
Design intent must be captured
Design tokens need to capture design intent and be easily understood
Design tokens must be flexible cross platform
Consistency in design intent and alignment must be supported cross platform, Android and iOS
Early design token exploration + workshops
We drew inspiration from Nathan Curtis’s article where he shared his approach establishing hierarchy within design token schema by utilizing levels.
