長谷川 裕行 （はせがわ ひろゆき）
有限会社 手國堂 代表取締役
http://www.hirop.com/
テクニカルライターとして活躍。プログラミングに関する著書多数、DB Magazineなどにも多くの記事を提供している。 |
業務アプリケーションでは、基本的なフォームデザインがほぼ一定しているため、あまり奇抜なデザインとなることはありません。しかしそれでも、ユーザーに扱いにくいと感じさせたり、なぜか間違いを誘発してしまうアプリケーションが存在します。
その原因として、ユーザーの視線の動きを考慮していないことが挙げられます。ボタンの配置やメッセージも重要な要素ですが、視線の誘導もまた、ユーザーインターフェイスにとって重要な要素です。
今回紹介する画面は、サンプル・アプリケーションから確認できるようになっています。画面のキャプション（説明文）の後ろの(Form1)などが、対応するアプリケーションのフォーム名です。
既に何度も書いてきましたが、「見た目」はソフトウェアの性能を決める重要な要素です。「見た目より内部処理」と思う人も多いと思いますが、結果的にアプリケーションの使い勝手は、その大半が見た目――つまり外観に依存します。
- デザインは基礎設計から始まっている -
人間がコンピュータを扱うとき、真っ先に情報を受け取るのはディスプレイ――画面上の表示です。それは、当然目から入ってきます。視覚によって情報を受け取り、解釈と判断を行って手を動かします。
コンピュータとその上で動作するプログラムに「入力と出力」があるように、人間にも入力と出力があります。一般に、入力は視覚であり、出力は手と指の動きです。コンピュータは勝手に判断して動いているのではなく、人間の側の
入力（画面を見るまたは読む）
→処理（解釈と操作の判断）
→出力（キーボードやマウスの操作）
という一連の動作と相互に補完して動いているのです。
- すべて「目」から入ってくる -
人間の操作によってプログラムの側が得た情報を、プログラムが内部でどのように処理して出力するかが、プログラミングの最も重要な部分――ということに誰も異存はないでしょう。
しかしまた、プログラムの出力から得た情報を人間がどのように受け取り、操作として出力するかも、それと同様に重要なことです。ユーザーインターフェイスの重要性はここにあります。
一般的な業務用アプリケーションの場合、人間の側が受け取る情報のほとんどすべてが視覚情報となります。文字によるメッセージ、ボタンやアイコンの色・形・位置など、ユーザーに情報を伝えて次の操作を決める要素は、すべて目から入ってきます。
視覚には動く視覚と動かない視覚があります。フォーム上のコントロールが動くという意味ではなく、それらやそれらに表示されたメッセージを見ている「目が動くかどうか」という意味です。
- 視線の移動とユーザーの判断 -
基本的に、広いウィンドウ内のコントロールを順に見ていく限り、ユーザーの視線は常に動きます。が、その動きが一定であったり規則的であれば、そこから情報を得ることは比較的容易です。しかし、ユーザーに不規則な視線の移動を強いると、的確かつ迅速に情報を得ることは難しくなります。
コントロールの大きさや色は、処理のたびに大きくかつ不規則に変化しません。同じフォームを操作している以上、基本的に一定です。そのため、コントロールを操作の順に眺めたり、全体を見渡して目的のコントロールを探すことは（配置や文字列が適切であれば）比較的容易です。
が、本来順に追っていかなければならない要素の並びが不規則だと、ユーザーの視線をいたずらに動かすことになり、思考を遮ってしまいます。するとユーザーは適切な判断をするのが難しくなり、誤操作や誤入力を招くことになります。そこまで行かないまでも、「操作するとやたらと疲れる」などと言われるでしょう。
- 視線でユーザーを導く -
視覚は思考と密接な関係にあります。私たちは見た順に物事を認識し、認識した順に考えます。それは我々が育ってきた環境の中にある本や放送といったメディアが時系列的な制約を負っていることと、無縁ではないでしょう。
これは、「前→後」ヘと向かう一方向のベクトルを持った、シーケンシャルな物事の捉え方です。物を考える場合にも、この時系列的な物事の捉え方が影響を及ぼしています。
ユーザーが「次に何をすればよいのか」を知り「ここを操作すればどうなるのか」を予測できるようにするには、ユーザーの視線を適切な方向に自然と導かなければなりません。これを「視線誘導」と呼びます。
大きさや色という静的な視覚に対して、コントロールの並び順は「動的な視覚」の問題であると言えます。「データの入力順とコントロールの配置」を考えてみましょう。
データの入力画面は、処理結果を眺めるだけの画面より重要です。入力する人間のものの捉え方を自然に反映できるようにしなければなりません。顧客や得意先などのマスターテーブルにデータを入力する場合を例に、入力順について考えてみます。
- フィールドの並び順 -
顧客や得意先などのテーブルは、基本的に住所録そのものです。会社や組織の基本的な情報の構成要素は、例えば
| 社名 |
読み |
郵便
番号 |
住所 |
電話
番号 |
FAX
番号 |
担当者 |
備考 |
といった感じになるでしょう。個人の情報なら、「社名」が「氏名」に変わったり「担当者」フィールドが不要になったりはしますが、基本的な構造は変わりません。
マスターテーブルに新規データを追加する場合の入力順ですが、基本的には
フィールドの並び順そのまま
で構いません。
という順序で入力することになります。
- テキストボックスの順序 -
では、これを行うフォームでは、コントロールをどう配置すればよいでしょう？頭の中でフィールドの順序や項目名の順序を考えていても、いざフォームのデザインを行うとなると、その配置に戸惑ってしまうことがあります。
縦一列なら、画面１のようにすることが考えられます。データフォームウィザードでデザインすれば、このようにフィールドの並び順と同じ順序になります。入力順も、当然「上→下」です。
ただ、ウィザードで作ったフォームはテキストボックスのサイズが同じになってしまうので、画面２のようにサイズを調整した方がよいでしょう。この場合、通常はテキストボックスの右側を操作してサイズを変更します。
画面１：ウィザードを元にして作った一般的な入力フォーム(Form1)
画面２：テキストボックスのサイズを調整したフォーム(Form2)
- 並び順は思考の順序 -
このフォームで情報を入力すると、自然な流れに沿って違和感なく作業できるはずです。これは、人間が一般的な会社や組織の基本的な情報を、先に示した順序に沿って把握しているからです。
試しに並び方を、画面３のように
郵便
番号 |
FAX
番号 |
社名 |
担当者 |
得意先
ID |
住所 |
電話
番号 |
などとしてみれば、途端に入力し難くなってしまうはずです。
なぜ前者の順序だと自然に入力でき、後者の順序だと入力が難しくなってしまうのでしょう?
「どう考えても自然じゃないよ。名前の次に住所を入力するのが常識じゃないか」と思った方も多いでしょう。そう、「当たり前」「自然」なのです。その当たり前のことを、なぜ私たちは当たり前だと感じるのでしょう？
画面３：並び順を変更すると入力しづらくなる(Form3)
- 自然な順序とは？ -
日常の会話を考えてみましょう。通常私たちは、「住所・氏名」と表現します。住所が先で名前が後です。しかしデータ入力では、「社名（氏名）・住所」の順で違和感を感じませんでした。
まずこのフォームが「得意先の基本情報を入力する」ためのフォームであることが、大前提となります。このフォームを開くとき、ユーザー（操作者）は「得意先の情報を入力しよう」という気持ちになっています。
人間が特定の人物や組織を特定するための文字情報は、言うまでもなく「名前」です。コンピュータでは識別記号として番号や英数字が使われることがありますが、人間は「固有の名前」で固体を識別します。
そのため、真っ先に「得意先の名前」（「社名」フィールド）を入力するのです。これによって、「これからどの会社の情報を入力するのか」が、実はユーザーにも明確になります。人間は、対象の実体を「名前」によって抽象化しているのです。
すると残りの「住所」や「電話番号」などは、得意先という実体の属性であり、「得意先の名称」というキーに付随する情報であるということになります。
- 作業の種類と思考の順序 -
手紙を出す場合ではどうでしょう？
普通は「郵便番号・住所・氏名」の順になります。これは、既に手紙を出す先が明確になっているという了解の上で、住所と名前という情報を捉えているからなのです。
「手紙を出そう。さて、誰に出そうかな？」などと考えることはありません。「ＸＸさんに手紙を出そう」と考えます。つまり暗黙のうちに
氏名 住所 郵便番号 氏名
…の順で考えているのです。これは、日本の郵便の宛て先の書き方が慣例的にそうなっていることも理由の１つです。欧米では
名前 住所（番地・市・国） 郵便番号（Zipコード）
となります。
同じ情報でも、作業の種類によって捉え方の順序は異なるのです。
- 住所データと属性 -
「属性」という言葉を用いました。英語でいうとProperty(プロパティ)です。ＶＢのオブジェクトにあるプロパティと同じで、郵便番号、住所、電話番号などはすべて１件の得意先のプロパティなのです。もちろん得意先名（名称）もプロパティの１つですが、それはオブジェクト名と同じで、ある１つの（１軒の得意先という）オブジェクトを特定するためのキーです。
属性の各要素を見てみましょう。例では「住所」と１つのフィールドにしましたが、多くの場合
住所１・住所２
あるいは
都道府県・市区町村・番地・室番号
どと複数のフィールドに分解されるでしょう。この場合、これらは統合して「住所」を表わすため、不可分な要素となります。単に、検索や分類、印刷など処理の都合上、別フィールドとしているに過ぎません。なぜなら、一般に住所は
１つの入力域に一気に入力する方が楽
だからです。
さらに「郵便番号」と「住所」も不可分であり、１組の情報となります。このとき、「郵便番号→住所」という順序が自然なのは、私たちが郵便物の表書きなどでそういった表記に慣れているためです。これも、海外では逆順に捉えられるのが普通です。
- 住所項目の並び -
例に示したフォームでは、「郵便番号→住所→電話番号…」の順になっています。「電話番号」が先ではいけないでしょうか？
住所はその情報のキーである「名称」（例では「得意先名」）と１対１に対応する情報です。「目指す会社の住所は１件につき１つしかない」というのが前提です。本店・支店はそれぞれ別のキーとなります。中には、１つの会社・１つの建物に複数の番地が振られている場合もありますが、それでもそのうちのどれか１つ（事務部門のある番地、登記された番地など）で会社の場所を特定できます。
ところが電話番号は、1つの会社に複数登録されている場合があります。フォームでは業務に必要な番号１つだけしか入力しなくても、実際には電話が１本だけの会社はあまりないでしょう。電話番号では、キーとなる会社を特定できないのです。FAX番号も同じです。
さらに「担当者」ともなれば、世の中に山田さんや田中さんはわんさかいます。担当者名で会社を特定することは不可能です。電話番号よりも範囲が曖昧になります。 |
|
- 輪を絞り込むように… -
「範囲が曖昧」という表現を使いました。「自然な入力順」とは「物事を認識する際の各要素の順序」であり、それは
キーとなる名称
→地域を特定する郵便番号
→場所を特定する住所
→部署を特定する電話番号
→人物を特定する氏名
という具合に、後ろにいくほど曖昧になり、曖昧になるほど対象範囲を絞り込んでいることになるのです。
特定のデータに付随する情報を、輪を縮めて絞り込んでいくような感じで認識しているのです。
- 「自然な順」にも理由がある -
こう考えれば、
郵便番号 FAX番号 社名 担当者…
といった並びが不自然に感じられる理由も、察しが付くはずです。
郵便番号から一気に絞り込まれたFAX番号、そこからキーとなるはずの社名、絞り込まれた担当者…と、「行ったり来たり」「広まったり狭まったり」の感覚が、ぎこちなさを感じさせるのです。こういった順序で情報を捉えようとすると、人間の頭の中は混乱してしまいます。
１つの情報を構成する個々の要素には意味があります。それらの関係を把握し、人間が各要素から全体を認識する過程に沿って提示するようにしなければいけません。「自然だから」という理由で何気なく並べている入力順にも、実はちゃんとした「理由」があるのです。
「見る」ことは「考える」ことです。入力順とコントロールの配置次第では、ユーザーの考えを簡単に混乱させてしまいます。逆に言えば、うまく設定することで、ユーザーの作業をスムースに導ける――ということです。
- 目的と並び順 -
「入力」という作業を前提にして考えましたが、これが「得意先の電話番号を一覧するための処理」だったらどうでしょう？
ユーザーの頭の中には「電話番号を知りたい」という気持ちがあります。すると、画面４のようなレイアウトが自然な感じになります。
画面４：電話番号検索の結果表示用フォーム（Form4)
「電話番号を知りたい」ということは「目指す得意先に電話をかけたい」または「FAXを送りたい」ということであり、電話で用件を伝える相手は「担当者」です。そのため
社名→電話→FAX→担当者
という並びが妥当だと言えます。ここで「住所」も知りたいという要望に応えるなら、コマンドボタンをクリックすることで別のフォームを開いて提示するのがよいでしょう。電話番号を知りたいという目的からすれば、住所はあまり重要ではない情報となるのです。
- 視線の遮断は思考の遮断 -
住所を知るということが、重要ではない付加的な機能である点は重要です。住所を表示するコマンドボタンを画面５のように配置したらどうでしょう？
画面５：コマンドボタンが思考の流れを遮ってしまう(Form5)
電話番号を知りたいのに、名称からレコードを特定して視線を右に移動すると、目指す電話番号や担当者名の前に[住所表示]のボタンがあり、行く手を遮っている…という感じを受けます。
視線の移動はそのまま思考の順序であり、作業の流れを決める大切な要素です。横書きが基本のコンピュータでは、視線は基本的に「上→下／左→右」という順序で移動します。その流れに沿う形で、コントロールも配置されなければなりません。
「住所を表示させる」という付加的な機能を流れの途中に持ってくると、ユーザーの目的に沿った思考の流れを遮ってしまうのです。
- 右揃えと左揃え -
「視線の移動」という観点からは、単に入力順だけではなく「入力箇所の先頭を、できる限り揃える」ことも大切になってきます。
画面６のようにテキストボックスの右端を揃えようとすると、カーソルが移動するたびにユーザーの目は左右に大きく振られてしまいます。特にテキストボックスを縦１列に並べて上から下に向かって入力させるような場合は、デザイン上の都合で、電話番号とFAX番号の小さなテキストボックスを1行に並べるような場合を除き、できる限り先頭位置を揃えるようにしましょう。
画面６：入力箇所の先頭がジグザグだと、ユーザーは疲れる
視線の動きは、そのままユーザーの思考の流れと一致します。そして、うまくユーザーの視線を導くための準備は、データベースデザインから始まっています。
- 思考の流れに沿った順序を -
ここでは基本的な情報を例に考えましたが、コントロールの並び順の問題は、日々の業務で操作する「商品の販売状況」などではもっと顕著です。
人間は
4月16日、大村商会へプリンタを３台販売した
といった形でその情報を把握します。間違っても
プリンタを16日、販売した大村商会へ４月３台
などと、破綻した思考はしません（できの悪い翻訳ソフトみたいですね）。
当然、入力順も先に示した自然な思考に従うべきです。自然な入力順とは、ユーザーの思考の流れに沿った項目の並び順であり、それを乱すことは「入力の邪魔」以外の何者でもありません。
- 外観と機能の一致 -
コントロールの配置を決めるには、ユーザーの思考の順に従い、対象となる情報を人間がどのような順序で認識しているかを意識することが大切です。
コントロールのTabIndexプロパティを設定すれば、タブオーダーを変更して入力順を自由に変更できます。が、画面をぱっと見たユーザーは「上→下／左→右」の規則に従って視覚的に入力順を理解するのです。内部の設定などまったく意味がありません。プログラムの内部でちゃんと処理しているということと、それを扱うユーザーが操作を正しく認識していることとの間には、実は何の関連もないのです。
視覚的な入力順と実際の機能上の入力順とを、合致させることが大切です。こういった見た目から受ける操作感と実際の操作の結果とが同じである状態を「操作と機能のリアリズムが成立している」と言います。
そのためには、ハードウェアやソフトウエアのこと以上に、生身の人間のことを考えることが重要になってきます。
- テーブルデザイン時から始まっている -
データ入力用のフォームは、データフォームウィザードで行うのが最も簡単です。ADOとデータベースとの接続やレコードソースの指定、フィールドとテキストボックスの関連付けなどが、すべて自動的に行われます。
但し、先の画面１でも分かるように、フォーム生成後にテキストボックスのサイズや位置を調整する必要はあります。また、項目名のラベルには元になったレコードソースのフィールド名がそのまま使われるため、一部手直しが必要な場合もあるでしょう。
すると、データの入力順も、元になったテーブルやクエリーのフィールドの順序がそのまま反映されることになります。先に説明したように、生成されたフォームのデザインを変更し、並び順や入力順を変更することは可能ですが、それ以上に
元のデータベースで
フィールドの並び順を適切に設計しておく
ことが大切です。そうすれば、入力順の手直しは最小限で済むはずです。
テーブルの構造はエンドユーザーには見えない部分なので、結構適当にデザインしてしまいがちです。が、しっかりした構造のアプリケーションを設計するなら、最後の仕上げまで考えて最初から丁寧にデザインするよう心掛けましょう。
- 紙の帳票と画面デザイン -
コントロールの配置と入力順はユーザーが自然に考え、操作できる順序にすることです。
もし手作業で行っていた処理をプログラムに置き換えるのなら、手作業で行っていたときの帳票類と同じレイアウトにするのが一番でしょう。それまで行っていたのと同じ手順をディスプレイ上で行えばよいので、ユーザーは違和感なく操作できます。
但し、紙の帳票には紙の帳票なりの、手書きのための工夫というものも施してあります。例えば、いくつかの固定された選択肢から１つを選ぶような場合、手書き帳票ではその選択肢が予刷されていて、必要な項目を○で囲むなり、チェックするなりして選択するようになっているはずです。
これをそのままコンピュータでの処理に受け継いでしまっても、無駄な視覚情報が増えてユーザーを惑わせるだけです。チェックボックスやオプションボタンを使う他、項目数が多ければコンボボックスを使うことも考えられます。
コントロールのサイズ・位置・色、メッセージ、入力順など、ユーザーインタフェイス設計の基本事項を紹介してきました。これらを考慮して使い勝手のよいアプリケーションを作るための留意点を、簡単にまとめておきましょう。
- 共通認識が大前提 -
外に向かって半開きになっているドアの絵がプログラムの「終了」を表すように、ある事柄を別の受け手に馴染んだ事柄に置き換えて表現したものを「メタファ」（暗喩）と呼びます。
Windows上のウィンドウやボタンなども、すべてメタファです。つまりフォーム設計の成否は、メタファをどのように利用するかにかかっているのです。
メタファを利用するには、送り手（作者）と受け手（ユーザー）との間にメタファとして使われたものに対する共通認識が存在しないと、まったく意味を成しません。それどころか、違う意味に取られてしまうことにもなりかねません。
コマンドボタンをクリックするとくぼんだ表示になり、何らかのアクションが実行されます。これは、画面上の画像が現物のボタンを模しているからに過ぎません。「ボタンをドラッグするとアプリケーションが終了する」といった仕様になっていれば、ユーザーは混乱してしまうでしょう。「ボタンは押すもの」という共通認識があるためです。
同様に、フォルダアイコンの意味は、実物のファイルフォルダというものの存在と、その機能を知っていなければ理解できません。事務系のビジネスマンはこの意味をすぐに理解できますが、文書の扱いに慣れていない人にはピンとこないでしょう。
- 高度な技術はユーザーに見えない -
多くの場合ユーザーは、アプリケーションの内面の性能など気に止めません。アプリケーションの検索速度が飛びぬけて高速であっても、内部に思いもよらない優れた仕組みを潜ませていても、おそらくほとんどのユーザーがそれに感激したり、誉めてくれたりはしないでしょう。
もちろん、「外観が良ければ誉めてもらえる」というものでもありません。使う側には「良いものを作って当たり前」という感覚があります。従って、実のところ多少処理速度が遅かろうが、内部の仕組みに幼稚な技術しか使っていなかろうが、ユーザーはそんなことを見抜けないのだから安心して大丈夫…ということにもなります（お薦めはしませんが…）。
しかし、外観は隠せません。見た目の悪いアプリケーション、使い勝手の悪いアプリケーションは、その中でどんな高度な技術が使われていようと、ユーザーからボロボロにけなされたりするものです。
- 使い勝手は数値化できない性能 -
「見た目」という言葉を使ってきましたが、本当の問題は「使い勝手」なのです。いかに使いやすいかが、最も重要です。もちろんその中には、（あまり関心を抱いてもらえない）内部の機能・性能も含まれるでしょう。
「機能・性能」と表現していますが、厳密に言えば「機能」は「目的に応じた働き」つまり「できる仕事」のことであり、「性能」はその仕事がどれだけできるかを示す「仕事の能力」のことです。
外観を含めた「扱いやすさ」「使い勝手」という部分は、機能ではなくアプリケーション全体の「性能の一部」だと言えます。
「あれができる」「これはできない」といった機能や、「速い」「大容量」など能力的な指標である性能は、数値的にその優劣を判断できます。一万件の検索に10秒かかるより、5秒で済む方が高性能です。
ところが使い勝手という要素は、数値化して優劣を付けたりはできない、非常に感覚的な部分です。そのため、大多数のユーザーが納得し、快適に使える外観をデザインすることが、重要になってくるのです。
サンプルプログラムについて
今回のサンプルex23.exeは、本文中で紹介した各画面を表示するフォームの集合です。[Form1]などのコマンドボタンをクリックすると、該当するフォームが表示されます。
 VBプロジェクトファイルのダウンロード
(LZH形式 10.4KB) |
