2つの方向性 ―ユーザビリティ・ファーストとデータモデル・ファースト―

GUIのデザインには2つの方向性が存在すると筆者は考えています。ユーザビリティ・ファーストと、データモデル・ファーストです。この2つは排他的存在ではなく、常に双方の考え方を取り入れながらデザインが進行されるべきであり、また現実に存在するGUIはすべてそのようになっていると思います。

ユーザビリティ・ファーストのGUIデザイン

ユーザービリティとは、「そのGUIを使う人から見て、いかに使いやすくするか」という観点でのデザインになります。場合にもよりますが、プログラマーよりはデザイナーの方が、こちらの分野のデザインを得意とする人が多いように感じます。

ユーザビリティを第一に考えてデザインする場合、私たちはそれを使う人――不特定多数のエンド・ユーザー、あるいは特定の社内業務のツールを必要としているスタッフ・ユーザー――をよく観察し、理解する必要があります。使い手のことを知り、使い方を知ることが、使い勝手の良い道具をデザインする上で非常に重要です。

ユーザビリティ・ファーストなデザインとはどういうものかを考えるための例として、一般の人向けの、ショッピング・サイトのデザインを考えてみましょう。

使い慣れたフォーマットの存在

ショッピング・サイトはすでに多くの人から支持を受けているフォーマットが存在します。

• 検索ボックスで商品名やメーカー名、ジャンル名をユーザーは入力し、それに該当する商品が一覧で表示されます。
• 商品の特徴（色、価格、サイズなど）によってフィルターし、目的の商品にたどり着きます。
• 商品画像をクリックします。
• 詳細ページに遷移し、複数まうぃの商品画像と詳細情報、「カートへ追加する」ボタンが表示されます。
• 十分に商品の詳細情報を吟味して、ユーザーはカートへ商品を追加し、画面の右上にあるショッピングカートのアイコンをクリックします。そして決済画面へ…。

こうした行動はすでに私たちの体に染みついています。また、ショッピングサイトを始めてみる人であっても、おそらくはそれほど迷わずに操作を行える程度に洗練されたフォーマットです。ですから、同じ目的のサイトを作る場合には、なるべくこれらの見せ方から外れないようにすることが、「誰にとっても使いやすい」を実現する上で非常に重要になります。

段階的な改善プロセス

ものを作る人は誰でも、そこにオリジナリティを付け加えたいという色気を出してしまいがちです。例えば次のような。

• 商品の数量を、スライダーで選択できるようにしたらどうだろう・・・？

しかし、現実には、数量のボックスの左右にプラス・マイナスアイコンを設置する方が、はるかに操作は簡単であったりします（水をミリリットル単位で注文するような場合以外は！）。

いくつかの実現方法を考えたうえで、「本当にユーザビリティに資するのはどちらだろうか？」ということを考え、私たちはボタン・テキスト・画像などの既存のパーツを組み合わせながらGUIをデザインします。

時には使いづらいというユーザーのクレームを引き受け、また時にはロギングツールから得られたユーザー行動を分析したうえで、使いやすさを段階的に改善していくことも、ユーザビリティ・ファーストなデザインの重要な領分になります。

一方で、全く異なる考え方をするのがデータモデル・ファーストのGUIデザインです。こちらはデザイナーよりもプログラマーの方が得意である傾向がより顕著だと思います。

データモデル・ファーストのGUIデザイン

データモデル・ファーストとは、ドメインを表現するデータモデルをより直接的にGUIに落とし込む方針です。この考え方のメリットは、そのシステムの在り方の根幹をなす知識が積極的に見た目のうえで表現されることと、それによる構造のわかりやすさです。

同様に、例えば、次のようなデータを作成するためのUIはどのような形になるでしょうか？

type ShoppingUser {
  email: string
  name: string
  age: number
  phoneNubmer: string
  address: string
  creditCards: CreditCard[]
}

当然のことながら、「メール」「名前」「年齢」「電話番号」「住所」「クレジットカード情報」を入力するフォームになることでしょう。

保守する上での分かりやすさ

デザインを直接的に表現したシステムは、ある意味で単純明快であり、また依存するバックエンドのAPIやテーブルの数も非常にシンプルなものになります。フロントエンドとバックエンドが「密結合」である、という言い方をすると非常にプログラマーからの評判が悪そうですが、厳密にこの方向性を適用している限り、バックエンドで1か所の修正を行えば、フロントエンドでも同様の1か所の修正を行うだけで済むことでしょう（例えば、上記の ShoppingUser にプロパティが1つ増えたならば、フォームの要素を1つ増やす、といった具合に）。

まとめ

これら2つの方向性は、それぞれ人によって、また組織内での役割によって得意・不得意があるものであり、複数人でデザインについて議論することは、これらの方向性をうまく止揚させるのに役立つ場合があります。デザイナーとプログラマーのそれぞれが画面デザインについて口を出すことは、この意味で時として重要です。

一般に、一方についての知識を持ちすぎるともう一方についておろそかになるということがよく起こりますが、デザインの2つの方向性についても同様のことがよく起こります。（一人でデザインを黙々と作っているとよくわからないものが出来上がりがちな原因もこのあたりにあるのかなと考えています。）