【海外記事紹介：上】Overhauling a UI without Upsetting Current User
こんにちは。インタラクションデザイナーの奈須です。
今回から2回に分けて、UI改修に関する海外の記事をご紹介したいと思います。
ご紹介するのは、UX Magazineで紹介されていた、「Overhauling a UI without Upsetting Current User」（現行のユーザーを混乱させずに、UIを組み直す方法）という記事です。タイトルの通り、UIの改修を行う際の障害は何か、どういう手法を使っていけばいいのかを紹介している記事です。内容は大きく以下の3つの章で構成されています。
- 見た目と機能を良く考えよう
- デザイン改修は根拠に基づいて行おう
- 終わりの見えない「UIの議論」はやめましょう
UIデザインの参考になればと思い、UXブログでご紹介したいと思います。長いので、今回は、
- 見た目と機能を良く考えよう
- デザイン改修は根拠に基づいて行おう
までの章の内容をご紹介します。以下、翻訳記事本文となります。
（この記事はUX Magazineにおける投稿記事「Overhauling a UI without Upsetting Current User」を翻訳したも
のです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）
現行のユーザーを混乱させずに、UIを組み直す方法
素晴らしいソフトウェア製品を持つ会社は、UI改善を行う必要を分かっていても、「UI変更によって、既存のユーザーが困惑してしまう」との懸念から、UI変更をためらうことがあります。ある会社の重役の方は、Macadamian社（注：この記事の筆者が勤める会社）に対して、以下のように発言しています。
「グーグルやFacebookのUI改修に対する、カスタマーからの反発を見るべきです。私はデザインの変更でカスタマーを失うリスクを、軽々しく冒したくありません。」
確かに、GoogleやTwitter , FacebookはUIの大きな変更を行いました。GmailのUI改修に対しては、「ユーザーの生産性を取り戻すため、UIを旧バージョンに元に戻すように働きかける」ため、UI変更後24時間以内には何百人ものユーザーが「新GmailのUIへの反対同盟」を結成しましたし、Facebookでは「問題がある訳じゃないなら、UIを変更しないで！」というような、UI変更への不満を表現するバナーが投稿されたりしました。
しかし、このように上手く行かなかった改修例もありますが、デザインを改修する事によって、競合を大きく出し抜き、成功した会社の例もあります。例えば、Salesforce.comがCRM（顧客関係管理）市場で優位なのは、その革新的なデザイン改修によるところが大きいのです。
外見と機能を良く考えよう
「経験」の価値の9割は見た目(How it looks)ではなく、どのように動作するか(How it works)によります。もちろん、ビジュアルデザインが重要でないということではありません。ただ、それだけでは不十分なのです。
とあるツイッタ―ユーザーは、新しいGmailのインターフェースが不評だった主な理由について、
「Gmailの新しいUIは機能よりも見た目重視に改修しすぎたのです。Gmailがみんなに使われていたのは、機能が良かったからだと言うのに。」と言い、「使ってみるまでは新しいGmailはスッキリしていて良く思えるけど、使い始めると使いにくいので、ユーザーは気を付けるべき。」とも発言しています。
通説として、非デザイナーは、「素晴らしい体験や製品の成功はビジュアル的な価値に依存する」と考えていると言えるでしょう。UXの専門家は、ビジュアルは「体験」を形作る１要素であると認識していますが、時にビジュアルデザインには、ユーザー体験の他の側面に使う時間を犠牲にして、不釣り合いなほど多くの時間が費やされます。素晴らしい見た目（ビジュアル）は、最初に製品に引きつけるためには重要度が高く、またビジュアルデザインは購入の意思決定をする際に非常に重要な要因でしょう。しかし、製品が市場において支持されるためには、製品の見た目ではないところに重点を置いて開発する必要があります。これは、ソーシャルメディアを通じ、予測できないほど早いスピードで製品に関する情報や意見が飛び交う社会において、特筆すべき真理である、と言えるでしょう。
デザインの改修において、見た目を改善したものの、「新しい価値」を提供する事に失敗した場合、新しいユーザーをガッカリさせるだけでは済みません。改修する以前は満足していたユーザーをも遠ざけ、さらに、こういった「失敗」のニュースは瞬く間に拡散します。「見た目の美しさは、ユーザーの実際の経験と等しい」というような間違った考えを持つのはやめましょう。
デザイン改修は根拠に基づいて行おう
単に見た目を美しくするためでなく、機能的な改善を行うため、プロダクトマネージャーと、デザインチームはリアルなユーザーを調査しなくてはなりません。多くの人は、この原則について既に知っているでしょうが、どうやって実行するかによって大きく異なってきます。
企業が一般的にもっともやりがちなミスのうちの1つは、ユーザーが欲しいと言っているものに基づいてUIの改修を行うことです。不幸な事に、実際の経験は、ユーザーが「すると思う」とか、「好きじゃないと思う」とか言ったことが、現実の行動と合致していないと言う事が散見されます。さらに、どうやって「UIを改善するのか」に関するユーザーの提案は、非合理的なものだったり、実行不可能なものだったり、さらにその両方だったりします。
ユーザーにフィードバックを依頼し、またそれを聞くことは大切なことである一方、ユーザーはデザイナーやユーザビリティエンジニアではないので、彼らの不満や提案はそのまま捉えるべきではありません。デザイン解と、デザイン提案を混同してはいけないのです。本当のUIの問題と解決策を見つけるために、「意見」だけでなく、「事実」も考慮した注意深いUXリサーチを行わなくてはなりません。
どんなUI改修でも使える基本的なテクニックとしては、フォーカスグループとユーザビリティテストが挙げられるでしょう。
フォーカスグループ
フォーカスグループは、新しい、もしくは既に存在する製品、アイデアについて、ターゲットユーザーの豊富な意見や態度を知る事ができる、強力な調査手法です。デザインの改修プロジェクトの早い段階での評価・調査として、フォーカスグループを行うのが最も良いでしょう。
開発の初期段階やデザイン改修の評価段階で、以下の事を見つけるためにフォーカスグループを行うともっとも効果的です。
- インターフェースの様々な側面に対する、意見の幅広さを感じとる
- ユーザーの「好み」にある背景、新しいUIに対するアイデア、UI変更のリクエストなど、なぜそういう意見が出たのかを理解する
- ユーザーのありのままの欲求をリスト化する
こういった情報は、プロジェクトの早い段階における方向性を、開発チームに与えてくれます。だからこそチームは開発の準備ができ、さらに重要な部分の開発をデザイン設計と並行し、早めに取り掛かることができます。
しかしながら、フォーカスグループは行動データを得る方法としてはあまり適していません。ユーザーが「きっとやると思う」と言う事は、彼らが実際に行う行動と比較すると非常に信用できません。それにはいくつか理由があります。1つめに、ユーザーが「きっとやると思う」と言う事と、ユーザーの実際の行動・態度は度々違うことがあります。人々はある状況下で、文脈的な要因が彼らの行動をどのように変える可能性があるかについて予測することができないのです。これが、車の試乗や30日間返品可能システムが好まれる理由でしょう。
２つめに、人々は自分自身の行動すべてに気を配りきれていません。毎日の習慣などは当たり前すぎて、やっている事すら忘れてしまうことがあります。例えば誰かに「電話のどんな機能を使っていますか？また、大体どの位の頻度ですか？」のような単純な質問をしたとします。質問への答えは、実際に調査したデータと比べるとびっくりするほど違っていたりします。
こういったところで、ユーザビリティテストなどの調査手法が活きてきます。
ユーザビリティテスト
ユーザビリティテストは、あらかじめ決められた一連のソフトウェア上のタスクを、ユーザーに実行してもらい、それらを調査・評価する事を通して、どんなデザインが有効か、見つけ出していくテクニックです。ユーザーが皆同様にワークフローの中の特定の部分でつまづくようであれば、それはデザインに不備があるという強い兆候です。
リサーチャーはインタビューを行ったり、体験したことについてのより質的な質問を行いながら、ユーザビリティテストの各セッションを遂行していきます。ユーザビリティ指標、たとえばタスク完了までの時間や、エラーの数、クリック数、成功率などは「使いやすい度合」と同時に収集/測定されます。
ユーザビリティテストは、βテストとは全く違ったものです。βテストでは、ユーザーは一般的にタスクを実行する事を非常に困難にするようなユーザビリティ問題、つまり明確なバグのみをレポートします。基本的に、「直観的でない」という問題や「実行する際に困難である」というような問題を見つけてもレポートしないでしょう。人は基本的に、自分のミスした点を認めるのを好みませんし、βテスター（もしくは、少なくとも1度は問題をレポートした事のある人）は、時に製品のファンであり、パワーユーザーであります。彼らはすでに、ユーザビリティ上の問題を回避したり、無視したりする事を学んでしまっているかもしれないのです。
ユーザビリティ上の問題（もしくは、その問題に関するバグ）を解決するにあたり、最もコストがかかる時期は「製品が完成した後」です。できるだけ製品がβ版になるまでに、明確なユーザビリティ問題は解決されているべきです。
次回、最後の章：終わりの見えない「UIの議論」はやめましょう をご紹介したいと思います。
関連サービス
ミツエーリンクスではよりよいUXの実現のため、各種UX,UI関連サービスをご提供しています。