3章 機能パターン 内容紹介（4）
3章「機能パターン」は、このノートが最後です。機能パターンを定義する際に有用なテクニックについて見てきました。最後に、似ているパターンを強弱や度合いといったスケール上で比較し、定義したパターンを検証するための仮説としてコンテンツを扱う方法について解説します。
このマガジンは、12月21日に全国書店、25日にAamazonで発売された「Design Systems − デジタルプロダクトのためのデザインシステム実践ガイド」を編集している私が、個人アカウントでこの本を紹介するものです。全貌をいち早くお読みになられたい方は、ぜひ購入ヨロシクでございます。
※こちらはコリスさんによる紹介記事です。
3章「機能パターン」
この章では、機能パターンの役割と、なぜそうしたパターンを、デザインプロセスの早い段階から定義する必要があるのかについて解説します。
1.パターンは進化、振る舞いは不動
2.機能パターンを定義する（その1）
3.機能パターンを定義する（その2）
4.機能パターンを定義する（その3）※この記事で一部を紹介しています
− − − − −
▷パターンをスケールで比較する似ているパターンを強弱、度合いといったスケール上で比較してみましょう。たとえば、システムには強度の異なる複数の宣伝モジュールがあるかもしれません。第1章で紹介した視覚的やかましさと同じように、宣伝モジュールも互いに比べることができます。
パターンをスケール上で比較すると、パターンが適切に使用されているかどうか、注目を得ようと競合していないかどうかを確認できます。また、同じ度合いのモジュールの有無を把握できるので、不要なモジュールを作らずに済みます。
別の考え方も可能です。インターフェースが目に見えるものではなく、音声で読み上げられるタイプと想像してください。どのようなときに音声をもっと大きくしたり、イントネーションを変える必要がありますか？ ボリュームとイントネーションを視覚的に表現する方法を、モジュール内の要素間の関係およびデザイン全体の構造を通して考えてみましょう。
このような考え方には、当然、スクリーンリーダーを活用しやすくなるというメリットもあります。
▷コンテンツを仮説として扱う
逆説的な例を紹介しましょう。最初にコンテンツをデザインすることになっていて、同時に、どのような種類のコンテンツにも合うモジュールの構築を作らなければならないとします。これを実現するには、コンテンツから始めるのではなく、目的から始める必要があります。その場合、コンテンツを既知のアセットではなく、仮説として扱う必要があります。結果として、モジュールの目的を定義したかどうか、あるいは目的にかなったデザインかどうかを検証できることになります。
たとえば、プロダクトの特徴を紹介するようにデザインされたモジュールがあるとします。
このコンテンツの目的は、「容易に読み取り可能な少量の情報で、メインのメッセージを補足すること」と定義できます。「少量」の情報で、主な特徴や短いアドバイスを伝えたり、次のステップを手短に紹介します。この仮説（簡潔で読み取りやすく、メインコンテンツというよりは補足情報である）に合ったコンテンツ用にパターンを構築して、テストできます。コンテンツが一貫してこのパターンに適さない場合は、次の3つのいずれかが原因として考えられます。
● パターンの目的を正確に定義しなかった。うながすべき行動を再確認してみます。
● 目標を達成するようにパターンをデザインしなかった。別のデザインを試してみます。
● 適合しないパターンに無理にコンテンツを合わせようとしていた。コンテンツを見直すか、別のパターンを試してみます。
目的や構造から始めないと、コンテンツに依存し過ぎたモジュールになる可能性があります。たとえばFutureLearnでは、コピーが上に表示され、重要なタブが可視領域の下に追いやれたケースがありました。
タブは、常に表示することになっていました。この問題を解消するため、もう少しで見出しを特別に小さいサイズに修正して、タブを少し上に移動するところでした。もし実際にそうしていたら、堅牢でないモジュールになっていたでしょう。タイトルがもっと長かったり、もう1行多かったとしても、同じ問題に悩まされていたはずです。モジュールの目的や構造から始めていたら、タブはデザインに重要な要素なので、上部に配置されていたでしょう。
ここまで、インターフェースに機能パターンを定義するのに使用できる考え方やテクニックをほんの一部紹介しました。最も重要なのは、パターンが本来目指している行動にどのように結びついているのか、つまりパターンの目的を理解することです。
パターンの構造、コンテンツ、表現方法など、すべては目的次第です。パターンの目的（うながしたい行動）を知ることが、より堅牢なモジュールをデザインおよび構築する上で役立ちます。目的がわかっていれば、どの程度パターンを修正すればよいかわかるので、まったく異なるものが出来あがることがありません。また、チーム全体に共通の基準を定め、デザインの本来の意図と結びつけることで、重複を低減できます。目的の明確化により、実際の効果も容易に検証できるようになります。
機能パターンがインターフェースのオブジェクトと考えると、認知パターンはスタイルと考えることができます。スタイルとは、どのような種類のオブジェクトが、どのように感じさせるのかを表現したものです。
次の章では、認知パターンを詳しく見ていきましょう。
− − − − −
noteの機能では表現しにくい画像のキャプションや、発言の引用や脚注などは省略しています。あくまで、書籍の概要としてイメージしてもらえれば幸いです。全貌はぜひ書籍でお確かめください。
3章はこのノートで終わりです。いかがでしたか？ 次回から第4章「認知パターン」へと進みます。アイコン、色、タイポグラフィなどのスタイルについて解説していきます。
では、次回をお楽しみに。
この記事が気に入ったらサポートをしてみませんか？