ワークフローを分断させるデザイン
タスクの実行がスムーズだとアプリケーションの利用は楽しいものになる。しかし、引っかかりのあるデザインや無理のある実装によって、ワークフローはよく分断されがちである。
ワークフローはアプリケーションデザインの最重要要素の1つである。ユーザーは自分たちのタスクを楽々と進行できているか。それともじれったい回り道をさせられたり、煩わしい余分なステップを踏まされているのか。
ワークフローのユーザビリティはいろいろなことで低下しうる。例えば、あるステップから次のステップに向けて何かを憶えておくようにユーザーに要求するとユーザビリティは低下する。（短期記憶への負荷は軽減しよう。これは憶えておくべき便利なガイドラインである :-)）。
今回は、1つのよくある問題に集中したい。それはタスクの自然な流れに沿った進行からユーザーが分断されるというものである。これは2つの方法によって起こりうる。すなわち、お粗末なユーザーインタフェースデザインによって意図的にユーザーを脱線させる場合。あるいはシステムに問題があるために、ユーザーの注意が、ユーザーのやりたい作業ではなく、システムの調整に逸れてしまう場合である。
では、出来の悪いユーザーインタフェースデザインと出来の悪いシステムの違いを理解するため、ユーザーに対してフレンドリーでないユーザーアカウントのアップデートの例を2件、見ていこう。
出来の悪いワークフロー： Apple iTunesのアプリケーション
AppleのWindows向けiTunesのアプリケーションにはひどいユーザーインタフェースデザインがあふれているが、今回、私が取り上げる例は、使用許諾契約書のアップデートに関わるものである。もちろん、ユーザーは「契約書」についてどうでもいいと思っているので、サイトやアプリが彼らにその変更を「同意する」かを尋ねる必要があるときでも、それはユーザーにとっては割り込みでしかない。（私は「契約書」と「同意する」を「」の中に入れた。なぜならば、ユーザーはこうしたよくわからない大量の法律用語に、本当の意味で合意したり、受諾したりしているわけではないからである）。
使用許諾契約書を自主的に探し求めるユーザーはほとんどいないので、それは流れを切る割り込み物のように表示される。割り込みはユーザビリティにとってはほとんど常に悪いものであるが、弁護士がユーザーインタフェースデザイナーに、こうした不快なデザインを顧客に押しつけるよう強いる理由は理解できる。もちろん、契約書のデザインは合理的、あるいは悲惨なワークフローのいずれかによって行うことが可能だ。そして、Appleが選んだのはユーザーが不愉快になるほうであった。
典型的な事例として、あるユーザーがiPhoneにインストールされたアプリをアップデートしたいと考えているとしよう。そのワークフローは以下のようなものである：
- データ形式のメニューで「App」を選択する。
- 画面の真反対の隅にある「アップデートを確認」をクリックする（これはFittsの法則を根拠とするお粗末なデザインの一例である。しかし、私は今回はもっと重要な仕事に取り組みたいと思う）。
- 変更のあったアプリのリストを見る。面倒な作業だ。
- 「すべての無料アップデートをダウンロード」をクリックする。（これは画面の3番目の隅にある。まさにこうしたことのために、我々はマウスをあちこち動かす練習を毎日しているのだ）。
- 使用許諾契約書が割り込んできて、流れが中断される。
- 「同意する」。
- 言い回しはすてきだが、ばかばかしいメッセージ、「もう一度購入をお試しください」を目にする。
- ステップ1からやり直す。げぇー。
もちろん、どんな駆け出しのデザイナーであろうと、ステップ7が分断されたワークフローの結果であることはわかる。コンピューターは実際、こういう記憶するのはかなり得意なので、システムはユーザーがその割り込みの前にしたかったことを憶えておくことができたはずである。言い換えれば、ステップ7ではステップ4で要求されていたダウンロードを開始すべきであった。
そう、コンピューターに追加の情報を記憶させるには、余分のちょっとしたコーディングが要るのである。しかし、株式市場で世界一の時価総額となった企業なら、ユーザーエクスペリエンスのこのちょっとした進化を実現させうる、今、ひまにしているプログラマーを1人追加で雇ってもいいのではないだろうか。
悲惨なワークフロー： 新しい通販薬局への切り替え
2番目の例は、私の健康保険の会社による、新しい通販薬局のウェブサイトへの切り替えに由来している。その会社は今回の切り替えをユーザーに通告するため、さまざまな方法で（物理的にも電子的にも）メッセージを送ってきていた。また、通院中の患者の現時点の処方箋が、今までの薬局から新しい薬局へ自動的に移されることまでも約束していた。ここまでのところはうまくいっていたのである。ユーザーは変化を嫌うので、そもそも、その切り替えを避けられたらもっと良かったが。
問題はログインしようと新しいサイトに行ったときに起きた。そのサイトで私は認証されなかったのである。
サイトに入れること以上に重要なことなどあるだろうか。このステップでの失敗によって、他のすべてのことが意味のないものになってしまうからである。
1～2週間後、ようやくその会社はしっかりした対応を取り、顧客はその新サイトにアクセスできるようになった。それ以降、そのサイトは普通に期待される程度にはまぁまぁ機能している。
バグ vs. 出来の悪いデザイン
なぜ私は、iTunesについて薬局のウェブサイトより気にしているのか。後者はより出来が悪く、ワークフローをただ悪化させるどころか、完全に駄目にしてしまっているというのに。
その理由は、薬局のウェブサイトに悪影響を与えているのはソフトウェアの1回きりのバグだが、iTunesに悪影響を与えているのは、出来の悪いインタラクションデザインという継続的なものだからである。
バグは誰にでも起こりうる。もちろん、時には私の身にも起こる。大きくて複雑である、ミッションクリティカルなソフトウェアは特にコーディングエラーの影響を受けやすいし、そのソフトウェアを顧客に押しつける前にデバッグのための十分な時間を取るのが賢明であることは間違いない。バグが修正される限りは、私もそうしたソフトウェアを言語道断とは思わないだろう。
もちろん、ユーザーにとっては、サイトの機能を妨げるものはすべて悪いものである。利用しているのが間違っている機能であろうが、たまたま動かなかった正しい機能であろうが、それは問題ではない。いずれの場合も、結果＝失敗、という意味では同じだからである。
今回はユーザーインタフェースとユーザーエクスペリエンスの違いを覚える良い機会だろう。我々がデザインするのは、画面やエラーメッセージ、フォーム、コマンド等のユーザーインタフェースである。しかし、デザインと実装の両方をシステム全体としてユーザーは経験する。（それ以外にもネットワークの遅延のような他の多くの構成要素もそこには含まれる。ネットワークの遅延は出来の悪いデザインと同じくらい応答時間を損ない、ユーザーエクスペリエンスを悪化させうる）。
ユーザーエクスペリエンス全体に対して、定義上、ユーザビリティはその質的属性にあたる。そのため、デザインと実装の両者、さらには、ホストするプロバイダーの選択のような、システムの管理スタイルの問題によってもユーザビリティは左右される。
したがって、あらゆるバグは批判する価値があり、デバッグ作業はより高い品質のための賢明な投資といえる。失敗の危険性をともなう華やかな最新機能を追いかけるより、堅牢なコードにするほうがユーザビリティを向上させることが多いからである。
結局のところ、出来の悪いユーザーインタフェースデザインに起因する、出来の悪いユーザーエクスペリエンスこそが、バグよりも私をさらにいらだたせるのである。iTunesの事例でいえば、ユーザーの操作をシステムが中断させた後はもう一度トライするよう指示したページを、誰かが自分は座ったまま書いたのだ。その結果、そのワークフローのデザインはユーザーに余計な負担を強いているものとして知られている。こうしたお粗末なデザインが何年もの間ソフトウェアの中に存在しつづけていることによって、そのデザインが真に批判するに値するものになっているのだ。