はじめに
この記事では、弊社が行なったデザインシステム導入への取り込みをまとめたものになります。
この取り組みが何かの参考になればと思い、今回記事にしました。
想定している読者
- デザインシステムを導入したいと考えている人
なぜ導入しようと考えたのか？
以下の理由から、デザインシステムの導入することを決めました。
複数プロダクトで共通したUIが必要になることが想定された
デジタルセラピューティクス(以下DTx)の開発では、患者、医療従事者向けにアプリを開発を行います。
特に、医療従事者向けのアプリでは同じようなUIが必要になることが想定されました。
例
- 医療従事者情報
- 患者情報
- 治療情報
また、患者取り違えによる医療事故などを防ぐため、すべてのプロダクトに共通するデザインルールを定め、順守する必要がありました。
DTx開発特有の事情
DTx開発では、臨床研究時に機能追加を行えません。そのため、開発リソースに余裕ができるタイミングがあります。
何からはじめたのか？
デザインシステムについて調査
デザインシステムのことをよく知らなかったため、まずは調査から始めました。
調査方法は以下の通りです。
- デザインシステムについて書かれた書籍を探す
- 公開されているデザインシステムを探す
- デザインシステムをテーマにした動画を探す
調査した結果、以下の情報リソースを見つけました。
デザインシステムについて書かれた書籍
公開されているデザインシステム
デザインシステムをテーマにした動画
調査からわかったこと
デザインシステムとは？
デザインシステムに関する標準的な定義は存在しません。[1]よって、プロダクトやチームに適した定義を設計する必要があります。1から作るより、公開されているデザインシステムの定義をベースとして、カスタマイズする方法がやりやすそうです。
デジタル庁デザインシステム
デジタル庁デザインシステムは、スタイリングの考え方を提供するデザイン言語、情報の視覚表現とインタラクションを具現化するUIコンポーネント、ユーザビリティとアクセシビリティを踏まえた設計や実装のためのガイドラインから構成されるデザインアセットです。
https://design.digital.go.jp/
SmartHR Design System
SmartHR Design Systemは、クラウド人事労務ソフトSmartHRにおいて、サービスに関わるすべての人がSmartHRらしい表現をするための基準や素材をまとめたものです。
https://smarthr.design/introduction/
Atlassian Design System
Atlassian Design System is a collection of UI components, foundations, and standards that help teams build beautiful product experiences.
(Atlassian Design System は、チームが美しい製品エクスペリエンスを構築するのに役立つ UI コンポーネント、基盤、標準のコレクションです。Google翻訳による翻訳)
https://atlassian.design/get-started/design
どうやって開発したのか？
開発チーム
開発特有の事情により、プロダクト開発チームからチームを立ち上げました。
チーム編成は以下の通りです。
- プロダクトマネージャー
- デザイナー
- エンジニア
開発方法
アジャイルを採用して開発を進めました。
具体的には、以下ような流れで運用しました。
- 定例ミーティング(週1)で議論を行い、タスクを整理
- 必要なタスクについて話し合い、チケットを作成
- 次回の定例ミーティングで進捗管理・レビューを実施
- 作成したチケットの進捗状況を確認
- 必要に応じてフィードバックや改善策を検討
- 会話が必要な場合は随時議論
- 定例を待たずに、必要に応じてその都度ディスカッションを実施
- 課題や不明点を早期に解決し、開発のスムーズな進行を図る
方針
今後使用していくことが前提のため、デザインシステムを使用する人のDX(Developer Experience)の向上を重視しました。
開発したデザインシステム
使用したツール
既存のプロダクトで導入していたツールを使用しています。
- Figma ... デザイン
- GitHub ... テーマファイル, UIライブラリを管理
- Storybook ... VRT, UIコンポーネントカタログ
全体図
Figma
ページ構成
| ページ名 | 説明 |
|---|---|
| Cover | カバー |
| Readme | 目的、適用範囲、用語説明、作業手順 |
| UI Rule | デザイン原則、理由、避けるべきデザイン例 |
| Design Token | デザイントークン |
| Component | コンポーネント、コンポーネント毎のガイドライン |
| Show Case | コンポーネントを使用したUI例 |
| Free Board | 主に議論で使用する |
GitHubにDesignTokenを渡す
FigmaのLocal Variablesに定義したDesignTokenをプラグインを使用し、GitHubに渡します。
実装方法は、Figmaからテーマファイルを効率生成！GitHub ActionsとStyleDictionary活用術で詳細に説明していますので、ぜひご覧ください👍
GitHub
テーマ
FigmaのDesignTokenを受け取った後、JSONに変換します。
その後、サポートする言語向けにテーマを生成し、
GitHub Packagesで提供します。
UIライブラリ
テーマを使用してFigmaで作成・変更されたコンポーネントを実装します。
このUIライブラリでは、radix-uiとvanilla-extractを使用し、効率的かつ型安全な実装を実現しています。
実装したコンポーネントは、Storybookでいつでも確認ができます。
また、CIでユニットテストやVRTを実行しています。
GitHub Packagesで実装したコンポーネントをプロダクト向けに提供します。
どういう運用にした？
実際に運用はできてませんが、以下のような方針・運用フローとしました。
方針
デザインシステムの変更は慎重に判断する
理由は以下の通りです。
- 会社の規模からリソースが限定されるため
- 変更やメンテコストが増加するため
運用フロー
振り返り
- デザイン原則があることで、議論がスムーズに進んだ
共通の基準があることで、デザインの意図を明確に伝えられ、意思決定の効率が向上した。 - チームで考え、決めていくことが多く、定期的な振り返りが重要
デザインシステムは一度作って終わりではなく、継続的に改善・調整する必要がある。 - DXを意識した開発が、システムを使い続けてもらうために不可欠
使いづらいデザインシステムは形骸化しやすいため、開発者にとっての利便性を考慮することが大切。 - 開発に時間がかかった
開発リソースがあっても、公開できる状態になるまでにそれなりの時間がかかった(最低限の実装で2ヶ月ほど)
まとめ
デザインシステムの導入は大きな取り組みでした。
そのため、導入の判断は難しく、慎重な検討が求められます。
現在の状況を踏まえ、導入判断には以下の観点が重要であると感じました。
- 導入コストを許容できるのか
初期構築や既存フローへの適用コストが許容できるか。 - 継続的に運用できる仕組みがあるか
作るだけではなく、使い続けたくなる仕組みが必要。
運用体制やルール整備が整わないと、形骸化するリスクがある。
今回の取り組みが参考になれば幸いです😊
備考
デザインシステムをテーマをした勉強会のリンクです。
-
Design Systems デジタルプロダクトのためのデザインシステム実践ガイド P13 ↩︎
Discussion