[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

誤ったUXが引き起こした5つの致命的な失敗

Caroline White

CareerFoundry卒のCaroline氏は、ニュージーランドのオークランドにあるソフトウェアソリューションエキスパートDatacomのUXアナリストです。彼女は、UX、問題解決、そして人々について読んだり書いたりすることが大好きで、暇な時間にはボードゲームをしたり、彼女が住んでいる美しい国を探索して楽しんでいます。

この記事はSpeckyboy Design Magazineからの翻訳転載です。配信元または著者の許可を得て配信しています。

The UX Mistakes That Cost Companies Millions

私の友人は鉄骨建築のエンジニアで、彼の会社はロンドンのシンボルであるガーキンのような巨大なビルの建築に関わっています。もし彼が正確に設計せず、何かが数ミリでもずれてしまったら、建物はバランスを崩して甚大な被害をもたらすでしょう。ではUXデザイナーにかかるプレッシャーは少ないのでしょうか。

以前は私も間違いなくそう思っていました。私が人事担当のソフトウェアを設計していたころ、友人とそれぞれのキャリアについて議論したものですが、当時は私の誤った判断がどのようにして大きな影響を与えるか理解できませんでした。一体何が起こりうるというのでしょうか?

どの業界にいるかによっても異なりますが、時には誤って決定したUXが大きな損害をもたらすこともあるのです。その実例として、企業(または納税者)に数百万ドルの損失をもたらした、そして救えたはずの命を失うという最悪の結果を招いてしまった5つのケースを紹介します。

1. ミニマルなデザインへのリニューアルでほぼ半分のユーザーを失ったIcons8

Icons8では何千ものアイコンを無料でダウンロードできる素晴らしいサイトです。UXについても少しは知識を持っていそうに思えます。もちろん今は間違いなくUXの知識を知っていますが、それは過去に起きたことから事後的に学んだためでした。

Icons8がUIを変更したのち、“アイコンリクエスト” サービスの使用者数は47%も削減してしまいました。このサービスでは、ユーザーがデザインしてほしいアイコンに投票し、翌日もっとも投票数の多かったアイコンが作られます。

Icons8は、新しくモダンでまとまったインターフェースを導入しましたが、実際にはあまり直感的なものではなくなってしまい、すべての目的が明確でなくなってしまいました。これまでのデザインでは、何票が投票されたのか、どこをクリックして投票するのか非常にわかりやすいシステムでした。テキストフィールドのプレイスホルダーに、アイコンをリクエストする方法のヒントも明示されていました。

しかし新デザインでは、それらのわかりやすい説明文がすべて非表示になっています。使用方法を見るためには、ユーザーは「リクエストアイコン」を選択しなければなりません。しかも各アイコンの緑色の数字が、投票数を示した投票ボタンであることをどこにも明記していませんでした。

さらに、リクエストされたアイコンへのコメントが見えないため、ユーザーはそのコメントを楽しめなくなり、画面を下にスクロールしたいというモチベーションを下げてしまいました。結果的により多くのアイコンを探して投票することが減ってしまったのです。

Icons8は学習曲線に基づいた体験だったと言っていますが、UIをシンプルにしようとしたことで、実際にはユーザーにとってより複雑なものになってしまいました。その反省としてIcon8は投票数を示す新しい方法を見つけ、説明文を戻し、メインページでリクエストアイコンサービスを表示する対策を講じようとしています。

2. 顧客行動調査の欠陥により185万ドルを失ったウォルマート

店内の“乱雑さ”を軽減してほしいか否か聞いた顧客アンケートに沿って、ウォルマートは顧客の要望通り多くの時間と費用をかけて在庫を大幅に減らして店舗をよりすっきりとさせました。しかし、このせいで店舗売り上げがおよそ185万ドル減少する事態を招いてしまったのです。最終的にこのプロジェクトに取り組んだチームは解雇され、改革で行われたすべての変更は元に戻されました。

たしかに顧客の声を聞くのは良いことですが、このウォルマートのアンケートは誘導質問でした。質問の背景がわからない状態で乱雑なほうがいいなどと誰が言うでしょうか?

ユーザーリサーチに基づかない仮説から導き出して二択の質問で検証しようとするのは、良い考えとは言えません。そうではなくウォルマートは店頭バーゲンをどのくらいの人々が好むのかなどの消費者行動を調査するべきでした。

3. 不出来なNHS患者記録管理システムにより120億ポンドを無駄にしたイギリス政府

2002年イギリス政府は、全国の患者の記録を一括するプロジェクトにのりだしました。しかしながら使用感、機能、および利益の面で見合わなかったため2011年に廃止され、史上最大の政府ITプロジェクトの失敗として多くの記事で引用されています。

Andrew Lansley保健長官は、「国民健康サービス(NHS)にトップダウンのITシステムを導入したことでニーズと合致しなくなってNHSが悪化し、納税者のお金を無駄にする結果となった」と述べました。このような大規模な財政惨事に対して必要なユーザーリサーチやテストが行われたとは考えにくく、解決策が完璧に目的に沿っているのどうか、もっと詳しい調査がなされるべきでした。

英国政府はこの間違いから反省し、2011年以来政府デジタルサービス(GDS)はユーザーを最優先に考えたものとなり、市民と政府の関係は改善されました。

私が2015年実際にGDS事務所のUXツアーに参加した際には、彼らの仕事ぶりにとても感銘を受けました。彼らのユーザビリティ研究所は、この分野の専門家であるKate Towsey氏によってデザインされました。もしUXを導入するよう尽力する人がいたとしたら、それは彼女でしょう。

4. 原子力発電所の劣悪なインターフェースデザインが、部分的な炉心溶解を招いた

1979年3月28日にスリーマイル島の原子力発電所で発生した事故はINES(国際原子力事象評価尺度)で7段階中5段階と評価され、広範に影響を及ぼしました。機械的な故障が原因ですが、訓練不足と粗末なUIが原因で状況を把握できなかった発電所作業員のせいで悪化していったのです。

事故ではバルブが開いたままの状態で動かなくなったことで原子炉が過熱され、放射性ガスが放出してしまい冷却材が原子炉から流れ出しました。

発電所作業員が警報を発するまでに、半分近くのウランが溶けてしまいました。幸いなことに犠牲者は出ませんでしたが、放出されたキセノン135およびクリプトン85という放射性ガスのせいで20マイル内の14万人が避難することになりました。

この恐ろしい事故を招いてしまった主原因は何だったのでしょうか。実は、コントロールパネルのライトでした。このライトは、点灯していればバルブは開いていて、消えていれば閉じているというように圧力逃し弁の状態を示していました。

しかしそれは従業員が信じていたことにすぎなかったのです。残念ながら、コンピュータがバルブを閉じる信号を送るとライトはすぐに消えてしまいました。バルブが開いたままであることはインターフェースに表示されず、従業員がバルブに問題があるという警告を受けることはありませんでした。

もし設計者がライトがどのような状況で使われるのかを考え、バルブが適切に閉じたときだけライトが消えるよう設計していたら、事故がここまで大規模になることはなかったでしょう。

5. 重要情報を強調しなかった病院の患者記録システム

このケースはこちらのMediumの記事でも取り上げられたものですが、がんが再発した幼い女の子が入院したときの話です。彼女は、3日間の点滴水分補給が必要な強い化学療法を受けていました。

3人の看護師が、何が必要なのか教えてくれる図表ソフトウェアを使って、彼女の看護をしていました。ですがソフトウェアのUIは曖昧で読みにくく、看護師たちは点滴水分補給に関する情報を見逃してしまい、彼女は毒性と脱水症状で死亡する悲劇が起きてしまいました。

ただ単にUIが複雑すぎて読めなかったから彼女が死亡した、と解釈するのは難しいでしょう。ですがさまざまな色、フラグ、警告メッセージ、またはすべての指示を正しくこなせるように段階的なウィザードを使用して、重要な情報を警告することもできたはずです。2番目に紹介した医療業界におけるUXの事例と同じように、明らかにUXデザイナーの助けが必要な分野のようです。

まとめ

これらの事例は重く受け止めるべきですが、ではUXデザイナーはこれらの過ちから何を学ぶことができるでしょうか?

3つ挙げるとすれば以下のようになります。

1.ユーザー調査は徹底的に行いましょう。決してユーザーの使用目的をわかっていると思い込んではいけません。ユーザーインタビューや現地調査などの定性調査による推測やアンケートによる定量データをもとに、状況を総括的に理解できていることを確認してください。自分自身で経験し観察するのがユーザーリサーチの最善手段です。ユーザーリサーチの詳細についてはこちらをご覧ください。

2.既存のカスタマージャーニーやデザインプロセスの中の欠点を探しましょう。どんなアイデアも初めから完璧なものはないので、反芻することを備えてください。すべての人に確実に解決案が働くように、ペルソナを用いてチーム全体でアイデアを話し合いましょう。

3.ユーザビリティテストはできれば少人数の人と被験者で、不自然でない環境で実行しましょう。被験者が単にわからない部分、またはよく起こる問題で潰せそうなものはありませんか? 開発チームのために簡単なものにしたりコストを節約したりするようにそそのかされたときも、この5つの過ちを思い出し、ストレス下でインターフェースがどのような意味を持つのか、上手くいかないとどれほど重大な結果を招くのか考えてください。


Welcome to UX MILK

UX MILKはより良いサービスやプロダクトを作りたい人のためのメディアです。

このサイトについて