HRMOSでは複数存在するモジュールの体験を統一するために「Design System(デザインシステム)」の開発を行ってます。
そこで本日は
- HRMOSにおけるDesign System
- メリットだけではない、Design Systemのデメリット
を中心に紹介をしたいと思います。
Design Systemとは？
『Design System』という本の一節にこう書かれています。
デザインシステムとは、デジタルプロダクトの目的を達成するために首尾一貫したルールで編成された、お互いに関連づけられたパターンとその実践方法です。パターンは繰り返される要素で、これらを組み合わせてインターフェースを作成します。
— Design Systems - アラ・コルマトヴァ
HRMOSにおいてのDesign Systemとは、いわゆるUI Kitのようにデザインパターンが羅列されているだけでなく、いつどのようにそのパターンを使用するのか、またそれはなぜなのか、を 可能な限り言語化したものと捉えています。
言語化をすることで、デザイナーの中での共通認識がうまれ、デザイナーごとのUIデザインのブレを少なくすることができます。また、UIデザインをする上での決定の根拠にすることもできます。
Design Systemを作成することによって、誰でも・簡単に・一定の品質を担保されたデザインができ、難易度の高いUI/UXデザインの負担を軽減し、各モジュール独自のUI/UXデザインにフォーカスさせることができると考えています。
HRMOSにDesign Systemが必要な理由
HRMOSは "採用"から"活躍"までひとりひとりのストーリーをデータから生み出せる組織へ というビジョンを掲げているサービスです。
このビジョンを実現するために、採用管理、従業員データベース、評価管理、1on1支援、組織診断サーベイ など、様々なモジュールが存在します。そしてモジュールはこれからも増えていく予定です。
モジュールごとにチームが存在し、それぞれ別々に開発しているのですが、このことにより以下のような問題がありました
- 同じHRMOSを冠するサービスにもかからず、UI/UXが異なる
- 例: HRMOSのカラーである青色のカラーコードが各モジュールで異なるなど
- 同じようなUIパーツを各モジュールごとに独自に実装してしまっている
- 例: ボタンUIの実装が各モジュールごとにあるなど
- モジュールごとのデザインが特定のデザイナーに属人的化してしまっている
そこで、One Experience1、Scalable DX2 を目的に、HRMOS独自のDesign Systemの開発がスタートしました。
Design System「Polyphony(ポリフォニー)」
上記の問題を解決するために、HRMOSでは「Polyphony(ポリフォニー)」と呼ばれるDesign Systemを独自で開発しています。
ポリフォニー(polyphony) とは、複数の独立した声部（パート）からなる音楽のこと。ただ一つの声部しかないモノフォニーの対義語として、多声音楽を意味する。
— Wikipedia - ポリフォニー
Design Systemとして調和がとれているという意味と、多数の機能群が独立しつつ協調して存在するためのシステムという意味を込め、このように命名しました。
既存のDesign System(Material Desiginなど)を使用せずに、独自にDesign Systemを開発することにした理由は、 ユーザーの声を素早くDesign Systemに反映させ、Design System自体を成長させ続けないといけない と感じているためです。
ここでユーザーとは、Design Systemを利用してモジュール開発を行う 開発チーム と、HRMOSの利用者である エンドユーザー の2つを指しています。
Design SystemはHRMOSのUI/UXの根幹を支えることになる一方、やり方を間違えると各モジュールの成長の足かせになりかねないというリスクをはらんでいます。
足かせにならないためには、Design Systemのスピード感のある継続的な成長が不可欠です。
このことは既存のDesign Systemでは実現できないと感じ、独自でDesign Systemを開発することにしました。
Polyphonyの概要
簡単に紹介すると、Polyphonyは大きくわけて以下の2つから構成されています。
デザイン原則
デザインをする上で判断軸になる標語や行動指針のことを指します。
例えば、Polyphonyでは原則の一つに Thoughtful というものを定めており、これは いつもユーザーの一歩先を汲みとり、率先して気の利いた提案ができるように努めましょう という意味を表してます
コンポーネント
Button, InputなどのUIパーツのデザイン仕様と、そのルールを言語化したもの。
例えば、赤いButtonは 不可逆的で優先度の高いアクションに使用でき、1グループ内に1つだけ配置できる などのルールを記載しています。
メリットだけではない、Design Systemのデメリット
Design Systemを開発・運用しはじめたことによって、目的どおりの効果も見受けられて手応えを感じています。
一方で、様々なデメリットも見えてきました。
- Design Systemが及ぼす影響範囲が広い
- 1つのバグや仕様変更が全モジュールに影響する
- Design Systemの開発に常にコストを掛け続けないといけない
- Design Systemの更新の手を緩めてしまうと、Design System自体がHRMOSの負債になりかねない
- モジュールなのか？Design Systemなのか？の線引が難しいケースも
- Design Systemの定義にないパターンをDesign Systemに組み込むのか、モジュール独自で実装するのかの意思決定が必要になる
HRMOSではこれらのデメリットに対して、以下のような対応をしてます
- Design Systemの変更によるデグレ検知のためにさまざま自動テストを導入3
- Design Systemの仕様変更の際、各モジュールチームに協力を依頼してテストを実施
- Design Systemの開発を組織的な目標の1つとして定義し、ある一定のリソースをかけることを組織的にコミット
- Design System開発責任者を明確にし、判断にこまる場面で都度相談してもらう
最後に
今回お話したことをまとめると以下のとおりです。
- デザインの属人性の排除や、体験の統一、生産性の向上のために「Polyphony」というDesign Systemを開発してます
- Design Systemの開発はメリットだけではなく、デメリットもあります
今回触れなかった、Design Systemの運用や開発、課題、今後の方向性などを別の記事で詳しく書きたいと思いますので、楽しみにお待ちいただけるとうれしいです！
