三井 英樹

 今回取り上げるのは,ほとんどのユーザーが読んでくれないのに,用意しなければならない“悩ましい”ユーザー・インタフェース(UI)部品――「(長めの)文言」――すなわち,注意事項などの説明文です。

 どんなシステムであろうと,熟練ユーザーのみを対象にしない限り,何かしらの「説明文」は必須です。RIA(Rich Internet Application)の場合も例外ではありません。特に,RIAの「わかりやすさ」や「直感的に操作できる」という特性を活かせば活かすほどユーザー層が広がるので,「万が一」のためにも何かしらの「(長めの)文言」を表示する必要性が高まります。

 この課題に対する秀逸な解決法を,全日本空輸(ANA)の「ANAパスポート」を例に説明してみましょう。日程/出発地/到着地の三情報を選択して,「空席照会」をクリックしたときに表示される「ご注意/ご案内」パネルに注目してください。


ANA:Flash版予約【2006.7現在トップページからリンクあり】

 航空券は安いものではないので,販売に関して様々な情報を提供する必要があります。例えばキャンセルに関しての情報など,販売側は毎回でも伝えなければなりません。

 なぜ,この「必須」の情報提示が“悩ましい”のでしょうか。それは,ほぼ確実に「読まれない」からです。それをわかりつつ,「伝えているということがわかる実装」をしなければならないので,作り手にとって悩ましいのです。

 おそらく,これは純粋なプログラミングとは,最もかけ離れたテクニック(技術)と言えるかもしれません。

 通常のプログラミングの世界では,「データを表示する」=「必要なデータである」=「表示されたものをユーザーは読むべきである」という論法がそれなりに正論として通用していると思います。特にイントラネットのシステムで,表示されるメッセージを読まないで誤操作してしまった場合,「読まないほうが悪い」という理屈が“かろうじて”通ります。しかし,コンシューマ相手のB2C型のWebサイトでは,そのような理屈をユーザーに押し付けるわけにはいきません。

 様々な製品についてくる「取扱説明書」や,パソコンが出す致命的なエラー・メッセージですらユーザーは読んでくれないものです。とはいえ,読んでくれないことの良し悪しを議論していても,ビジネスは進みません。読んでくれないのが一般的であるなら,それを前提にシステム開発を進めるべきなのです。

説明パネルが上下することで,ユーザーの関心をひく

 「ANAパスポート」が秀逸なのは,人の感性や「気付き」を利用した,文言表示の仕組みを実装しているところです。下図は,その「ご注意/ご案内」パネルがどのように動くかを示したものです(この図だけではうまく説明できませんので,ぜひ実際に触ってみてください。背景画面が右から左にスライドすると,「ご注意/ご案内」のパネルが上に「ピョコッ」と飛び出して,ゆっくり下がっていきます)。


「ご注意/ご案内」パネルの上下の動き

 何が工夫されているのかを,四段階に分けて考えてみます:

  1. 【注目させる】
     このシステムは,左方向に画面がスライドして,右へ右へとユーザーをナビゲートするのが基本の動きになっています。そこに,縦方向のオブジェクト(「ご注意/ご案内」のパネル)が登場します。人間の視点は基本的に通常とは異なるものに注がれるので(異物に対する防衛本能だと思います),いや応なしに目立ちます。多くの人が「何だろう?」と視線を注ぐでしょう。
  2. 【わからせる】
     このパネルは,少し表示スピードを落として「何」であるかを知らせます。この何気ない動作により,それが「注意」や「案内」であることを,注意内容を読まなくても伝えています。
  3. 【隠す】
     次に,パネルを隠してしまいます。理由は,どうせ読んでもらえないから,そしてスペースの関係で他の操作の邪魔になるからです。通常なら表示し続けるべきものを,存在を知らせればもう良いと言わんばかりに隠すところが革新的でした。さらに,隠すスピードは出現のスピードよりも速くしています。この時点では背景画面のスライドは終了しているので,そのスピードも目を引きます。「もう少し見せてよ」という気持ちを抱くユーザーもいるでしょう。
  4. 【促す】
     そして,「ご注意/ご案内」と書かれたタブの部分だけを残して,文言は完全に隠されてしまいます。しかし,この画面に来るときにクリックした「空席照会」というボタンと,このタブはほぼ同じ色です。タブをクリックすれば何か動き出すであろうことは容易に予想できます。というより,同系色の色を使うことによって,「クリックすれば何かがおきる」ことが“ユーザーに刷り込まれた”と言ってもいいかもしれません。おそらく,もっと読みたいと感じたユーザーは,なんの疑問もなく,このタブをクリックして注意事項を読むでしょう。

 いかがですか。以上のことを,作り手が計算づくで実装しているなんて信じられない方もいるかもしれません。「自分はちょっと気になった程度で記憶に残っていない」と思う方もおられるでしょう。

 でも,優れたUIとは,本来気がつかないものなのかもしれません。お節介気味のUIは,多くの場合毛嫌いされます。さも自分で何もかもやってしまったかのように思わせてしまうのが,巧みなUIなのです。ある人は,そんなUIのことを「透明」と表現したりもしています。ナビゲートされていることを気づかせないUI,それが最上のものなのかもしれません。

 もう一つ,この「UI部品」が“悩ましい”点を付け加えておきます。それは,説明の文言は,「開発」の中で一番後回しにされるという点です。ANAのシステムがどう開発されたかはわかりませんが,一般的に文言の決定は最終フェーズやテスト中になされます。

 読まれるのか読まれないのかわからないような説明文や注意の表示は,諸般の事情でどんどん先送りになっていきます。そのくせ,リリース後に一番緊急に修正される場合が多いのも,説明や注意事項です。そのため,文言の部分をXMLにして,そこだけ修正すればよいという具合に,メンテナンスが容易なように設計されているのが常です。

 したがって開発者は,文字長も決定されないデータを待ちつつ,読んでもくれないユーザーを想定しながら,この部品を実装していくのです。

 しかし,こうした積み重ねがクライアント企業との信頼を構築していきます。すべてが徒労に終わるわけではありません。こうした心理的な「気付き」を利用したUIを作った経験は,次の開発にも大きく影響します。

HTML版と比較してみよう

 最後の検証として,ANAパスポートのHTML版での同じ画面を下記に載せます。Flash版に比べて,どの程度「ご注意/ご案内」情報が頭に残るのか,ご自分で検証してみてください。おそらく多くの方が,Flash版のほうが「告知された」と感じることと思います。逆に,そう感じた方は,RIAやUIの力が信じられる方なのでしょう。


HTML版での「ご注意/ご案内」(クリックすると拡大します)

参考) RIAシステム 構築ガイド 2005年版 ( RIAコンソーシアム )


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