こんにちは、フロントエンドチームです。
今週のフロントエンド定例の内容を記載します。
フロントエンド定例について、以前の記事（ランサーズのフロントエンドチームが取り組んでいること）でお伝えしたのですが、毎週金曜日に開催しており、実際の業務で取り組んでいることや気になった技術情報等をシェアしあう会になっています。
以下、今週の内容です。
@high_g_engineer
書籍：Design Systems – デジタルプロダクトの為のデザインシステム実践ガイドの社内共有まとめ
本書について
デザインシステムを中心に、システマチックにデザインにアプローチする方法を紹介し、デザインシステム思考を組織にインプットすることを目標とした内容です。
読者対象は、ビジュアルデザイナー、UXデザイナー、フロントエンドエンジニアとされていますが、プロダクトに関わる全員が読むべき本だと個人的には感じています。
Chapter1に本書の大切な要素がまとまっているので、以下は、Chapter1に記載されていた内容を掻い摘んで、自分流に噛み砕いて表現したものを記載しています。
デザインシステム
本書でデザインシステムとは、デジタルプロダクトの目的を達成する為に一貫したルールで構成されたパターンや実践方法、慣習を集めたものと定義されています。
世間一般的には、標準の定義があるわけではなく、様々な用途で使用されています。
パターンは、以下のようなものを指し、これらを組み合わせてインターフェースを作成します。
例：ユーザーフロー、インタラクション、ボタン、テキストフィールド、アイコン、色、タイポグラフィ、ライティング
慣習とは、上記のようなパターンをどの様に作成、保存、共有、使用するかを記載したものです。
プロダクトが達成したい目的によって、デザインパターンが形成されます。
パターンと慣習のわかりやすい例として、トムソン・ロイターとFuture LearnのUIを画像で掲載します。
トムソン・ロイターのEikonのページ
トレーディング及びマーケット分析アプリケーションで、
データ管理、実用性、速読性、マルチタスクを目的としたUI
Future Leran
オープン教育のソーシャル学習サイト
深く考えながら記事を読む、形式張らない学習を目的としたゆったりとしたUI
デザインパターン（パターン）
デザインパターンは多くの要因に左右されます。
- プロダクトの領域、コア事業、機能の違い（本書では、機能パターンと呼んでいます。）
- エートスの違い
- エートスとは、特定の集団の基本的な考え方、性格、気風、特性などの意味
- ランサーズであれば、個のエンパワーメント、LancersWay（最高か最速、プロフェッショナル、チームランサーズ）等
上記の組み合わせで、どの様に認知されるかが決まり、本書では、これを認知パターンと呼んでいます。
認知パターンの定義が無ければ、似通った機能を持った同一ジャンルのプロダクトは、どれも同じ様に見えます。
パターンの違いは、プラットフォームの慣習でも形成されます。
- Web or アプリ
- PC or スマホ
- Windows or Mac
など
上記のように、デジタルプロダクトの作成に影響を及ぼすパターンは非常にあり、これがデザインの難しいところです。
パターン同士を対話、つなぎ合わせ、シームレスな連携を行うことが大切です。
デザインパターンという概念の初登場
デザインパターンという概念を初めて紹介したのは、建築家のクリストファー・アレグザンダーの以下2点の著書です。
- 「時を超えた建設の道」（原題：The Timeless Way of Building）
- 「パタン・ランゲージ ー 環境設計の手引」（原題：A Pattern Language）
この著書の一貫したテーマは、「普段生活していて、心地よいと感じられる場所もあれば、そうでない場所もあり、それはなぜか？」という疑問になります。
具体的な形を有した特定の場所や建物のパターンが、心地よさの印象を左右する為、
そのパターンを学び、利用することで、普通の人でも良い建築物が作り出せるとのことです。
同様にUIにおいてもデザインパターンを利用できれば、一般的な問題を解決することができます。
デザインランゲージ
世間一般的に、デザインパターンというものは既に確立されていて、おなじみのものが多く、直感的に利用できるようになっています。
まったく新しいパターンを使用する場合、そのパターンを覚え、慣れる必要があり、ユーザーの負荷は高めになります。
こういったパターンは稀で、プロダクトを競合他社と差別化する為には、パターンの目新しさではなく、既存パターンを連携、応用し、いかにデザインの目的を達成しているかが大切です。相互に繋げられた一連のパターンは、プロダクトのデザインランゲージを作り出します。
デザインランゲージとは？
- プロダクト開発が進むと現れてくるもの
- この言語がどの様なものかが必ずしも分かるものではない
- 効果的なデザインは直感をベースとしている場合も多い為、仕組みが明確にならないこともある
ただ、直感を完全に信頼したり、測定できない状態だったりするのは問題なので、
できる限り、この抽象的なもののパターンを具体化し、共有する必要があります。
デザインランゲージが明確にできると、実行可能かつ再生可能になる為、システムをより強力にコントロールすることが可能です。
例えば、あるUIを作成する場合、どう調整すれば、より目立つようになるかといったことをゼロベースで話し合うのではなく、視覚的な目立ち度合いに併せて、複数のカラーパターンを当てはめるだけであったり、UIパターン上のUIを組み合わせるだけといった世界になります。
また、ある些細な変更がUXに良い影響が出ると分かった場合は、この変更を1箇所だけでなく、サービス全体にパターンを適用するといったことも可能です。
デザインランゲージに対して共通認識を持てれば、パターンそのものに対しての議論よりもユーザー中心の議論ができるようになります。
機能パターンと認知パターン
デザインランゲージを明確化する為に本書では、機能パターンと認知パターンに焦点を当てています。
機能パターンは、ボタン、ヘッダー、フォーム要素、メニュー等実態のあるインターフェースを指します。
認知パターンは、色、タイポグラフィ、アイコン、形状、アニメーションなど、プロダクトの個性を視覚的に表現するものを指します。
言語に例えると、機能パターンは、名詞・動詞に少し似ており、認知パターンは、形容詞に近いものがあります。
フロントエンドの観点でいうと、
機能パターンは、HTMLをベースにしていて、
認知パターンの多くは、CSSプロパティになります。
デザインシステムには、他にも様々なパターンが含まれます。例えば、入力フォームのエラーメッセージや成功メッセージ、ユーザーのフローパターン、使い勝手を特別に考慮したUXパターン等があります。
共有言語
言語は共同作業の基本です。チームで作業している場合、プロダクト開発に携わるメンバー間でデザインランゲージを共有する必要があり、この言語が共有出来ていなければ、各メンバーが個別の思考で取り組むこととなり、効率的にプロダクト開発を行うことが出来ません。
アビー・コバートは、著書「今日からはじめる情報設計 ー センスメイキングするための7ステップ」
で、言語に関する取り決めについて話し合い、審査し、明文化する事で、共有言語を確立してからインターフェースについて考えるべきだと述べています。
これでもまだ十分とは言えず、チーム間で同じ言葉を共有して、深く理解し合っている様に見えたとしても、解釈が根本的に違っていることもあります。
共有できる言語を開発するだけでは、不十分で、言語の使用方法も統一しなくてはいけません。
例えば、ボタンという言葉に対して理解を共有するだけでなく、それを使用する理由、コンテキスト、それが果たす目的なども把握する必要があります。
ある実装において、上記が決まりきっていないと、ボタンが良いのか、リンクが良いのか、チェックボックス等のUIが良いのか等の様に思考にブレが発生し、効率的なプロダクト開発を阻害します。
理想を言えば、プロダクト開発に関わるすべての人が、この要素の名称と目的、デザインされた理由、いつ、どの様に使用されるのかを知っているべきで、この共通認識が強固であるほど、要素が適切に使用される可能性が高くなります。
デザイナーとフロントエンド実装者には、この共通認識が欠かせませんが、コンテンツ企画、マーケティング、PdMなどの担当者も知っておくことが望ましいです。
現状の画面を知らせるコンポーネントをある人は「シーケンス」と呼び、ある人は「ウィザードコントロール」、ある人は「ファンシーバブル」と呼んでいるとその言語は機能しません。全員が「シーケンス」として知っておく必要があります。
パターンライブラリの限界
パターンライブラリは、デザインシステムの代用になると考えられることがあります。
しかし、非常に包括的で生きたパターンライブラリであっても、システムそのものと同一ではない為、パターンライブラリは、デザインシステムの効果を高める為のツールでしかありません。
パターンライブラリは、デザインの一貫性を保証するものではありません。ちょっとした不整合を修正したり、基本コードを堅牢にするのには役立ちますが、ライブラリ単体では、UXにはほとんど影響しません。
逆に、包括的なパターンライブラリがなくても、一貫したUXは提供するプロダクトは作成可能です。
パターンライブラリが最新の状態を維持できていれば優れた共同作業につながりますが、少人数のメンバーしか利用できていなかったり、チーム間のコミュニケーション不足で大量にパターンが存在したりすると分断された状況に陥りこともあります。
優れたパターンライブラリと慣習を統合し、一貫したデザインシステムという基盤がなければ、その影響力は限定的になってしまいます。
効果的なデザインシステムを構築するには
効果的とは
デザインシステムの効果を測る際に指標となるのは、様々な部分がどれほど上手く連携して、プロダクトの目的に貢献しているかです。
効果的であると判断できる例としては、UIを作成する上で、デザイナーがデザイン作成するコスト、フロントエンド実装者の実装コスト（難易度が低く、速度を上げて実装できるか）の効率が良く、プロダクトの目的に関して、効率的かつ満足度の高いUXが実現されている場合です。
共通の目的
少し話はそれるのですが、ある大きなシステムを考えた時に、サブシステムが集まって構成されています。
人間を例に挙げると、脳、心臓、肝臓、胃、骨等のサブシステムがあり、さらにそれらのサブシステムを構成する為の細胞がありといった形です。単独で存在するシステムはありません。
デザインシステムも同じで、デザインシステムを構成する要素の中に、レイアウトをコントロールする編集ルールやレスポンシブの際の画像の拡大・縮小の方法などが存在します。
また、デザインシステムは常に、プロダクト、チーム、企業文化といった大きなシステムの一部でもあります。
効率の高いシステムは、サブシステムが連携して共通の目的を果たそうとします。
デザインのアプローチは、フロントエンド設計に反映され、デザインパターンは指針となる原則に従います。
デザインランゲージは、デザイン、コード、パターンライブラリに一貫して適用されます。
こうしたシステムの働きは調和が見られ、その後のワークフロー、UXにも一貫して適用されます。
問題の特定
一貫性が分断されたデザインシステムでは、UXも分断され、ちぐはぐなものになります。
そして、チームの生産性も影響を受けます。
コードがわかりにくく複雑である場合、ちょっとした変更を加えるだけでも手間と時間がかかります。
同じ様に、デザインがわかりにくい場合、コピーが困難だったり、UIを個別最適したりといった問題が出現する為、
解決すべきユーザーのニーズを理解して対応することが出来ません。
本書では、具体例を元に改善例を提示しています。
ざっくりと記載すると、
- 対象ユーザーの目的、ニーズ、動機を理解
- メンバー間で優先順位が違わないように全員が原則を理解
- UXフローを明確にしたり、ボタン、フォントなどを決める際には原則に従うことを徹底
- ユーザーの行動を洗い出し、機能パターンに落とし込む
- UXを良くする為、ブランドに相応しいムードボードをまとめる等し、タイポグラフィ、カラーパレット、トーンなどを認知パターンに落とし込む
- これらのプロセスと並行して、概念に対しての意味付けを行い、それぞれの詳細に応じた共有言語を取り決めていく（プロダクト内の単語の意味、何を持ってシンプルで軽快なインタラクションとするか？などに対して等）
掻い摘んだつもりが、かなりのボリュームになってしまいました。。
デザインシステムは一朝一夕で作られるものではなく、少しずつ、日々の業務に定着し、習慣化することで形成されます。
ここに書いてあることが全てではないので、詳しく知りたい人は、Design Systemsを読んでみてくださいね！
次回の更新予定は、5/27（金）になります！
前回の定例内容はこちらから確認可能ですのでご興味いただければ下記のリンクから閲覧いただければと思います