デザインシステムを創りはじめました。
こんにちは。
株式会社iCAREで健康管理システムCarelyのUIデザイナーをしている高橋名人です。
Carelyのデザイン・フロントエンドチームでは現在「デザインシステム」の構築を進めています。
デザインシステムとは
デザインの基準やドキュメント、原則に加えて、基準を達成するためのUIパターンやコンポーネントなどのツールキットをすべて備えたものです。
これを規定することで、展開するサービスやアプリにおいて一貫性が保たれ、ユーザーが期待する機能性やユーザビリティを提供できるようになると同時にチームが協力する際に生じるスケールの問題を解決するのに役立ちます。
雑にいうと、Carelyというプロダクトをチームで創る上での「辞書」のようなものです📘
発生していた問題
なぜ、デザインシステムが必要になってきたか？それは以下のような問題が発生したためです。
😱 作成したデザインファイルの最新版の管理が難しくなってきた
2021/01現在、株式会社iCAREの開発チームはデザイナー3人、フロントエンドエンジニア5人（内2人はパートナー）、サーバーサイドエンジニア9人(内2人はパートナー)の人数比率です。（インフラ、分析エンジニアも在籍しています。）
仮にデザイナー/フロントエンドエンジニア/バックエンドエンジニアがそれぞれ1人いる3人のチームであればそれぞれ自分の携わる範囲を把握し状態を理解できると思いますが、成長企業におけるソフトウェア開発ではそうもいきません。
そうした状況の中でAdobe XDのファイルを見たまま参照するだけでは、認識の齟齬や統一されていないUIパーツの実装に繋がってしまうことが増えてきてしまいました。
😱 技術の理解やプロダクトのコンテキストへの理解度にバラつきが出てきた
Carelyは産業保健スタッフや人事担当の方がメインで使うB2Bのプロダクトであり、専門家の直接的な意見がスピーディーに反映される側面があります。そのため一般的なUIデザインの原則に乗っ取っていないところもあります。
また、チームも増えてきて、サーバー/フロントどちらにもassignされることがあったり、新機能の開発に集中してから違う機能の改修にスポットでassignされることなども現場では発生しており、開発の意図や目的などを全員が正しく把握することが難しくなってきました。
これは「デザイン」に付随した「ドキュメント」が必要になってくるという課題感のもとデザインシステムの構築プロジェクトが始まりました。
参考にしたドキュメント
以下に、デザインシステムの参考にしたドキュメントをまとめます。
OSのプラットフォーマーのガイドラインはやはり目を通しておきたいものです。ユーザビリティやアクセシビリティに関する指針はかなり厳格がゆえに改めて意識しておきたい視点もたくさんあります。
ただし、SaaSのデザインシステムとして上記に倣って規定するのは膨大すぎるので、ATLASIAN Design SystemやSalesforce Lightning Design Systemなどのデザインシステムも読んで温度感を考えました。
また、『Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド』という書籍を一読しました。
デザインシステムの厳格さ加減のグラデーションを実例とともに紹介してくれた大変な良書でした。
Atomic Designの考え方
デザインシステムをエンジニアと構築する上で、Atomic Designという考え方は架け橋になります。
なぜならAtomic Designはデザインの変更やバリエーションの追加に優れているからです。ボタンの色などの小さな変更から、ページのレイアウトといった大きな変更まで、柔軟的に対応しやすいデザインシステムがAtomic Designです。
Atomic Designの詳しい考え方の解説については割愛させてもらいますが、こちらのスライドが大変参考になりましたので載せさせていただきます。
国内の事例
海外の事例はかなり完成度の高い厳格なシステムとなっているものが多いです。
これはアメリカなどが、多民族の契約社会になっていることも一因かと思いますが、これをそのまま目指そうとすると尻込みしてしまいますよね笑
そこで、国内のデザインシステムの事例も見てみました。
eurekaさんのデザインシステムの話は大変助けられました。
デザインシステムは正解もゴールもないので、みなさん暗中模索しています。
まずは、社内の実情に即したシステムの構築が必要ですね。
eurerkaさんの例はミニマルに規定を設定していますが、小さいことに見えてもじっさい大変なことははじめてみてよ〜く分かりました。
Carely Design Systemではどう始めたか？
では、実際にCarelyのデザインシステムはどのように運用を始めたかということを書いていきます。
まず、メインでデザインシステムを構築するのはUIデザイナーである私とフロントエンドチームを外部パートナーとしてアドバイスをしてくださる方の2人体制で行っています。
XD用のUIコンポーネントは1年ほど前から運用されていたのですが、それらのColor・Typography・Iconをdesign tokenとして整理し直して規定し、名称やどういった機能において使用されるかをドキュメント化し、Storybook上でフロントエンドチームが確認できるようにしました。
また、これらをXDのColor assetでも同様の名称とパレットを使用するようにして必要であればデザインファイルにコメントを追記してフロントエンドチームとの認識の齟齬をなくしていこうと考えています。
まずは、利用頻度の高いUIパーツからUIコンポーネントとして実装し、徐々にプロダクトへも適応していこうとしています。まだまだ始まったばかりですが、堅牢かつ柔軟なソフトウェアを作りユーザー体験を棄損しないためにも大切なことだと思うので、チームを牽引して創り上げていきたいと思います！
このnoteが面白かったら「スキ」や「フォロー」や「コメント」をしていただけると大変嬉しいです！
この記事が気に入ったらサポートをしてみませんか？