QA & UX

品質保証はユーザーエクスペリエンス(UX)に影響する。物事がうまくいかないと、ユーザーは自分の理解を疑い、思い込みをして、非効率な回避策を作り出すからである。

  • QA & UX
  • by Jakob Nielsen
  • on February 17, 2013
  • 日本語版2013年3月5日公開

品質保証(QA)とユーザーエクスペリエンス(UX)の関係は双方向である:

  • 1番わかりやすく言うと、ユーザビリティとはデザインの品質尺度である。したがって、ユーザビリティを確保するためには、UXの質を上げるQA的考え方が必要である。
  • ユーザーインタフェース以外の多くの品質問題もUX全体に影響がある

QAとしてのユーザビリティ

定義によると、ユーザビリティは学習しやすさや利用の効率、ユーザーの満足度といった測定可能な品質特性から成っている。

私の30年間に及ぶユーザビリティでの経験の中で、繰り返し示されてきた1つの教訓がある。それはデザイン品質へのアプローチとして、QA はQC (品質管理)に何倍も勝る、というものである。最初の段階、つまり、あらゆるものをデザインする前にユーザビリティをプロジェクトに組み込むほうが、デザインがほぼ最終段階になるまで待ってから、ユーザーテストの「検証」の対象にするよりもずっと良いからである。

早い時期から重点的にユーザビリティに取り組むことで、大きくROIも上昇する。デザイン課題の修正は計画段階で行うほうが製品の発売後に行うより100倍安いからである。

(ユーザビリティの第一法則を思い出してみよう。それは、デザインというのはユーザーによって必ずテストされる、というものである。あなた方が唯一選べるのは、後で高いコストをかけて巻返しを図る代わりに、予測できる問題を安く修正できるよう、自分たちでも発売前にテストするかどうか、だけである)。

これは他の品質分野でも見られるのと同じ結論である。製造業や航空会社のサービス、あるいは病院の清浄度でも、最高の結果は品質を基本プロセスの一部としてみなす積極的QAによって達成される。事後のQC評価が何もしないよりましであることは間違いない。それによって次に向けて集中することが可能になるからだ。だが、それによって、最高の品質は作り出せない。

UXのQAと、他の品質分野とのもう1つの類似点は何か。それは、質の高いデザインは望むだけでは得られない、品質活動をプロジェクトプランに組み込むことによって得られる、ということである。

QAはどのようにUXに影響するのか

そう、我々が手に入れたいのは質の高いデザインだ。だが、そこにたどり着くには、全体のUXを損なう可能性のあるユーザーインタフェース以外にも、多数の品質問題に取り組む必要がある。

応答時間については既に何度も論じた。かなりはっきりしているのは、きびきびしたコードというのは、単なるプログラマーのプライドの問題ではない、ということである。システムのスピードは.ユーザビリティのすべてのエリアに影響を及ぼすからである:

  • のろいシステムがじれったく、ただちに満足度を下げるものであるのは間違いない。1994年から行っているユーザーテストのすべてで、ユーザーは遅いウェブサイトには不満を言い、速いものはほめている。
  • 利用の効率もシステムのスピードに影響を受けることがわかっている。1つ1つの行動に時間がかかればかかるほど、タスクの実行に時間がかかるようになるからである。しかしながら、全体が受ける影響はシステムに起因する遅延の合計よりもずっと酷いものになることは多い。ユーザーは待たされるのではないかと不安に感じると、有益な行動を取るのにも躊躇するようになるからである。
  • 遅いコードが学習しやすさを損なうことはあまり知られてはいないが、真実だ。人間の短期記憶は急速に減衰する。したがって、ユーザーは、待つ必要性が出てくると混乱しやすくなる。また、スピードが遅いことによってインタラクションの負担が増すと、ユーザーは新しい選択肢を探求(して、学習)するのが嫌になる。

これら以外の品質問題もUXには影響がある。バグやクラッシュはユーザーを激怒させ、タスクの達成を妨げ、時には、多大な時間のかかる回避策を必要とすることになる。しかし、こうした実装のエラーは学習しやすさも損なう。というのも、ユーザーは問題を回避するややこしい思い込みをしてしまうことが多いからである。(「Xをしたいのなら、Yをすることはできない。クラッシュが起きるから」のように)。ユーザーのメンタルモデルが混乱していると、システムのバグのない部分を利用する彼らの能力も低下するのである。

また、物事がうまくいかないとき、ユーザーはそれがコンピューターによる誤りだとは必ずしも思わず、自分自身を責めるのが普通である。

例を挙げよう。私は、1月の初旬、年金を積み立てている大手証券会社から、新しい税年度の始まりは口座に資金を追加する良い時期だ、と勧める広告メールを受け取った。なるほど、というわけで、私はサイトに行き、適当な量の資金を自分の銀行の口座から年金の口座に送金しようとした。で、結果はどうなったか。エラーメッセージが出て言うことには、私は限度額以上の資金を入金しようとしていたそうだ。

こうしたことが起こりうる理由はいろいろあるが、最初に頭に浮かんだのは次の2つである:

  • 入力した数字が間違っていた。例えば、6,500ドルのところを65,000ドルと入力したというふうに。そこで、私はもう一度試みることにし、細心の注意を払って、正確な数字を打ち込んだ。しかし、同じエラーメッセージが出た。
  • 税法の変更内容を勘違いしていた。2013年時点では、私の年齢の人は年間6,500ドル貯めることができるようになったと思っていたのだが。しかし、結局のところ、こうした規則は極めて複雑なうえに、毎年変わる。そこで、私は長ったらしい資料を再度読み返した。

実際には、そうした時間はすべて無駄であった。私の打ち込んだ数字は正しかったし、私に許されている金額も間違っていなかったからである。つまり、間違っていたのはシステムだったのである。誤って、2012年の税制を、2013年になされた年金への投資に適用していたというわけだ。もちろん、システムが自分でそう言ったわけではない。それどころか、システムはかわいそうなユーザーを自分が悪いと思わせたままにして、何度も何度もやらせ、毎回、結局、投げ出させるだけである。1週間後、もう一度試したらうまくいったので、わかったのである。(今回のケースでは私は口座を維持し続けた。しかし、こうした問題が繰り返し起こるようなら、あるいは私が新規顧客だったら、私の資金は競合他社に行ってしまっていただろう)。

新年度税制に合わせるというコンピューターシステムの更新は、1月1日に行われるべきであり、1月10日に行われるべきでないのはわかりきっている。同様に、バグというのは悪いもので、応答時間は早くなければならないというのも自明のことだろう。

では、そうしたことが当たり前なら、なぜ問題がはびこるのか。理由は、企業が品質というものを真剣に考えていないからである。彼らは古い機能を強固にすることよりも、機能を新しくすることのほうに投資する。しかし、QAがユーザーの信頼と顧客満足の土台であることを我々皆が認識すれば、UXは随分と向上するだろう。そして、すべてがうまくいった時点で、新しい機能については考えればよい。

10年前、私は、技術を生かすときがきた、と言った。今日、バグに悩まされることは10年前よりはやや減ったようには思う。しかし、品質の低さというのはいまだに横行しすぎている。そんなわけで、私はもう一度言いたい。今こそが技術を本当に生かすときであるということを。

さらに詳しく

調査レポート

記事

Original image by geralt