みなさんこんにちは。Ｓｋｙ株式会社では、社員が使用するコミュニケーションアプリや業務システムなどを内製化しており、社内DXを推進する専門部署（Ｓｋｙスタイル部）が存在しています。今回は、それらアプリやシステムで一貫性のあるユーザー体験を提供するために構築したデザインシステムのこれまでの経緯についてご紹介します！デザインチームの発足から、課題の解決、システムの構築とバージョンアップ、そして社内公開までの詳細をお伝えします。
デザインシステム構築に至るまで
デザインチームが2022年に発足し、そこから2024年にデザインシステムを社内公開しました。そこに至るまでの経緯もご紹介します。
導入前の状態
デザインシステムの構築にあたり、デザインチームについても紹介させていただきます。デザインチームは2022年に発足されました。 それまで、部内ではデザイナーはおらず、開発メンバーがデザインも担当していました。 また、デザインツール等も使用せず実装時に画面のUIを決め、ユーザーからの要望を元に画面を修正していました。
▲作成資料（Excel）
部内では多くの社内システムを開発し、いくつかのチームに分かれてシステムを開発していました。
感じていた課題
デザインシステムを導入する前は、デザインシステムを始めとするデザインに関するガイドラインがなく、 システムごとに開発メンバーが独自の方針で画面を作成していました。その中でいくつかの課題がありました。
- システムごと・画面ごとにデザインが違う
システム・画面ごとに担当する開発メンバーが異なっているため、それぞれの画面にてデザインにばらつきが出ていました。また、スタイルも共通化されておらず画面によってボタンの色が異なっていたり、余白が異なっていたりとばらつきが多くありました。 - 開発コストが高い
実装の場合、システム間共通のライブラリがないため、システムごとに一からUIコンポーネントの実装が必要でした。また、ガイドラインがないことで細かいUIを都度考える必要がありました。ですが、スケジュールとの兼ね合いにて検討の時間が十分に取れずデザインが後回しにされることが多くありました。 - リッチな機能にできない
スケジュールの問題から、社内システムにてUIの実装にかけられる工数が取れず流行りを取り入れたUIやリッチな仕様にできない状態でした。
デザインシステムの構築
スケジュール
デザインシステム構築に当たって以下のステップで作成していきました。 それぞれのステップごとに行ったことや、起こった事件をダイジェストで振り返ります。
ひな形作成
デザイナーがFigmaを作成するよりも前に、開発メンバーが試験的にUIコンポーネントライブラリ「Chakra UI」を元にコンポーネントを作成し、Storybookにてコンポーネントを管理していました。 ただ、コンポーネントも十分に揃っているわけではなく、最低限のコンポーネントのみ作成していました。
ベンチマーク
ここから本格的にデザインシステム構築が始まり、まずデザインシステムのベンチマークから行いました。 デザインシステムを構築する中で必要な要素もわからなかったため、公開されているデザインシステムの中からより近い領域・コンセプトで作成されたデザインシステムを参考にしました。 （デジタル庁、 Attlasian 、SmartHR、 vibes、 Spindle 等） それぞれのデザインシステムのガイドラインサイトや公開されているFigmaを閲覧しデザインシステムに必要な要素や構成を書き出していきました。
▲書き出したコンポーネントのカテゴリ分け
ver1.0 構築
デザインチームメンバー３名と開発メンバー１名で構築を開始しました。 ベンチマークと並行してAtomic Designの階層の定義やファイル構成の検討も行い、 それに合わせてFigmaにてスタイルとコンポーネントを作成していきました。 デザインシステムを構築する中で、デザインチームではデザインコンセプトを作成し、 それに沿ったデザインシステムとなるよう必要最低限の要素を洗い出し、定義していきました。
▲Figma
▲Storybook
発生した事件
- デザインチームに衝撃走る！いつの間にか初期化されたテキストの謎
- バリアントを変えてもアイコンの色が引き継がれず、地味に苦労していた件
- サイズ変更できないバグを見つけたので、全コンポーネントを内包に切り替える作業が始まった件
ver2.0 構築
ver1.0をリリースした後、実際に各プロジェクトでデザインシステムを導入してもらいました。 しかし、長期的な運用を行う上で以下の課題が出てきました。 ガイドラインの記載がないことでデザインメンバーの認識が誤り、デザイナー間で正しくコンポーネントを使ってもらえない デザインシステム更新時にFigmaの互換性がなく、更新後のコンポーネントの修正が多く発生してしまう Storybookで提供しているUIコンポーネントが不足しており、実装の開発工数の削減に繋がらない これらの課題から、Figmaファイルの構成やコンポーネントの作り方の見直しが必要となりました。 「開発と共通認識を持てるデザインシステム」をテーマに、Figma,Storybookでの構成を一から見直しました。 また、ガイドラインの拡充も行いコンポーネントをデザイナー・開発ともに正しく使ってもらうための利用時のルールを明確にしました。
▲検討資料（FigJam）
▲Figma
▲Storybook
発生した事件
- ボタンのターシャリカラー決定戦！デザインメンバーの熱き戦い
- ボタンの見た目を統一したら、修正地獄に陥った
- フォームコントロールの構成に悩んで、レスポンシブ対応のために横配置をリストラした結果
- セグメントコントロールの誕生！Tabとの違いを超えて
- Figmaの再構築：カテゴリーの力でコンポーネントを探せ！
- Figma仕様を優先したデザインデータ作成で、過去のコンポーネントをアップデートするのが大変すぎる！？
- Figmaのブランチ機能でデザインシステムを整理する方法を確定した件
- 色彩の迷宮（ラビリンス）！デザインシステムのカラーパレットを決めたら世界が変わった
ver2.1 構築
新しくビジュアルを刷新したデザインシステムを各プロジェクトで使用するにあたって、コンポーネントの周知を行いました。 また、Figmaのブランチ機能が追加されデザインシステムの運用方法の手順を確立できました。同時期にバリアブル機能も追加され、検証を行っていました。
発生した事件
- ステータス切替ができないなんて、ありえな～い！バグったサイズも調整してみたら、意外といい感じになった件
- 「このコンポどこにあるねん」デザインシステムの迷子になったデザイナーが目次とビジュアルでパーツ探しを始めました
外部評価
構築したデザインシステムを外部委託にてGoodpatch様に評価していただきました。 Figma、Storybookを元に、簡単なシステムを作成してもらい、デザインシステムとしての完成度や使いやすさを評価いただきました。
▲評価内容（Figｍa）
ver2.2 構築
デザインシステム評価レポートを元に、不足していたガイドラインの追加やコンポーネントを追加しました。 また、デザインチーム内で上がってきた改善点を元にコンポーネントの修正も行いました。 要素を揃えることができたためデザインシステムを社内で公開し、ここでようやくデザインシステムを構築できたといえる状態になりました。
▲検討内容（Figｍa）
発生した事件
- バリアブルを導入したら、コンポ読み込みバグが止まらない
ver2.3 構築
デザインシステムを社内に公開し、部署内でのデザインシステムの導入も進めていきました。各プロジェクトから上がってきた改善要望をデザインチーム内で毎日15分ほど時間を取って共有・検討しました。 また、デザインチームメンバーも増員しチームメンバー全員にガイドラインの認識が必須となりました。そこでデザインガイドラインを作成しFigmaにて共有しました。
▲デザインガイドライン（Figma）
▲検討内容（FigJam）
発生した事件
- フォームコントロールの改善をしたけど、プロジェクトごとにイレギュラーが多発してルールが決まらない件
- テキストがかすかすで読めない！？ウェブフォントの罠にハマったデザインチームの奮闘記
- VRTを無理矢理合わせたら実装が崩壊したけど、デザイナーの力で一致させることにした
- 数値上はクリアしてるのに、見た目が微妙！色のコントラスト問題に悩む日々
おわりに
デザインシステムの構築は全体として2年ほどかかりました。それぞれのバージョンアップでは多くの課題にぶつかりながらも、デザインチームメンバーで検討し進めていくことができました。