はじめに
私は普段ゲームアプリのQAをやっているのですが、
「リリース後に発生する障害は少ないけど、UIが使いづらいといった形でユーザーからの評判があまり良くない」
といった経験ありませんか？
私はあります！
今回もしかしたらその打ち手の一つになるかもしれない「ヒューリスティック評価」という手法をやってみたので紹介ができればと思います。
ヒューリスティック評価とは
検索して調べてみると
「UI/UXの専門家が経験則を元に、プロダクトのユーザビリティを定性的に評価すること」
とあります。
そして、その評価に使用できる「ヤコブ・ニールセンの10原則」という観点があるとのことです。
10個の原則は以下です。
- システム状態の視認性を高める
- 実環境に合ったシステムを構築する
- ユーザーにコントロールの主導権と自由度を与える
- 一貫性と標準化を保持する
- エラーの発生を事前に防止する
- 記憶しなくても、見ればわかるようなデザインを行う
- 柔軟性と効率性を持たせる
- 最小限で美しいデザインを施す
- ユーザーによるエラー認識、診断、回復をサポートする
- ヘルプとマニュアルを用意する
上記の観点を用いて各プロダクトに沿ったチェックリストを作成し、対象のプロダクトを確認しながら定性的に評価する手法とのことです。
やってみるに至った背景
なぜ「ヒューリスティック評価」をやってみようと思ったかといいますと、
私が担当するプロダクトで新規UIを用意した追加施策があるたびに、ユーザーの方から「使いづらい」といったご指摘をいただくことが多く、何か改善を行いたいと考えておりました。
ただ「ヒューリスティック評価」は「UI/UXの専門家による評価」とあり、すぐに実施するのは難しいと判断していました。
そんなとき「JSTQB Conference」にて「Erik Van Veenendaal」さんの「ヒューリスティック評価」のワークショップに参加させていただく機会があり
- 専門家である必要はなく「Just Do It !」
- まずはやってみることが大切で、ナレッジは実施することで蓄積していく
- ある調査でコードの42%がUIに関わる内容で、UIの品質をあげることが全体の品質を底上げすることに繋がる
上記内容をお話しいただき、まずはやってみようと思いました。
導入の方法について
今回実施するまでに行った導入から実行、報告までの手順を説明します。
1.導入に向けて
私の担当しているプロダクトでは開発メンバーの方も改善に積極的な方が多く導入はそこまで困難ではありませんでした。UIにおける課題抽出の方法でヒューリスティック評価という手法があり、それをテスト的に運用するという説明を行いスムーズに実施ができました。もし、スムーズに進めづらい場合には、前述した「コードの42%がUIに関わる内容で、UIの品質をあげることが全体の品質を底上げすることに繋がる」という説明を行ったり、後述しますがコストをかけずに実施が可能であること、課題の早期検知が可能であることは説得材料の一つになるかもしれません。
2.原則を元にチェックリストを作成する
次に「ヤコブ・ニールセンの10原則」を元にチェックリストを作成します。
今回は実施するハードルを下げるためスピーディーに実施できる範囲内（チェックリスト作成から実施まで１〜２日）に収めたかったので、1つの原則に多くても確認項目は5つまでとしました。
チェックリストを参考用として添付します。
（実際に使用したリストは公開できないため、内容を変更しています）
【仕様】
・お店でお買い物をするたびに、「100円 = 1ポイント」が貯まるスタンプカード
・ポイントが一定ポイントを超えるたびに、おまけのアイテムがもらえる
・スタンプカードには有効期限がある
・スタンプカードは複数枚の所持が可能で、自身で破棄することもできる
チェックリスト（抜粋）
3.実施するメンバーの選定
参加したワークショップでは実施するメンバーについて「プロダクトのドメイン知識を持ったQAメンバー」や「プロダクトの開発メンバー」等が良いというお話がありました。
ただ、今回はまず実施する事を優先するため、導入コストを抑えられる「プロダクトのドメイン知識を持ったQAメンバー」2名で実施しました。
少なくともQAメンバーであれば確保はしやすかったので、最初から欲張り過ぎずここで効果が出れば開発メンバーを巻き込む提案がやりやすくなると思い、まずはQAメンバーで実施しました。
4.実施タイミング
新規リリースのUIが実際に実機上で触れるようになったタイミングで実施しました。チェックリストは事前に用意してあったので、実施するメンバーが個別にチェックリストを元に確認を実施する形で進行しました。
5.報告
確認が一通り終わり開発メンバーに報告する前に、認識合わせとしてすり合わせのMTGを30分程度行い、報告内容を取りまとめて行きました。
その際に行ったのは、以下となります。
- 課題があった箇所、内容の認識合わせ
- 課題の修正優先度づけ
- 報告方法の認識合わせ
上記のすり合わせの結果、今回は6件の改善ポイントを検出し、
修正することが望ましいもの4件と提案2件として修正優先度づけを行い、
普段の不具合報告で使用している不具合チケットの形で登録し、
開発メンバーに報告することとしました。
実施タイミングによっては報告を別の形（スプレッドシート等）で行うことも検討できたのですが、今回はすでにQA期間に入っていたのでチケット化したほうが漏れが発生しないだろうと判断しました。
今回「ヒューリスティック評価」を実施してみて、提案2件は今後の開発メンバーの改善タスクに積まれたものの、修正する事が望ましいと報告した4件は、リリース前に修正が入ることになり、一定の成果は出たと考えています。
実施するメリット
コストが低い
10原則が既にあるので、チェックリスト作成にそこまで時間がかからないところはメリットかと思います。今回は実施がQA開始のタイミングになってしまいましたが、準備〜実施に時間がかからないため、開発フェーズの早期タイミングで実施ができると手戻りのコストを抑えることができ、より大きな効果が望めるかと思います。
他社アプリとの比較が容易
今回は実施できなかったのですが、10の原則がありそれに基づいたチェックを行えることから、競合他社アプリとの比較も容易になるかと考えています。競合他社アプリ等で似たような施策を実施している場合、そのアプリと比較して本アプリはこうなので改善した方が良い。という主観だけに頼らない評価ができると考えています。
探索的テストに含める事が可能
またワークショップの際にお話もあったのですが、探索的テストのチャーターに含めることで、普段のテスト業務と合わせて確認することも可能です。
気を付けるポイント
コストをかけず小規模にすすめる
コストをかけて対応すると実施までに時間がかかってしまったり、費用対効果を考えると継続実施が難しくなるため、コストをなるべく抑え小規模に実施するところが気を付けるポイントです。今回はチェックリストの作成から実際のテスト実施まで、2名で1〜2営業日程度(別作業と並行して行っていたので実際の作業時間は合計6時間程度)で実施しました
実施時の注意ポイント
前述した通り実施自体は比較的容易なため、必要以上にスピードを出しすぎないようにも意識しました。また欠陥を最初から見つけようとしないで、実際にこれがリリースした際にユーザーにどう使われるかを理解し全体の流れを考えながら確認するようにしました
報告内容について
報告内容はどの原則に違反しているかを振り分けて、どの原則でどういう問題が起きているかを把握と今後の分析に利用できるようにしました。また、報告内容について修正優先度をつけて、開発メンバーに報告するようにしました。
やってみての振り返り
今回やってみて取り組みを継続したいと思った結果の一つとして、実装されたものがリリースできるレベルかの確認を行うプロデューサーと同じ指摘を、QA側で実施したヒューリスティック評価で指摘することができたというところがありました。
こちらの指摘は温度感高く修正が進められた内容だったため、ヒューリスティック評価を実施する方向性としては間違っていないという確信を得る事ができました。
また今までにない観点でのチェックでしたが、チェックリストを用いることで体系化してテストを行うことができたため、継続して実施する下地を作ることもできました。
ただ実施回数がまだ少ないため、UIにおける改善ポイントをより多く見つけるためにも、実施する回数を増やしナレッジを蓄積する必要があると感じています。
また今回実施タイミングが遅れてしまったのも改善ポイントだと感じています。
より早期に修正必須な対応を検知することで手戻りを防げるという確信は得られたので、早期に実施ができるよう開発メンバーと連携し今後改善を進めたいと考えています。
＜今回の実施タイミング＞
UI設計 ➡︎ 実装 ➡︎ プロデューサーチェック ➡︎ QA&ヒューリスティック評価 ➡︎ リリース
BAD:QAタイミングでの実施となってしまい報告が遅れてしまった
＜理想のチェックタイミング＞
UI設計 ➡︎ 実装 ➡︎ ◎ヒューリスティック評価 ➡︎ プロデューサーチェック ➡︎ QA ➡︎ リリース
GOOD:プロデューサーチェックの前に実施することで手戻りを防ぐ
今後について
進め方の改善ポイントも多かったのですが、改善を進めて継続して実施していくことでプロダクトの品質をより良くする手応えを得る事ができました。
また指摘内容についても修正必須なものも検知することが出来、今後より早期に実施することで手戻りを防ぐことができる確信も得ることもできました。
今後は実施タイミングの改善と、報告からの改善率やユーザーの評価に改善傾向がみられるか……といった実施結果に関するKPIも取れるようにしていきたいと考えております。
コストをかけ過ぎず小規模から始めることを意識すれば、早期かつ低コストで実施が可能なので、実施のハードルは思ったより低いと思います。
みなさんもぜひヒューリスティック評価を「Just Do It !」