UIにもデザインパターンってあるのだろうか？(2021.10.04追記)
先日社内でUIデザインの勉強会のようなものがありまして、エンジニアから「UIにもデザインパターンのような設計手法はあるのか？」と質問をうけました。
即答できなかったので宿題になりました。まずは、恥ずかしながらデザインパターンというものを全然知らないので、そこから調べます。
エンジニアの言うデザインパターンってなに？
注！以下は、プログラミングの素養を持たない人間が、書籍「オブジェクト指向における再利用のためのデザインパターン」と「増補改訂版Java言語で学ぶデザインパターン入門」の第1章だけを読んだ浅い理解です。
・デザインパターンとは、様々なプログラムで再利用可能な汎用的な設計パターンのこと。
・オブジェクト指向プログラミングにおけるGoFデザインパターンが有名。
・ソフトウェア設計における自分の経験を他人が再利用できるようにするための記録、経験や内的な蓄積。
「それぞれのパターンは我々の身の回りで何回も起きる問題、および、それぞれの問題に対する解法のポイントを記述している。そこでアレわれは、これらの解法を何万回でも使うことができる。同じ問題に対する同じ解法を何度も何度も最初から考え直さすに済むというわけだ」Christopher Alexande
役割と目的「設計者は適切な設計により早く到達できる」
・成功した設計やアーキテクチャの再利用
・新しいシステムの開発者が簡単にアクセスできる
・再利用を可能にする代替案の選択、あるいは再利用似弊害となる代替案の排除
・既存システムの文書化、保守性の向上
４つの基本的な構成要素をもつ
①パターン名
カタログを開発する上でのもっとも重要な作業の１つ。名前をつけることで用語としての語彙が増え、高い抽象レベルで設計が可能になる。
②問題
パターンを適用すべき問題とその文脈の説明。
③解法
設計の要素、関連と責任、協調関係の記述。特定の具体的な設計・実装の記述はしない。
④結果
パターンを適用する歳の結果やトレードオフの記述
設計で何度も何度も用いられてきた良き解法に名前をつけ、カタログ化し、開発者同士の共通言語になったものをデザインパターンと呼ぶようです。
デザインシステムやスタイルガイドは似てそうだが目的が違う
デザインシステムとは何か ｜ ひらくデザイン ｜ 株式会社コンセント
このように「名前」がつき「カタログ化」され「共通言語」となったUIのパターンといえば、スタイルガイドラインやその先のデザインシステムが当てはまりそうです。
スタイルガイドとは元々は統一した言葉遣いを規定する手引きを指し、デジタルプロダクト開発の文脈ではデザイナーやデベロッパーが設計・実装にあたり従うべきルールがやガイドラインをまとめたものです。
デザインシステムとは、デザインの原則・概念・基準が明文化されたガイドライン、それに従ってプリセットされたUIコンポーネントとその実装コード、開発キットや配布プラグインなどで構成されており、「何を良いデザインとするか」の基準と「どのように実行するか」の手段がセットで示されています。
両者ともコンポーネントの再利用による工数削減・共通言語化によるコミュニケーションコスト低減が謳われ、結果的にローンチスピードが速くなり、よりサービスやプロダクトの改善サイクルを早めることができる、と言われています。
つまり役割と目的としては、開発者を体験設計に集中させ、ユーザーにより良い利用体験を提供することにあります。
デザインシステムの代表例である「Material Design」（2014年, Google）もガイドラインサイトの一番目立つところで謳っています。
Materialは、オープンソースコードに裏打ちされた設計システムであり、チームが高品質のデジタルエクスペリエンスを構築するのに役立ちます。
UIコンポーネントがそれっぽいが、UIはモジュール化された部品だけでは成立しない
スタイルガイドやデザインシステムそのものは、デザインパターンとは目的が違いました。(前者の目的はUX向上のため、後者の目的は設計のため）
UIにおける設計のためのパターンとは、デザインシステムに含まれるUIコンポーネントがそれです。
例えば前述のMaterial Designではプラットフォームごとに、ボタンやチェックボックスのようなフォームパーツの他、ナビゲーションドロワーやメニュー、テキストリスト・画像リスト、、、と20個前後のコンポーネントが定義されています。それぞれ見た目サンプル、原則に基づく使用法、使い所の適切不適切の事例と解説、プラットフォームをまたぐ場合の対応方法などが詳細に書かれています。コンポーネント名称は一般的に使われる範囲で示され、かつ他のプロダクト・サービスとも方言程度の差があるのみです。
しかしながら、UIはパーツパーツをモジュラブルにつなげただけでは成立しない特性があります。
それはUIはUX設計の手段の１つであることに起因します。そしてUX設計というものは多層構造でできているからです。機能要件・コンテンツ要求のアウトプットとしてのインタラクションと情報モデリング、それをインプットした情報設計・動線設計、その結果として視覚情報・ビジュアルとしてのUIが浮き上がってきます。
UIコンポーネントの部品単体ではUX設計をしたことになりません。
有名な【キャンセルのキャンセル問題】
インタラクションや情報設計を省いてパーツをだた使うとどうなってしまうのか、有名なエピソードとして「キャンセルのキャンセル問題」があります。
例えば編集画面で入力を中止・破棄・中断などの破壊的操作を行うときに、実行確認をするダイアログが出てくると思います。
上記の画像のように「投稿内容をキャンセルしてもよろしいですか？」との問いに対し、回答の選択肢は「キャンセル」と「OK」になっていた場合（おそらくダイアログコンポーネントの汎用的な選択肢)、これを見たユーザーはOKは破壊的操作を実行するのか、破壊的操作のキャンセルを実行するのか、判断つかなくて混乱しちゃうよねという話です。
アラートダイアログは、ユーザーが意図せず異常フローに進行する際にその是非を問うためのモーダルなUIとして使われます。ではどのような改善策が考えられるか。
・ 問いや選択肢の文章を、操作後の実行内容が予測できる表記にする
・選択する可能性が高いボタンは右側に、キャンセル系のボタンは左側に配置する（ガイドライン規定遵守）
・ ユーザーは意図してキャンセルしたいのだから、ダイヤログではなくてアクションシートを使う
など回避方法はいくつか考案され論議されていますが、いずれもユーザーの体験を阻害しないために、情報設計・導線設計・インタラクション設計を検討したうえでの改善策になっています。ただレゴブロックのように部品として組み合わせていると、ユーザー視点が抜け落ちてしまうことがあるよ、という教訓でした。
※ Material Designでも「ダイアログは意図的に中断するため、慎重に使用する必要があります。」としっかり但し書きされています。
まとめ
・プログラミング言語のデザインパターンにあたるような、モジュラブルなUIデザインパターンは存在しない
・部品としてのUIパターンはあるが、UX設計は多層構造のため部品単体で成立させることができない
良いUIとは何だ？と聞かれたときの答えの一つに「ユーザーが見慣れてるUI」というものがあります。Material DesignやAppleのHuman Interface Guidelineでは、ユーザーが日常的に見慣れているAndroidやiPhoneのUIが一式になって定義されています。プログラミング界隈のデザインパターンのような定石ではありませんが、それに近しい存在ではあるので、UIデザインの際に大手のデザインシステムを参考にするのは非常に良い手だと思います。
追記 2021.10.04
Twitterで「ありますよ！！！」と推しコンテンツをご紹介いただいたので、追記します。
ソシオメディア社のUIデザインパターンと、オライリーの書籍「デザイニング・インターフェース 第2版」（通称オシドリ本）です。
ソシオメディア | UIデザインパターン https://www.sociomedia.co.jp/category/uidesignpatterns
オシドリ本は2011年発行のため紙の書籍は入手しにくいですが、PDFで電子版があります。原典なら2020年に第3版もでてます。
発端の質問の背景から、デザインパターンあるよ！ってキャッキャウフフする前の整備に重きを置いてしまい、こんな端切れの悪い内容になっていることを反省するばかりです。Twitterで推しコンテンツとしてご紹介いただけたこと嬉しかったです。ありがとうございまた。
参考サイト
- UIデザインと守破離の精神
- キャンセルのキャンセル問題から考えるダイアログデザイン
- https://goodpatch.com/blog/dialog-design
- 矢沢久雄の早わかりGoFデザインパターン(1)
- Human Interface Guidelines 日本語訳