「デザインシステムのよくある悩み」に遭遇しなかった SmartHR Design System の2年間の実践
ご無沙汰しています。SmartHR プロダクトデザイナーの @versionfive です。
ここ1年ほどは、SmartHR基本機能のとある機能のリニューアル開発に携わっていて、楽しく仕事をしています。
2020年11月にSmartHRのプロダクトのデザインシステムの公開をはじめて、立ち上げの経緯や “デザインシステムは、「ユーザー」と「目的」からはじめることが大事だよ“という趣旨の連載をしたのが2021年4月。公開して2年以上、前回の振り返りからも1年半以上も経ってしまいました。
詳細は以下の記事で紹介しています。お手頃価格な電子書籍版もあります。(宣伝)
今回は、SmartHRのプロダクトのデザインシステムのこれまでを年表で紹介しつつ、公開して2年ほど運用して分かったデザインシステムに関する気づきを書いてみたいと思います。
SmartHR Design Systemの目的
社内のプロダクトサイド向けオンボーディングドキュメントで、デザインシステムの目的を以下のように説明しています。このドキュメントも公開後すぐに生まれて都度更新していますが、ここの説明は変わっていません。
携わるメンバーもコンテンツも増えた現在でも、根っこで共通している部分だと個人的には思っています。
目的の対象は「プロダクト(開発)」であり、プロダクトデザインをデザイナーだけのものにしない、「プロダクトに関わるすべての人への仕組み」を意識して作っています。
年表
社内オンボーディングドキュメントに載せているものをほぼ転記しちゃいます。(大盛りでごめんなさい)
結構いろいろありましたね〜
立ち上げ当初は、コムデとプロデザの一部のメンバーが中心でした。
今では、UXライターが中心にライティングに関するドキュメントがどんどん公開されたり、UXリサーチャーが中心にユーザービリティテストに関するドキュメントの公開もはじまり、プロダクトデザイン以外の職能からもコミットが増えています。
こんなSmartHR Design System(のプロダクト部分)を運用して2年間、デザインシステムを運用している企業と情報交換も増え、お話する中で気づいたことを書いていきます。
デザインシステムに影響する要素
デザインシステムは、それを運用する組織の体制や構造に強く影響を受けます。いわゆるコンウェイの法則で、デザインシステムに関わったことがある人は「当たり前でしょ」と感じると思います。
情報交換を通して、デザインシステムの構成や位置づけは、それを運用する組織に強く紐づいていることを実感しています。
SmartHR Design Systemも、カテゴリに対して組織にならう形で構成されています。
デザインシステムの立ち上げ時は、課題意識や感度が高いデザイン組織が中心となることが多いため、デザインシステムをはじめたデザイン組織の体制や組織上の役割が、そのデザインシステムにも投影されているな、と感じます。
デザインシステムのよくある悩み
情報交換する中で、以下のような悩みがあるけどSmartHRはどう?という話をすることがよくあります。
「ひとまずコンポーネントのバリエーションをまとめたが、プロダクトがバラバラで適用範囲を広げられない」
「コンポーネントをまとめるだけになってしまい、使い方を書くまで手が回らない」
「作ったデザインシステムが浸透しない(エンジニアに使われていない)」
「デザインシステムにどこまで投資すれば(作り込めば)よいのか」
「開発組織からデザインシステムの投資効果を問われている」
深くお話をしていくと、悩みの背景には、デザインシステムを運用している(デザイン)組織の体制や組織上の課題が関連していることが多かったのです。
デザインシステムに関するよくある悩みは、デザインシステムの運用する組織の課題(の裏返し)と言い換えることができるのではないでしょうか。
そして実は、SmartHRでは、これらのよくある悩みを感じることがほとんどありません(今のところ)。2年の運用を経て、その理由がなんとなくわかってきたのでご紹介します。
SmartHR Design System がよくある悩みに遭遇しなかった理由
それは、「プロダクト開発のため(だけ)にデザインシステムを運用していたから」だと考えています。
先述したとおり、SmartHR Design Systemの第一の目的は、プロダクトの「品質」と「生産性」に貢献することです。
この背景には、プロダクトデザイングループが、SmartHR 製品のインターフェース品質と、円滑な開発活動のサポートに責任をもつ組織であることが影響しています。デザインシステムプロジェクトも「もっとプロダクトを作っていく仕組み」の一つとして企画されました。
この前提においては、以下のような実践が生まれます。
開発チームに所属し、プロダクト開発の中で「全体を揃えたほうがよさそうだな」と課題感をもつプロダクトデザイナーやUXライターが、ドキュメント作成をリードする
先にプロダクト開発があり、後に共通化・汎用化したドキュメントが生まれる
プロダクト開発の生産性に関わらないドキュメントは生まれにくい
オーナーや専任担当を置かず、ロードマップも特にない(管理ツールの運用はPixelGridさんに協力いただいています)
結果的に、以下のようなデザインシステムができあがりました。
必要なときに必要なだけの基準を作るので、すべてがWork In Progressで最低限の穴あきドキュメントが公開される
Figmaなどのデザインツールベースではなく、SmartHR UIのコードを埋め込むのに相性がよいツール(GitHubのPull Requestベースの更新、メンバーが慣れ親しんでいるMarkdownでの記述)を自前で作る
「ルール」ではなく、開発の生産性を上げるための「ガイドライン(補助線)」だよ、と都度強調して共有される
課題感を持った人が参加しやすいように、テンプレートや運用ドキュメントが充実する
必要以上に整理されたバリエーションや、すぐには使わない基準はつくられない(つくる体制がない)
具体的な実践例は、Schema by Figma 2022 Tokyoで @wentz_design さんが登壇した「“デザイン”のためじゃないデザインシステム」で詳しく読むことができます。
SmartHR Design Systemはプロダクト開発につながる活動以外をほぼやっていません。デザインシステムを更新することは、実績がある整理された基準が生まれることであり、プロダクトの品質や生産性を上げる活動にそのままつながっています。
ここがSmartHRではよくある悩みを感じない理由だと考えています。
SmartHR Design Systemの今後
近年、デザインシステムが「DesignOps(デザイン業務の運用改善)」の文脈で紹介されることがありますが、SmartHRではデザインの業務改善というよりも、プロダクト開発に必要なこと(だけ)をアウトプットしながら、2年間運用してきました。
今後もしばらくは、オーナーもロードマップもなく、プロダクトの品質と生産性を上げるためにデザインシステムを作り続けていくことになりそうです。
採用情報
SmartHRのプロダクトデザイングループでは、プロダクトとデザインシステムをともに作り上げていく仲間を募集しています!
この記事が気に入ったらサポートをしてみませんか?