DesignSystemへの理解と困った事

これはなに？

Alla Kholmatova さんが書かれた本。
DesignSystem を読んで自分の理解をまとめつつ、運用して感じたことなどを残す。

DesignSystemとは

標準の定義があるわけではない。

「スタイルガイド」「パターンライブラリ」などと同じ意味で使われる場合もあるが、一貫性を持って編成された一連の繋がったパターン、また共有されたプラクティスのセット。

パターンはボタン、テキストフィールド、アイコン、タイポグラフィなどの様々なインターフェイスを構成します。

基本的に以下の要素で構成されています。

• デザイン原則
• 機能パターン
• 認知パターン
• 共通言語

デザイン原則とは

インターフェースをデザインするにあたり、プロダクトの目的とエートスが明確であることが重要です。

目的を踏まえあらゆる決定をする必要があり、これらの価値観にプロダクトに関わる人の同意と、コミットが必要となります。

そのために基礎となる価値と原則を確立させる必要があります。

作成時点で何もなければ、会社のビジョンやプロダクトビジョン、大きなビジョンにデザイン原則がどう貢献できるかを考えるところから始めるのが良い。

目的や対象を絞り原則を進化させていくことでパターン化していきます。

原則はデザインパターンに限らずデザイン原則にそってサイトのパフォーマンスや運営方法などにも表現されていきますが。

チームでの合意が不可欠です。

機能パターン

インターフェースの具体的な構成要素です。
特定のユーザ行動を可能にしたり促したりすることを目的としています。

ユーザの行動を基にどのようにデザインするかを考える必要があります。

この本では「10分レシピサイト」でわかりやすく例えられていました。

ユーザー行動の例です。 「レシピを選ぶ」「割り当てられた時間内に手順を進める」などがあります。

これらのユーザ行動を基に機能パターンをどの様にデザインするかを考えます。

機能パターンはシンプルでも良いですし、いくつか組み合わせて複雑なパターンにしても構わないです。

プロダクトが進化するとパターンも進化していきます。ユーザがレシピを採点できるようにして、その点数をレシピカードに表示させるかもしれません。

大事なのはパターンのテストをなんども繰り返し、より効果的にユーザー行動を促せるようにすることです。

「パターンは進化、振る舞いは不動です」

機能パターンを作成するのにカスタマージャーニーなどを用いることがあります。

認知パターン

オブジェクトの組み合わせにより雰囲気で認知が変わるという性質を持つ。

例えば部屋の雰囲気は人によってだいぶ違います。 家具次第では家に見えたり、倉庫に見えたりもします。

デジタルプロダクトに置ける認知パターンは、 トーン、タイポグラフィ、カラーパレット、レイアウト、イラスト、アイコンスタイル、形状、テクスチャなど様々な要素をインターフェースで組み合わせて使用する多様な方法が含まれます。

認知パターンは意図的では無い場合でも常に存在しています。

これらはプロダクトでスタイルやスキンなどで取り上げられるが認知パターンは表面上のものではなく、ブランドのコアに存在してこそ本領を発揮します。

モジュール式のシステムでは一貫性のあるシームレスな外見にするのが難しい場合があります。 認知パターンが浸透することでそれらをつなぎ合わせることが可能です。

共有言語

デジタルプロダクトではチームで構築していきます。

メンバーはそれぞれ異なる目標とスケジュールがあります。 そのためいい加減なパターンが追加されたりモジュールが重複することは避けられません。

大勢の人が関わっている中で一貫性や一体感を持つには、 チームが DesignSystem とその仕組みについて共通理解・認識を持つ必要があります。

チームが同じ原則に従っていることブランドビジョンが揃っていることです。一貫した DesignSystem には共有される言語が必要です。

そのためにはパターンランゲージのアプローチが有効です。 しかし実現するには多大な労力が必要になる場合があります。

機能させるために必要な取り決めやプラクティス

• 命名規則のパターンを決める
• チームで命名する
• 専用チャンネルを準備する（ Slack など）
• デザインランゲージを浸透させる
• オブジェクトをそれぞれの名称で呼ぶ
• プロジェクトの導入研修に取り入れる
• 定期的な DesignSystem キャッチアップを実施する
• 用語集の維持

実践して困ったこと

デザイン原則が曖昧なまま進行するUIライブラリ集

既存のアプリケーションに DesignSystem を導入を進めた際、UIライブラリ集や一部の認知パターンを導入していくことはできた。特に最初のリリースまでは問題なく進行していたと思う。しかしデザイン原則が曖昧なまま運用を続けてしまい少しづつ歯車が噛み合わない箇所が発生してしまった。特にカラーの命名周りで発生していた様に思う。

今回、改めて勉強し直しデザイン原則の大切さを理解できた。

ドメインに引っ張られるUIライブラリ集

DesignSystem として認知パターンなどを実装していくことはできたがアプリケーションのドメインに引っ張られる実装などが見受けられた。例えば汎用性の無いAPI通信ロジックなどでこれらは DesignSystem には不要だと思うが、開発が進むにつれて増えるエッジケースの対応などに困った。

これに関しては議論の中で「 ApplicationAware かどうか？」という切り分けがとても良かった。

「 Application-aware かどうか」とは 「プロジェクト」や「ユーザー」といった概念 (=ドメイン) に依存するかどうか 「内包するカード状のUI部品を並べるUI部品」と「ユーザの画像を表示するUI部品」という2つのUI部品があった時、前者はカード状のUI部品という他のUI部品に依存するのに対し、後者は「ユーザ」のデータに依存する。ドメインに依存するものはデータが必要、と置き換えて考えることもできる

既存プロジェクトでデザイン原則を構築する

デザイン原則とは何か？ DesignSystem に必要なことは何か？がしっかりと認知されていないチームで実装が進む事により産まれる歪み。またプロダクトのグロース・修正とデザイン原則作成タスクの優先順位付けなどがスムーズに行かない。

まとめ

DesignSystem 実践前に一読し、実践後改めて読み直し理解を深めて見落としていた事などが多かったなと感じつつも、 DesignSystem や実装にあたり周辺技術の恩恵はかなりあったと思う。運用や浸透に課外が起きがちなのはある程度どの方法でも起きる気はするので、しばらく運用を続けて勉強していきたい所存。