Schema by Figma 2022の備忘録
Nov 3, 2022
昨日は Schema by Figma という Figma が開催するデザインシステムのイベントに参加してきました。
その中で Figma の VP of Product である Sho Kuwamoto 氏によるオープニング・キーノートが特に印象に残ったので備忘録を残しておきます。
（聞きながらリアルタイムに同時通訳をメモしていたため、もしかすると引用が微妙に間違っている可能性があります...ご容赦ください...）
Figma はこれまでフリーフォームなデザインと構造的なデザインをどちらもカバーすることを重要視してきたとのこと。
現在はデザインシステムが成長し進化するにつれ、その複雑さもどんどん増してきています。
その複雑化をレイアウトの複雑化、テーマの複雑化、プロセスの複雑化という 3 つのセクションにわけて説明されていました。
レイアウトの複雑化
デザインシステムで扱うレイアウトはアプリケーションの要件によってどんどん複雑化している。複雑なコンポーネントの例として、Card コンポーネントが挙げられる。 Card コンポーネントは中身のレイアウトが複数存在し、管理が非常に難しいので Nesting components を使う。
このあたりはまさに Card コンポーネントを例に、EightShapes の Nathan Curtis 氏が 「Subcomponents. Relinquish control, offer parts, and…」という記事で詳しく解説しているのを自分はよく参考にしています。
テーマの複雑化
複数ブランドにライトモードやダークモードなど、様々なテーマが求められるようになり、複雑化している。 その解決方法としては「Headless design system」が挙げられる。
Headless design system とはあらゆるテーマで使える"ヘッドレス"なデザインシステムを設計し、デザイントークンを置き換えることで、様々なテーマを一つのデザインシステムでまかなえるようにしたものです。
これは Figma tokens のコミッターでもある Esther Cheran 氏が「Building a headless design system」の動画の中で説明している内容が参考になりそうです。
また、このトピックに関しては自分も前回の Config by Figma のセッションの「One design system for multiple brands」で話させていただきました。
前職の GMO ペパボ株式会社の共通基盤デザインシステム Inhouse のコンポーネントを設計するにあたって、まさにこの「Headless design system」にかなり影響を受けていて、現職の家計簿プリカ B/43 を運営する株式会社スマートバンクにおいても現在、いくつかのクレジットカードのテーマや Brightness に対応できる Headless なデザインシステムを設計しています。
プロセスの複雑化
チームメンバーの増加に伴い、他の人が何をしているかわからなくなっていく複雑化がある。デザインシステムの更新は多くても月に 1 度程度だろうと考えていたが、実際に調査してみると平均して日に 1、2 回もの変更が加えられていることがわかった。
この問題に関してはドキュメンテーション、ブランチとマージや、コードの世界でいうテストコードのような VRT（Visual Regression Test）を整備して解決していく方法がよく用いられているとのこと。
VRT に関しては、Storybook で Chromatic を用いたものは自分もよく活用していますが、Figma のコンポーネントにおいても簡単にできると確かに便利そう。
Figma のブランチとマージをまだ本番運用したことがないのであまり詳しくないのですが、GitHubのオニオンスキンのような形で比較できるようです。
まとめ
Figma のツイートより引用
現在のデザインシステムにおいては、これまで説明したように複雑なレイアウトのコンポジション、Headless design system、分岐とマージ、テストドリブンデザインなどコードの世界の考え方を参考にした手法が多い。
このような考え方がコードの世界から来ているのは偶然ではなく、デザインシステムはより複雑な世界に進んでいるため、コードからのアイデアを借りている。
しかしコードの考え方を借りることで、デザインが型にはまってしまう。デザイナーを型にはめたくない、柔軟性を失わせたくない。
冒頭で説明したように Figma はフリーフォームなデザインと構造的なデザインをどちらも大切にしたい。
このような複雑性に対応するためには問いのフレーミングが重要。
間違いをしないようにデザインしようというのが昔は主流だったが、現在はデザインシステムがあるから間違えることはなくなった。ミスを避けるというのはクリエイティビティを制約する。デザインシステムを摩擦を減らすものと捉えている。
このような構造化されたデザインへの捉え方は自分もすごく同意していて、クリエイティビティを発揮するために、考えなくても良い摩擦を減らす、そして、もっと本質的なデザインに集中するためにデザインシステムを作っているよなぁと日々感じています。
また、エンジニアリングの世界を参考にした手法が多いというのは本当にそうで、デザインシステムを作る上でエンジニアリングに関する知識を蓄えることの重要性が日々増していっているのをひしひしと感じます。
今後どのようにエンジニアリングの手法によってさらなるデザインシステムのパラダイムシフトが起きていくかとても楽しみです。
