3章 機能パターン 内容紹介（1）
今日から新しい章、3章「機能パターン」を見ていきましょう。2章でデザインシステムを検討する上での最上流とも言える「デザイン原則」について紹介しましたが、いよいよデザインパターンについて具体的に解説します。3章は、インタフェースの具体的な構成要素である「機能パターン」です。全4回の予定です。
このマガジンは、12月21日に全国書店、25日にAamazonで発売された「Design Systems − デジタルプロダクトのためのデザインシステム実践ガイド」を編集している私が、個人アカウントでこの本を紹介するものです。全貌をいち早くお読みになられたい方は、ぜひ購入ヨロシクでございます。
※こちらはコリスさんによる紹介記事です。
3章「機能パターン」
この章では、機能パターンの役割と、なぜそうしたパターンを、デザインプロセスの早い段階から定義する必要があるのかについて解説します。
1.パターンは進化、振る舞いは不動 ※この記事で一部を紹介しています
2.機能パターンを定義する（その1）
3.機能パターンを定義する（その2）
4.機能パターンを定義する（その3）
− − − − −
機能パターンとは、インターフェースの具体的な構成要素です。特定のユーザー行動を可能にしたり、うながしたりすることを目的としています。
10分レシピのWebサイトでは、「材料を選ぶ」、「レシピを選ぶ」、「割り当てられた時間内に手順を進める」などがユーザー行動です。これらのユーザー行動を基に、機能パターンをどのようにデザインするか考えます。機能パターン、つまりモジュールには、プロダクトの領域が大きく関係しています。
機能パターンとは、純粋な理想的な形というよりも、よりそれらが一般化されたものであり、モジュールは機能パターンを具体的に形にしたものと考えることができます。どのように具体化されるかは、インターフェース要件によって異なります。
財務関連ソフトウェアのパターンは、料理アプリケーションのパターンとかなり違うはずです。財務関連ソフトウェアの場合、レシピカードの代わりに、タスクバーやデータフィールド、表やグラフなどを扱うことになるでしょう。
機能パターンはシンプルでもよいですし、いくつか組み合わせて複雑なパターンにしてもかまいません。レシピカードは、料理の名前、画像、材料、アクションボタンで作られます。レシピカード内の各モジュールにはそれぞれ目的があり、料理名はどんな料理かを示します。画像からは、どんな料理が出来あがるのか想像でき、材料アイコンはレシピカードを検索をしやすくします。また、それらのモジュールは、「レシピ通りに料理を作れるようにする」という共通の目的の達成にも貢献します。
プロダクトが進化するとパターンも進化します。ユーザーがレシピを採点できるようにして、その点数をレシピカードに表示させるかもしれません。カードのレイアウトを改良したり、材料アイコンをわかりやすくしたり、コンパクト版のカードを導入する場合もあるでしょう。パターンのテストを何度も繰り返して、それぞれが連携して目的を果たせるように、言い換えれば、より効果的にユーザー行動をうながせるようにします。
デザインプロセスの早い段階でパターンの目的を明確にしておくと、プロダクトの進化とともにパターンを重複せずに済みます。初めは無駄骨のように思えるかもしれません。何しろ誕生して間もないうちのプロダクトは急速に変化するので、すべてのインターフェースパーツを決めるのは難しいからです。
しかし、本当に主軸となる機能パターンも大きく変化するのでしょうか？ FutureLearnの例で、インターフェースのデザインが3 年間でどう進化したか見てみましょう。
パターンは進化、振る舞いは不動
FutureLearnは2013年にイギリスのオープン大学によって創設されて以来、「ストーリーを語り、コミュニケーションを誘導し、進行を称えることで、人々を学習に導く」というビジョンを保ち続けています。ビジョンの実現には、人々にオンラインコースを発見し、参加してもらう必要がありました。そして学習意欲をかき立てたり、やりがいがあって刺激的な学習体験を提供しなければなりませんでした。FutureLearnでは、このビジョンが最初の機能パターンの土台となりました。
コースはユニット単位で用意され、1つのパートを終えると次に進むというように、直線的なフローが採用されています。インターフェースレベルでは、週単位の構成です。1週間はいくつかのアクティビティに分かれ、アクティビティはいくつかのステップに分かれています。コース進行モジュールは、主軸となる機能パターンのひとつです。学習者はコース間を移動したり、進行状況を確認したり、現在受講中のコースを確認できます。
これらのパターンは3年前に初めてデザインされて以来、いくつか変更されています。スタイルだけでなく、機能やインタラクションも変わりました。しかし目的は、FutureLearnの仕組みのコアなアイデアに結びついており、基本的に同じままです。
FutureLearnのディスカッションスレッドもまた、参加人数の増加とともに少しずつ進化してきました。スレッドのレイアウト、インタラクション、フィルタリング機能が改良されましたが、主な目的はほぼ変わっておらず、学習者どうしがコミュニケーションを取り、学び合えるようにすることを目指しています。
コースの詳細を表示するコアユニットも、3年間で進化を遂げました。ページをスクロールしなくても、より多くのコースを表示できます。それでもやはり、パターンの目的は、「学習者が興味のあるコースを見つけ、受講できるようにすること」から変わっていません。
立ち上げ時期によくあることですが、時間の制約や他の優先事項のため、主軸となる機能パターンは一部しか定義できませんでした。FutureLearnでは、インターフェースと学習機能の進化に合わせて、パターンを重複させてきました。最終的に出来あがったのは、いくつかのコース進行モジュール、様々なコメントモジュール、数種類のコースブロックとコースカードです。パターンの重複は不可避だったのでしょうか？ それとも、少しは回避できたのでしょうか？
チームでパターンを定義、共有していないと、別の宣伝モジュール、別のニュースフィード、別の共有リンクセット、別のドロップダウンなど、似たような目的を果たすパターンを作り直すことになります。そして気づくと、数えきれないほどのプロダクトの表示やドロップダウンメニューが出来あがってしまいます。
パターンは、インターフェースを通じてうながす行動を物理的に具現化したものです。パターンの実行方法、内容、挙動、表現方法は千差万別です（実際、パターンは目に見えるとは限りません。音声で読み上げるなどの方法で具現化することもできます）。
それでも、パターンがうながす主な行動は、プロダクトの目的と、その仕組みのアイデアに由来するため、比較的予測可能な形になります。主なパターンの目的を意識すると、システムの仕組みを理解し、統一性を保ったまま進化させることができます。
− − − − −
noteの機能では表現しにくい画像のキャプションや、発言の引用や脚注などは省略しています。あくまで、書籍の概要としてイメージしてもらえれば幸いです。全貌はぜひ書籍でお確かめください。
次回からは、機能パターンを定義する際に有用なテクニックについて紹介していきます。まずは、パターンマップやインターフェースインベントリーの作成についてです。
では、次回をお楽しみに。
この記事が気に入ったらサポートをしてみませんか？