三井 英樹

 デザインが持つ力を,今回は「レイアウト」という観点で見てみることにします。

 まず,購買システム系でありがちな下記フォームをご覧ください。大別して七項目(案件名,顧客名,納品場所,請求先,特記事項,回答希望日,優先基準)の入力をさせる画面です。

■フォーム1:( は入力必須です )
案件名(*)
顧客名 会社名 (*)  部署名
住所
ビル名   階数
TEL   FAX   担当者    Email
納品場所
(*)
会社名       部署名
住所   ビル名   階数
TEL   FAX   受取人    Email
請求先 会社名 部署名
住所   ビル名   階数
TEL   FAX   担当者    Email
特記事項
回答希望日 (yyyymmdd)
優先基準(*) 特になし   納期優先   価格優先

 おそらく多くの方が,何を入れれば良いのかと目を細めたのではないでしょうか。その理由を,以下の「フォーム2」を見ながら考えてみてください。

■フォーム2:( は入力必須です )
案件名(*)
顧客名 会社名(*)部署名
〒   
住 所
ビル名  階数
受取人Email
電 話 FAX 
納品場所
(*)
会社名 部署名
〒   
住 所
ビル名  階数
受取人Email
電 話 FAX 
請求先
 
会社名 部署名
〒   
住 所
ビル名  階数
受取人Email
電 話 FAX 
特記事項     
回答希望日      (yyyymmdd)
優先基準(*)      特になし   納期優先   価格優先

 多くの方が,このフォーム2のほうが入力しやすかったのではないでしょうか。この二つのフォームの差は,「レイアウト」だけです。入力すべき項目は全く同じですが,並び方だけが異なります。さらに,フォーム1は改行などの処理をブラウザに任せっきりにしているので,内容に反した部分で改行が生じていると思います(ブラウザによって多少異なります)。

 このフォームは,「顧客名/納品場所/請求先」の三つの情報群を骨格とする入力システムですが,住所などはほとんど変化のない情報の塊です。ところが,フォーム1ではそれに気がつきにくく,フォーム2ではテキスト・フィールドがそろって配置されているので予測しやすくなっています。

 人間は,ある程度の情報を扱う場合,まずどれくらいの作業量が待っているのかを事前に知ろうとします。全体像を捉えようとするといっても良いでしょう。その場合に,レイアウトが見やすく成されていると,その予測作業を軽減できます。フォーム2を見た利用者は,細かな入力すべき情報を知る前に,三つの大きなカテゴリーがあることをほとんど考えることなく察知できるのです。そして,入れるべき情報の分類がわかっているので,同じ入力作業量であっても,作業自体が簡潔になったと感じます。

 ここで,「レイアウト」というデザイン要素が,一つの働きをしてくれています。二つのフォームから飛ばされるデータの行き先は全く同じWebアプリケーションです。データベースの構造に違いはありません。同じAPIで処理できます。なのに,ユーザーは異なる印象をもって,この入力作業を終えます。

 この二つのフォームのソースコード上の違いは,大まかに言えば二点です:

  1. 整理された情報の順番
    (担当者や受取人の部分で,人の名前の後にEmailや電話番号などの情報を記入するようにしています)
  2. 改行と空白による見栄えの整理
    (人目で同じ形式の情報の並びを認識しやすいように配置しています)

 ここで,このアプリケーションの価格を考えてみてください。どちらに顧客は高い開発費を払うでしょうか。通常はこのような比較をできる状況にはありませんが,ほとんどの顧客は「フォーム2」を選ぶでしょう。そして,それは実装上は,開発側がほんの少し「レイアウト」という「技術」を学べば,誰だって実現できるレベルのスキルなのです。

 もしも開発費が同じであるならば,「フォーム1」で納品したほうが開発側としては低コストで済むでしょう。しかし,現在はツールの高機能化などによって,開発費は徐々に下がっています。価格競争になることは必至の状況であり,既存の顧客の心をつかみ続けるためには,顧客満足度向上につながる手を何か打たなければなりません。

 こう考えると,「デザイン」という領域が,付加価値を生む新たな土壌と考えやすくならないでしょうか。多くのエンジニアは学生時代に「美術」の成績が良くなかったなどを理由にデザインの学習を嫌いますが,アーティストになることが求められているわけではありません。自分でも使いやすいと思う,ほんの少しの工夫が求められているに過ぎません。

 では,レイアウトをもっと直感的にする方法はないのでしょうか。一つのヒントとしては「色」があります。色分けされた情報が,「分類」という意識を呼び出しやすくさせてくれます。以下のフォーム3はフォーム2と全く同じレイアウトで,色だけを変えてあります。もう少しわかりやすく美しい配色は考えられるでしょうが,フォーム2と見比べてください。

■フォーム3:( は入力必須です )
案件名(*)
顧客名 会社名(*) 部署名
〒   
住 所
ビル名 階数
担当者  Email
電 話   FAX 
納品場所(*) 会社名 部署名
〒   
住 所
ビル名  階数
受取人  Email
電 話   FAX 
請求先
 
会社名 部署名
〒   
住 所
ビル名  階数
担当者  Email
電 話   FAX 
特記事項     
回答希望日      (yyyymmdd)
優先基準(*)      特になし   納期優先   価格優先

 どうでしょうか。「入力しやすい」,あるいは「入力しても良いと思える」ユーザー・インタフェースに感じないでしょうか。配色の際に考慮したのは,色のドギツサ(は少し目にまぶしい)と諧調(段階的な明度差を同じ情報群であることを暗示するのに利用)です。

 データベースの設計上では,これらの画面上には差はありません。しかし,利用者の入力しやすさという観点から見ると,できあがったシステムには明らかに差があります。小さな配慮と思われるかもしれませんが,使われてこそシステムの意味があり,気持ちよく使われてこそ開発者冥利に尽きるというものではないでしょうか。少しの配慮が,次回も頼みたくなるシステム開発に繋がるかもしれません。


基本機能と付加価値の関係

 今回も基本的なHTMLで書ける部分での説明になりましたが,HTMLでさえ工夫次第で利用者を迷わせない画面設計が可能です。ましてや,今後ますます活用されるRich Internet Application(RIA)では,より直感的でわかりやすいものが求められていくでしょう。

 そのときには,「デザイン」の価値が再考され,毎年基本機能に組み込まれていく「付加価値」の部分として,エンジニアにも求められる「技能」になっていく予感がします。


三井 英樹(みつい ひでき)
1963年大阪生まれ。日本DEC,日本総合研究所,野村総合研究所,などを経て,現在ビジネス・アーキテクツ所属。Webサイト構築の現場に必要な技術的人的問題点の解決と,エンジニアとデザイナの共存補完関係がテーマ。開発者の品格がサイトに現れると信じ精進中。 WebサイトをXMLで視覚化する「Ridual」や,RIAコンソーシアム日刊デジタルクリエイターズ等で活動中。Webサイトとして,深く大きくかかわったのは,Visaモール(Phase1)とJAL(Flash版:簡単窓口モード/クイックモード)など。