企業デザインシステムの構築と拡張に関する11の教訓
2022年5月、UXPinはDelivery Hero MENA（中東・北アフリカ地域（talabat））のDesignOpsディレクターであるアンバー・ジャビーン氏をお迎えし、「Enterprise Design System – How to Build and Scale.」と題したウェビナーを開催しました。
本記事では、彼女の講演の一部を要約し、デザインシステムの賛同を得る際にチームが直面した課題と、彼女ならどうするかということについてお話します。
アンバーは、UXPinの無料eBook「 DesignOps 101: Guide to Design Operations」の共同執筆者です。この本は6つの章からなり、DesignOpsの紹介とその実践法が説明されています。
UXPinでデザインシステムを構築、拡張、共有、成熟させましょう。
デザインシステムの賛同を勝ち取るために多くのチームが行っていること
2019年、Delivery Heroは、多くのスタートアップが経験する、あまりにも身近な困難に見舞われていました。UIライブラリやデザインシステムもないまま、9つのチームが製品に取り組んでいたことにより、Delivery Heroはサイロを生み出し、重複が多く、拡張しにくく、結果的に「非常に断片的なUX（ユーザーエクスペリエンス ）」になっていたのです。
アンバーとそのチームは、デザインシステムこそが、自分たちの問題を解決するイチバンの方法だと考え、ステークホルダーの賛同を得るためのケース作りに取りかかりました。
デザイン監査の実施
Delivery Heroの製品チームは、まずデザイン監査から始めました。そして監査報告書では、以下のような多くのユーザーインターフェースの不整合が明らかになったのです：
- 数種類のCTA（Call To Action）
- タイポグラフィ・スタイリング基準なし
- 複数のアイコン形式
アンバーは講演の中で、「…私たちのデザイン言語は、あちこちにあったのです。これは、大きな気づきの瞬間でした。」と言っています
チームは監査報告書をもとにビジネスケースを構築し、Delivery Heroの幹部に提示した結果、アプリ再デザインの賛同を得ることができました。
製品チームはまず、主要な画面とユーザーフローの再デザインを行いました。新しいデザインは、より一貫性があり、クリーンで、ブランドとの整合性が高く、UXを上げるものでした。
UIパターンでUIライブラリーを構築する
製品チームはこの再デザインをもとに、色、タイポグラフィー、立面図、UIパターン、コンポーネントなどのUIキットとスタイルガイドを作成しました。
Delivery Heroの製品部門は規模を拡大し、新しいデザイナーを採用しました。アンバーは、「このような規模の拡大にもかかわらず、Delivery Heroのデザインプロジェクト全体の一貫性が向上し、デザインを拡張することができた」と述べています。
コンポーネント・ライブラリ構築の初挑戦
デザイナー向けの信頼できる唯一の情報源（Single source of truth）のデザインに成功したDelivery Heroの製品チームは、エンジニアリング向けにも同じことをしたいと考えていました。そこでアンバーと彼女のチームは、コンポーネントライブラリのための別のビジネスケースをまとめました。
ビジネスケースのDelivery Heroデザインシステムの主要な利点を以下にまとめました：
- デザイン – 開発間の信頼できる唯一の情報源（SSOT）
- より良いUX（ユーザーエクスペリエンス）
- ブランドとの親和性強化
- 実験、プロトタイピング、テストの迅速化
Delivery Heroの幹部は、プレゼンテーションを気に入り、製品チームの提案に価値を見いだしました。 なのに、デザインシステムを作るお金もリソースもなかったことから、コード・コンポーネント・ライブラリの構築の答えは「ノー」だったのです！!
アプローチの練り直し
アンバーのチームは、もう一度振り出しに戻って、スタイルガイドを使った新しいデザインをアプリ全体に展開することにしたのです。このプロジェクトには3ヶ月を要しましたが、製品開発チームにとっては大成功でした。
その後6ヶ月の間に、Delivery Heroはたくさんの新機能と実験結果を出しました。製品チームの新しいデザインは新鮮で一貫性がありましたが、エンジニアにとっての信頼できる情報源がないため、Delivery Heroの最終的なリリースに一貫性がないという問題がありました。
製品チームは、一連の監査を再度行うことにして、そこでデザインハンドオフとプロダクションのスクリーンショットを撮った結果、コンテンツやUI要素の欠落など、多くの矛盾が明らかになりました。この監査で、Delivery Heroがリリースごとに負債を積み重ねていることがわかったのです。
Delivery Heroのデザインシステムに対する説得力のある事例の構築
Delivery Heroのデザインシステムチームにはエンジニアがいなかったので、デベロッパーと組んで、幹部に新しい売り込みをするためのコンポーネントを作り、テストする必要がありました。
アンバーのチームは、Delivery Hero の【No results】画面用のコンポーネントを作成し、デザイン システムを「使用する場合」と「使用しない場合」とで比較して実験しました
- デザインシステムなしで構築 – 合計時間：7.5時間
- 再利用可能なコンポーネントとして構築 – 合計時間：3.25時間
製品チームは、フロントエンドの開発時間のみを記録しました。この実験では、再利用可能なコンポーネントによって、フロントエンドの労力が57%削減され、負債が0%になることが実証されました。
アンバーのチームが、この新しいデータを使って、コンポーネントライブラリ構築のための別の事例を提示すると、Delivery Heroの幹部はこの結果に感動し、デザインシステムの開発にゴーサインを出したのです。
そして現在、Delivery HeroのデザインシステムであるMarshmallowは、デザインシステム専門チームが管理するUIキットとコードUIライブラリの30以上のコンポーネントを持ち、デザインと開発を一元化しています。
Marshmallowには、以下のものがあります：
- デザインシステムのウェブサイト
- 専用Slackチャンネル
- ブランド、コード、デザイン、コピーなどのガイドライン
- デザイン言語
- 作業やコミュニケーションのためのプロトコル
- コードコンポーネントライブラリ
- アイコンのテンプレート
- UIキット
- UIサンプル
- デザインシステムガバナンスの手順
ゼロからのデザインシステムの作り方はこちらでご覧になれます：Design Systems: Step-by-Step Guide to Creating Your Own.
企業向けデザインシステム構築のための賛同取得と拡張
アンバーは、学んだことを振り返りながら、企業向けデザインシステムへの賛同を得るための6つのアドバイスをしています。
本当のペインポイントから始める
製品、ユーザー、ビジネスに悪影響を及ぼしているペインポイントを特定することは、重要な第一歩です。アンバーとそのチームは、監査システムを使って、デザインと開発の間に大きなずれがあることを突き止めました。
価値提案の構築
ビジネスケースのための価値提案の構築に、ペインポイント（複数可）を使いましょう。そして解決策は、問題を解決し、ステークホルダーに投資対効果をもたらすものでなければなりません。
最大の支援者とスポンサーを特定する
アンバーは、デザインシステムの売り込みを裏付けるために、他部署からの支持者を探すことを勧めています。その支持者は、1, “これは会社にとって本当の問題である” 2, “これは最良の解決策である “というあなたの主張を支持してくれるでしょう。
語る前に見せる
アンバーは、最初のプレゼンテーションで犯したミスは、証拠なしにストーリーを語ったことだと言います。そこで、コンポーネントライブラリで何ができるかをステークホルダーに見せると、チームの話はより説得力を増し、ビジネスケースも納得のいくものになりました。
ビジネスメトリクスを語る
“シナリオのビジネスケースを、KPIやビジネスに影響を与えるメトリクスと関連付けなければ、ストーリーは完成しません。” アンバー・ジャビーン氏
さらに、ビジネスケースには、この問題がどのように会社のリソースに負担をかけているのか、そしてその解決策によって何ができるのかを示す、デザインシステムのメトリクスが含まれていなければいけないと言います。
一人でしない：ネットワークを築く
技術、デザイン、製品、マーケティング、顧客サービスなど、部門を超えたパートナーのネットワークとしてビジネスケースを売り込み、デザインシステムが、組織のための解決策であり、デザインチームの負担を軽くするためだけのものではないことを証明しましょう。
アンバーの1時間のウェビナー全体はYouTubeでご覧になれます。
UXPinによるコードベースのデザインシステム
UXPin独自のMergeの技術により、デザインシステムのコンポーネントライブラリとUXPinのエディタを同期させ、デザインと開発の間に信頼できる唯一の情報源（SSOT）を作成することができます。
