🧵 Here’s the tea on Design Tokens for Twitter’s new Visual Design Language. Specifically, the learnings that I gained working on Android, iOS, and Web for the Revenue, Marketing, and Consumer design systems.
(1/7)
🎨 Colors
I tried generating these using ColorBox, but adjusting the contrast ratio for accessibility and getting clean shades was near impossible. We ended up using a handpicked spectrum. Also naming `Blue100`or `Blue50` is far more useful than `FaintBlue`or `FadedBlue`
(2/7)
🔤 Typography
iOS and Android have predefined ratios for Font-size:Line-height. So instead of overwriting each instance, we specify a few cases where both Line-height and Font-size are respected. For the rest, only Font-size. IMO, fighting the OS is a losing battle.
(3/7)
🤏 Spaces, BorderRadii, and BorderWidths
I’d advise using numbers in your naming. It’ll save your team time in development. You will get push back about maintainability, but realistically, we changed these values only one time in 5 years. Hot take: `none: 0` is useful.
(4/7)
🐛 Types, feature-switches, and experiments
For Web, use Flow or Typescript. It’ll save you a lot of time. For iOS & Android, since the release cutoffs are biweekly, I try to feature-switch my changes when convenient. Otherwise, maximize the testing time on internal builds.
(5/7)
📣 Stages for Pull Requests
1. Introduce the new variables.
2. Switch over to the new names and values.
3. Deprecate the old names and values.
I make sure to communicate with the on-call engineers to ensure that they know these changes are coming before merging.
(6/7)
😌
I sleep better at night knowing that the design systems and production apps share the same tokens. The same language across Android, iOS, and Web. Check out this splendid thread by @ashlie to understand the principles behind our Designs.
(7/7)