「Design Systems」輪読会まとめ

はじめに

WEBサイトのページを効率よく開発したり、ブランド毀損なく拡張していくためには、 そのページで使われているパーツ(ボタンや、色、フォントなど)を繰り返し使い回せるように管理しておくことが重要です。

ただ、その繰り返して使うパーツをどの粒度で作成、保存、共有、使用するかをプロジェクトメンバー間で決めておかないと、だんだんと崩壊していきます。

どのようなモチベーションでデザインし、それを変更、保存、共有、使用するかのルールを定めて明文化することを「デザインシステム」といいます。

今回、この「デザインシステム」について、具体的にどのようなことを明文化するべきかをデザイナーとフロントエンドエンジニア間で認識合わせるをするために「Design Systems」という本の輪読会を行いました。
この記事は本のまとめと感想の記事になります。

業務時間内で毎週1時間をつかって1章ずつ声に出して読みました。
全10章なので10週で終わります。(実際可能なペースです)

Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド

Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド

f:id:uggds:20190629235947j:plain
輪読会の様子

本のまとめ

デザインシステムとは
あるプロダクトのデザインに関するルールを定義し、そのルールに則ってプロダクトをデザインしていく仕組み

繰り返し要素を組み合わせてインタフェースを作成する

繰り返し要素の例

  • ユーザフロー
  • インタラクション
  • ボタン
  • テキストフィールド
  • アイコン
  • タイポグラフィ
  • リードテキスト
  • ...

デザインシステムでいうルールとはこれらの繰り返しの要素を
どのように作成、保存、共有、使用するかを記載したもの

繰り返し要素=デザインパターン

デザインシステムで整理、用意しておくもの

デザインパターンの種別

  • 機能パターン
    プロダクトの領域やコアな機能に基づいて決まるパターン
    ECサイトなら商品表示、絞込み機能、ショッピンカート、支払い機能)
    ユーザ行動に対する動詞になる
  • 認知パターン
    プロダクトのブランドに基づいて決まるパターン
    (口調、タイポグラフィ、色、アイコン、余白、レイアウト、形状)
    ユーザ行動に対する形容詞になる
  • ユーザーフローパターン
    ユーザーフロー(ユースケース)に基づいて決まるパターン
    (入力フォームの失敗メッセージや成功メッセージの出し方)
  • プロジェクト固有のUXパターン
    ABテストなどの計測に基づいて決まるパターン
    (入力フォームのファーストビューにはアクションボタンを入れる)

認知パターン補足
認知パターンがないと似たような機能になる
f:id:uggds:20190712093000p:plain f:id:uggds:20190712093016p:plain 認知パターンを使用することでユーザの関心をひき、行動を促したり、タスクを容易にしたり、達成感をコントロール感を与えることができる。

直感的に理解できるようになっているかが重要

共通言語
チームで作業している場合、プロダクトの開発に携わるメンバー間で言語を共有する必要がある。

「ボタン」とは?
クリックできる領域?
どこかにリンクされているページ上のインタラクティブな要素?
ユーザーデータを送信できるフォーム要素?

言語に関する取り決めについて話し合い、審査し、明文化することで共有言語を確立してからインターフェースについて考える。
それに加えて、ユーザー側がそれをどう解釈するかもさらに合わせて考える。

パターンライブラリ
デザインパターンを一覧化したもの、ツール

Webのデザインシステムでは以下を一覧化したものをさす

メンテナンスされ続けること必要

デザインシステムで明文化すべきこと

①プロダクトの目的と価値
Webサイトの対象ユーザーとその目的、ニーズ、動機を理解する。

②解決したい課題
デザインで何を解決しようとしているのかを明らかにしておく。

③デザイン原則
プロダクトの目的を表現する基盤となる原則を確立する。
プロダクト作成に関わる人々が価値に賛同し、その実現に尽力することが目的。

測定や数値化ができないので、定義は反復作業しながら徐々に作られていく。

良いデザイン原則の共通した特徴

  1. 真実で本質
    例えば「シンプル、便利、楽しい」という原則の場合、このプロダクトにおけるシンプルとは何か?などの答えが導かれていること
  2. 実用的かつ実行可能
    「シンプル、便利、楽しい」を明文化した場合、それが実行可能であること
  3. 視点(POV)がある
    「シンプル、便利、楽しい」のうち、どれを優先させるかはっきりさせるための視点があること
  4. 関連付けやすく、覚えやすい
    多くても覚えられないので、4~5点くらいに抑えていること

作り方の例

  • プロダクトの目的から作る
  • メンバーのすでにある共通認識から作る
  • ターゲットに注力して作る
  • 検証して原則を進化させる

④どうやって機能パターンを切り出すか
目的達成に向けて、主にどのような行動をユーザーに促したいかを考え、どの粒度でパターンを分割をするか。 (写真をアップしてもらう、いいねを押してもらう)

作り方の例

  • カスタマージャーニーから促したい行動のパターンマップを作る
  • インターフェースインベントリーを作成する

命名にはパターンを行為で捉える
「イメージヘッダー」「バナー」ではなく
 →「〇〇を宣伝する」
  →「広告看板」
   →「Billboard」という名称

パターンの中身を考える
 →どんな要素が必要か(見出し、CTA、目を引く画像)

パターンをスケールで比較する
 →パターンの大小が間違っていて行動の妨げになっていないか
 →PC用とスマホ用を考える

⑤どうやって認知パターンを切り出すか
誰にどのように認知して欲しいかについて考える。
(華やかで洗練されたもの?、真面目な雰囲気?、遊び心を盛り込む?)

さらに、それを実現する手段についても考える
(手書き風?イラスト?写真?ピンク一色?白黒?)

作り方の例

  • ムードボードを作成する
  • スタイルタイルを作成する
  • 要素コラージュを作成する
  • 反復と再調整

ブランドを守る時の注意点
一貫性のバランスをうまくとる
 →一貫性を守りすぎてブランドを崩さないように

ビジネス要件のバランスをうまくとる
 →ビジネス要件によってブランドにそぐわない要素をその場しのぎで入れてしまう
  →効果があった場合にブランドに合わせた変更がしずらい

⑥共通言語とデザインパターンの共有方法
上記で考えた機能パターンと認知パターンをどうやって、チームで共有するか

作り方の例

  • チームで命名する
  • 導入研修に取り入れる
  • 用語集を作る・維持する

感想

他社ではどうやっているかなど、想像以上に効果的でした。

本を読みながら、うちはこうだよね!とか、これができてないよね!とかが話せてとても効果的でした。

ここでまとめたことは、本のたった半分の「基本編」だけです。
「応用編」では実際にどうやって作るのかが具体的に記載されていて、一読の価値ありです。

実際どうやって進めたかは以下の記事にまとめました。
参考になれば幸いです。

ugap.hatenablog.com