
ユーザビリティのヒント(最終回)
「OK」と「キャンセル」、どちらが有効か
「情報表現の最適化」
ソシオメディア 上野 学
2006/10/20
| プログラマーの文法をユーザーに強要しない |
- - PR -
例えば、デスクトップのメモ帳を新規に開いて、メモを書き、ウィンドウを閉じようとすると、「変更を保存しますか?」というメッセージダイアログが表示されます。ユーザーにしてみれば、「新しいメモをいま書いたところなのに、なぜ『変更』なんだ?」と思うでしょう。
システム側からすれば、内容が空であった状態から新たに文字列が追加されたという意味で「変更」が加えられたといえますが、これはデータの状態に対する視点であり、ユーザーの行動に対する視点ではありません。システム全体がこのような視点からデザインされていると、大変使いにくいものになってしまうでしょう。
![]() |
| 画面6 新規に作成したメモなのに、「変更」とはどういうこと? |
このような、技術的な仕組みやプログラムの都合に従って作られた典型を、「技術モデル(もしくは実装モデル)」と呼びます。ユーザーインターフェイスやインタラクションは、技術モデルではなく、ユーザーのメンタルモデル(「ユーザーにとっては“ユーザーインターフェイス”こそが製品そのもの)に合致するように(もしくは正しいメンタルモデルを持ってもらえるように)デザインされなければいけません。
メモ帳の例でいえば、そもそも、書いたメモを保存するかどうかをユーザーに尋ねること自体、技術モデルに根差した不自然なインタラクションだといえます。なぜならこれはコンピュータの仕組み上の都合でユーザーに強要しているアクションだからです。
現実世界では、紙のメモ帳にメモを書いた後、それを保存するかどうか、それをどのような名称でどこに保存するか、といった意思決定をユーザーはいちいち迫られません。書いたものは当然そこに存在し続けるのです。こういった自然のルールがソフトウェアにおいても適用されていれば、それはユーザーのメンタルモデルに一致したものになりやすいはずです。
実際、アプリケーションによっては、いちいち保存のアクションを起こさなくても作業結果が自動的に保存されていくものがあり、使い勝手の良いものが多いと思います(むしろ自動保存は自然に起きるので、そこに保存処理が発生しているということ自体が意識されず、自動保存の機能を肯定的に評価するのが難しいほどです)。
もちろん、「作業前の状態に戻せると思っていたのに、勝手に上書き保存されてしまった」というトラブルは予想されますが、それはまた別の問題であり、多段階のアンドゥを可能にするといった方向で解決すべき話でしょう。
誤解を生みやすい概念としては、ほかにも、「AND」や「OR」を使った論理演算があります。ブール演算の考え方は検索サービスなどの利用で一般的になりつつあるともいえますが、日常で使う「〜と〜」「〜または〜」という言葉の意味と混同してしまうと、システムの振る舞いが不可解なものに見えてしまう恐れがあります。
例えば、顧客データベースの中から「東京都在住の人と大阪府在住の人」をすべて探し出したいという場合、検索条件として住所を「東京都 AND 大阪府」と指定してしまうと、当然意味を成しません。
同様に、「りんご または みかんのどちらか1つを買った人」を探したい場合に、検索条件として購入商品を「りんご OR みかん」と指定しても目的を達成できません。そのため、UI上では「AND」や「OR」といった言葉を使うのではなく、「すべてに一致」「いずれかに一致」「含めない」といった説明調の言葉で、システムの振る舞いを分かりやすく表現することが望まれます。
| まずは「べからず」を守ることが有効 |
今回のTipsは以上です。また、この「ユーザビリティのヒント」の連載は今回で最終回になります。ここまで通して読んでいただいた方はすでにお気付きかもしれませんが、紹介してきたTipsはすべて「〜をしないこと」という書き方になっており、いってみれば「べからず」集となっていたのです。
良いユーザーインターフェイスを設計するためには、ユーザーを迷わせる要因を排除するための「べからず」を守ることが有効です。一方で、ユーザーにとっての利便性を積極的に向上させる「べき」を実践していくことも重要となります。この「べき」は、「べからず」に比べると、ユーザーの要求などの状況に応じて変化する傾向があり、一概に原則化するのが難しいものでもあります。
とはいえ、この部分がブラックボックスになっていたのでは、ユーザーインターフェイスを効率的にデザインすることができません。そこで次の機会には、UI設計における「べき」について考えていければと思っています。
最後に余談ですが、連載の第1回「多くのユーザーは一度に1本しかジュースを買わない」で「ジュースの自動販売機では連続購入モードは不要」といったことを書きましたが、そもそも多くの自販機は1本ずつしか買えないようになっていました。食券販売機などの動きと混同していたようです。
| 3/3 | 次の連載もお楽しみに |
|
INDEX 以下ダミー |
||
| ユーザビリティのヒント(4) | ||
| Page1 意識の流れに逆らわない デフォルトボタンは左右のどちらがよいのか |
||
| Page2 時間の流れに(必要がない限り)逆らわない 表現を特定の文化的背景に依存させない |
||
| Page3 プログラマーの文法をユーザーに強要しない まずは「べからず」を守ることが有効 |
||
関連記事 |
ユーザビリティのヒント バックナンバー
- 第1回 多くのユーザーは一度に1本しかジュースを買わない
- 第2回 「メールは送信されました」伝えるのなら、控えめに
- 第3回 虫眼鏡のアイコンは『検索』か『拡大』か?
- 最終回 「OK」と「キャンセル」、どちらが有効か
Webアプリケーションのユーザーインターフェイス
従来のデスクトップアプリケーションでのGUIやインタラクションの原則から、Webアプリケーションのデザインを考えよう
- 第1回 ユーザーにとって “インターフェイス”が製品そのもの
- 第2回 ユーザーが選びやすいフォームのカタチを考えよう
- 第3回 UCD=利用者中心設計のプロセスとは?
- 第4回 お金を下ろせないATMの画面デザインを考える
- 第5回 入力情報を預かる責任を果たせる画面デザインとは?
- 第6回 「戻る」で入力データが消えてしまうフォームはいらない
- 第7回 すでに入り口にいるのに、ホームに導くボタンは親切か
- 第8回 ユーザーが間違えても間違えずともエラーは回避せよ
- 最終回 売りたいなら、“販売”でなく“購入”ツールを準備せよ
TechTargetジャパン
- 次のモバイルアプリはどのフレームワークで作る? (2012/5/24)
スマホアプリの開発を容易にするJavaScriptのフレームワークが続々と増えている。それぞれの良さや仕組み、何がどこまでできるのかを徹底解剖する - 「LESS&専用エディター」でCSSをシンプルに書こう (2012/5/23)
「LESS」はCSS初心者に向けた、シンプルなライブラリだ。「LESS」で、変数などのプログラミングの基礎的な考え方もCSSで学ぼう - 学校が世界一のデジタル環境になったら (2012/5/18)
授業はアーカイブに蓄積され、家からも見られる。家族が授業テーマのアイデアを出す。そんな姿が実現されるかもしれない - 1000万ドル調達も夢じゃないクラウドファウンディング (2012/5/15)
クラウドファンディングは、寄付型でも投資型でもない「購入型」が主流。商品を“開発する前に販売”して開発費用を集める逆転のシステムだ
|
|

