デザインシステムを導入する為にやって良かったこと５選

こんにちは。クラウドワークスでデザイナーをしているYUCCAです。

今回「デザインシステムを導入する為にやって良かった事５選」のお話をしたいと思いますが、デザインシステムと一言で言ってもいろんな側面を持ち抽象度が高いので、前提としてこの記事でのデザインシステムのスコープや私たちのデザインシステム「norman」について軽く紹介させてください。

クラウドワークスのデザイン基盤チームでは、スケーラビリティを持ちながらUIデザインの品質を高められようにする為の一貫した仕組み（デザインシステム）づくりをしています。
このデザインシステムを私たちは「norman」と呼んでいます。

クラウドワークスで使用されている自社CSSフレームワークは2013年から根本的には変わっていない背景があります。なぜ変わっていないのかをここでは省略しますが、10年くらい前のものなので、レガシーなデザインが引き起こす様々な課題が現在生じてしまっています。

そこで私たちデザイン基盤チームでは、プロダクトや組織が膨らんでも品質を落とさずスケールしていく仕組みを作るべく、プロダクト開発としての技術的負債文脈や生産性文脈でのデザインシステム開発に取り組んでいるというわけです。

次に「norman」としてのプロセスのアウトプットは大きく４つに分類して定義しており、ブランドガイドライン、デザイン原則、スタイルガイド、コンポーネントライブラリがあります。（またこれらのアウトプットを使って運用できる様にする為のドキュメントや仕組みづくりも対象となります。）

デザインシステム（norman）

各アウトプットのピラミッド関係

現在、スタイルガイド（β版）が完成したので、プロダクト内の一部画面からスタイルガイド（デザイントークン）の導入やコンポーネントライブラリの作成などに着手しています。

これまでの取り組み

まだまだ道半ばな取り組みではあるのですが、ここまで取り組んできた中から、デザインシステムを既存のプロダクトに導入する上でやってきて良かった事を５選上げていきたいと思います。

１.ブランドガイドライン・デザイン原則をつくる

「ブランドガイドライン」はブランドとしてどうありたいかをルールではなく指針をまとめたもの。「デザイン原則」とは具体的なタイポグラフィや配置といったデザインするためのノウハウではなく「我々が考える良いデザイン」とは何かを思想として表したものです。

これらは、デザインシステムがデザイナーのものだけでなくプロダクト全体のものとして扱えるよう、当時の事業責任者やPMにサービスのあるべき姿・強み・将来的な理想、ユーザーにどのような価値を届けたいかなど様々な観点でヒアリング・分析後、それらを「実現するためにどんなデザインであるべきか？」を、１単語３つ（カンタン・スムーズ・オープン）でシンプルに表現し、ブランドガイドラインとしてドキュメントにまとめたものになります。

ブランドガイドライン

ブランドガイドラインについて

デザイン原則

２.DesignTokenを使ったスタイルガイドをつくる

冒頭でも記述したとおり、デザイン基盤チームはスケーラビリティを持ちながらUIデザインの品質を高められようにする為の一貫した仕組み（デザインシステム）づくりを目指しています。その為に、今回Design token（デザイントークン）を起用したスタイルガイドを作成しました。

スタイルガイドは主にデザイン作業のために、デザイントークンは主に実装のために作成していきますが、作成したスタイルガイドからデザイントークンに変換する際に、どのスタイルがBase token（ベーストークン）やSemantics token（セマンティクストークン）に当たるのかが分からない課題感がありました。

そこでデザイナーとエンジニアとの認識を合わせながらスタイルガイドとデザイントークンを定義し、必要に応じてアップデートしていきました。
また、実際に施策を行っているデザイナーに向けたユーザーテストを行う事で、スタイルガイドとデザイントークンが現場目線で使いやすいものなのかを検証。
カンタンでわかりやすく理解できるを意識したスタイルガイドへとアップデートしていきました。

スタイルガイドのプロセスと一部の見本

Design token（デザイントークン）：データとして表される、デザインシステム（間隔、色、タイポグラフィ、オブジェクトスタイル、アニメーションなど）を構築および維持するために必要なすべての値のこと。
私たちのデザインシステムではデザイントークンの中に、base tokens（ベーストークン）、semantics tokens（セマンティクストークン）という２種類のトークンレベルの棲み分けが存在しています

Base token（ベーストークン）：データとして表すための原始的なトークン。スタイル（色、フォント、ボーダーetc...）を定義する最小単位のトークン

Semantics token（セマンティクストークン）：サービス内で実用する為に定義・意味づけされたトークン。semantics token は base token で構成される。

デザイン基盤チームの共通言語より引用

３.プロフェッショナル・玄人向けにしない

プロジェクト自体が長期プロジェクトという事もあり、メンバーの入れ替えが発生した際に、これまでの知見を継承したりオンボーディングする為の工数が必要であったり、継承する人も属人化されてしまう課題感がありました。

そこで、同じコンテキストでデザインシステムについての議論を行える状態にする為に、これまでの経緯を文章としてドキュメントを残す事、チームメンバーで複数他社のデザインシステムを読み知見や知識を同じ視点まであげる為の輪読会、チーム内で飛び交う単語を新しいメンバーでも分かるように共通言語を一覧化し共通言語としての定義を行っていくなど。

チーム運営として、一見さんお断りの雰囲気を作らないよう活動をする事で、情報をよりフラットでオープンに出来る形になり、同じコンテキストでデザインシステムについての議論を行える環境を意識しています。

デザイン基盤用語集

新入社員に向けたオンボーディング資料

４.デザインシステム検証用のスコープを定めて少しずつ反映、一気にやらない

デザインシステムの始まりは小さな一歩でありました。この頃はスタイルガイドとデザイントークンをまだ紐づけていない状態（懐かしい）

ここからスタイルとデザイントークンを紐づけたスタイルガイドを作成しはじめ、ようやくプロダクトに反映していける状態へ。

その際に、検証用の対象画面（スコープ）を定め、スタイルガイドの要素である計７つのスタイル（typography、color、layout、spacing、shadow、border、border-radius）のうちまずはcolorのスタイルを適応。
その次に他のスタイル達も適応というように、実験的に一部分から反映をし、その中で修正したい場所が生まれたら修正後、再度反映。というサイクルを進めて行く事で、全体として後戻り少ない工程となりリスクや負荷を少ない状態で進めていきました。

５.半期ごとの目標・ロードマップを明確にする

デザインシステムの構築を進めていく上での、やりたい事・やるべき事がたくさん出てきて、メンバー間の目線が揃わない。大きなゴール（ビジョン）や半期ごとの目標はあるけど、どこまでの品質が担保されていれば運用できるのかが不透明である課題がありました。

理由としては、現状の自社CSSフレームワークの仕様を知っているメンバーが誰もいないという事もあり、関係各者と合意形成を取りながら新しいデザインシステムを定義する必要があったからです。

そこで私たちが行った事は、まずはデザインシステムとしてのデザイントークンを導入していく導入フェーズと、デザインシステムとしてのコンポーネント設計など最適な運用を考えていく運用フェーズとで分け、それぞれのフェーズごとに必要になるアウトプットを具体化していく事にしました。

導入フェーズと運用フェーズとで分けてのアウトプットを具体化

導入フェーズと運用フェーズとで分ける事で、導入の為の合意形成と運用する為の合意形成とで、別軸で行う事が出来るので、今やるべき事のイメージや優先順位をメンバーにもマネージャーにも伝えやすくなったと感じます。

誰のためのデザインシステム？

私たちが目指しているデザインシステムは事業メンバーに「使いやすい・使いたい」と思ってもらえるデザインシステムであり「必要だよね」と思ってもらえる仕組みです。
デザインシステムとして導入してもらう為には、なぜデザインシステムが必要なのか、から始まり、組織へと浸透させていくためのプロセス設計、システム構築・導入・運用フェーズも踏まえて開発・推進していく事が望まれます。

実際に施策を進める上でも技術的負債に苦しめられているエンジニア、本番と乖離したデザインデータやレガシーなUIコンポーネントに苦しめられているデザイナー、想定していた開発規模・工数がかかる為に、本来行いたい施策ではなく別策を考えながら事業の数字と向き合わなけらばならないプロダクトオーナーやマーケター。
デザインシステムはフロントエンドの技術的負債文脈として考えられがちですが、事業としての影響範囲はエンジニアやデザイナー以外にも間接的にプロダクトオーナーやマーケターなど施策を企画する職域にも影響していると私は考えます。

マイナスになってしまっている仕組みをフラットにし、開発体験を上げて働きやすい環境をつくる。その結果プロダクトへの付加価値を素早くユーザーへ届ける。
元々はボトムアップから生まれた活動ではありますが、今後はよりスピードやインパクトを持って事業に貢献出来るよう人材の採用を進め、チーム単位でのロードマップではなく事業戦略としてのロードマップとして連携できる状態になるようアプローチしていく必要があると考えています。

そういった手を動かすだけでない泥臭い働きかけもデザインシステムを推進していく上ではとても大切ですし、これからも続けていきたいと思います。

さいごに

ここまで読んでくだった方はきっとデザインシステムに興味があったり、課題を感じていたりする方なのではないでしょうか。少しでも役に立ったなと思えていただけたら嬉しいです。また他の事業会社さんではのデザインシステムについても色々情報交換ができたら嬉しいです！

まだまだデザインシステムは未完成ですので、サービスのデザインに大きくチャレンジできる面白さがあると感じています。一緒に成長し続けてくれるメンバー募集しています。