ほとんどの開発チームと同様に、 Mendixでは、アプリケーションの構築に Scrum を適用しています。Scrum 手法の一部は、ユーザーと関係者による製品の検証です。しかし、多くの開発チームは、機能的な製品を構築するために最善を尽くしているにもかかわらず、このステップを軽視することがよくあります。通常、ユーザビリティ テストが複雑になりすぎて、それが重要ではない、またはリソースを節約していると誤解して、開発プロセスから除外されます。これは残念なことです。ユーザーによる (価値の低い) 製品のテストは、より良い結果につながるからです。
ユーザビリティテストはアプリケーションの成功率を高めます
アプリケーションの成功は、ユーザーがどのように使用するかにかかっています。ユーザビリティの問題は、製品の使用意欲に悪影響を及ぼし、その結果、アプリケーションの長期的な成功にも悪影響を及ぼします。書籍「Rocket Surgery Made Easy」(Kurt、2010 年) によると、すべてのアプリケーションには、軽微なものから深刻なものまで、ユーザビリティの問題があります。ここで問題となるのは、アプリケーションの使用方法が「あまりにも明白」であるため、設計者、開発チーム、および製品所有者がユーザビリティの問題を見逃してしまうことが多いことです。
ユーザビリティ テストを使用すると、ユーザビリティの問題を簡単に見つけて説明できます。開発中にこれらの問題を解決することは、成功するアプリケーションを作成し、後で問題を修正するために不必要な開発時間と費用を費やすことを防ぐために不可欠です。
なぜ人々はテストをしないのでしょうか?
ユーザーや関係者による製品の検証はスクラム プロセスの重要な要素ですが、次のような理由からユーザビリティ テストが省略されることがよくあります。
- 考え方: アプリケーションをできるだけ早く提供し、必要に応じて後で調整します。
- 私たち（開発チーム）はユーザビリティの問題を経験していないので、問題ないはずです。
- これには専門知識と知識が必要ですが、開発チームにはそれがありません。
- そして、それを外部の業者に依頼すると、費用がかかりすぎます。
ユーザビリティ テストには数日から数週間かかるとよく考えられます。そのようなタイムラインに直面すると、ほとんどの人は、明らかなことをテストして微調整するよりも、新しい機能の構築にリソースを費やそうとします。
あなたのために作られたユーザビリティテスト方法
ユーザビリティテストがどれだけ大きな影響を与えるかを知って、私たちのデザインチームはテスト方法を確立しました。 Mendix メーカーがプロセスに組み込める製品を開発しました。実験の結果、私たちはシンプルで早く、安価なテスト方法を見つけました。 Mendix アプリケーション。私たちが考案したアプローチは、「Rocket Surgery Made Easy」（Kurt、2010年）という本にヒントを得たもので、開発者、設計者、製品所有者に、アプリケーションがどのように使用され、どのように改善できるかについての貴重な洞察を提供します。
このプロセスでは、これまで考えもしなかった興味深いことが必ず見つかります。また、ユーザビリティの問題を解決することで、アプリケーションはよりユーザーフレンドリーになります。このアプローチは、関係者に参加を依頼することで、彼らの関与を高める絶好の機会でもあります。さらに、結果から、開発で使用された仮定が実際には無効であることがわかる場合もあります。
その Mendix ユーザビリティテスト方法
物事をシンプルに保つという理念のもと、私たちの方法は 3 つの主なステップで構成されています。以下に各ステップと、あらゆるテスト体験を最大限に活用するためのガイドラインを示します。
テストを準備する
- 3 つのセッションを計画します - ヒント: スプリント レビューを使用してテストを実施します。
- ユーザーシナリオを定義します。
- アプリケーションを準備する Mendix テスト環境。
- パイロットテストを実施します。
テストを実施する
- 観察者はミュートし、カメラをオフにして、メモを取る必要があります。
- 参加者を指導するファシリテーターを指名します。
- ユーザーシナリオを実行するときは、参加者に「声に出して考える」ように依頼します。
- 最後の 15 分間は参加者に質問し、参加者からも質問を受けます。
テストを確認する
- 各観察者は、発見した重要なユーザビリティの問題を 3 つ提示します。
- チームは協力して、ユーザビリティに関する上位 5 つの問題を定義します。
- それぞれのユーザビリティの問題を新しいストーリー/タスクに変換し、プロジェクトのバックログに追加します。
この方法を最もよく示すために、ハッカソン アプリケーション* 用に作成したテストを例に見てみましょう。このテストの目的は、アプリケーションでハッカソン イベントを設定するときに主催者にとってのユーザビリティの問題を見つけることです。注目すべき点は、テストを実行するのにたった 1 日の午前中しかかからなかったことです。
*注: ハッカソンアプリケーションを使用すると、組織は完全なオンラインハッカソンイベントを設定して主催することができ、ハッカーは登録してソリューションをアップロードして視聴し、優勝者を見ることができます。また、ソリューションを評価して賞を授与できる審査員パネルを追加することもできます。ハッカソンアプリケーションは現在、 マーケットプレイス.
ユーザビリティテストの設定
プロジェクトの最後から 60 番目のスプリントでは、合計で XNUMX 分のセッションが XNUMX 回計画されました。これにより、チームはアプリケーションをリリースする前に最後のスプリントでユーザビリティの問題を解決することができました。関係者にアプリケーションの検証に参加してもらうために、参加者またはオブザーバーとして行動するよう依頼しました。
準備のもう 1 つの部分は、参加者のユーザー シナリオを定義することでした。チームと製品所有者は、次の質問に答えることでこれを行いました。
- 何について確信が持てないのでしょうか?
- アプリケーションで最も重要な機能は何ですか?
私たちが知りたかったことの 1 つは、主催者がアプリケーションで新しいハッカソン イベントをどのように設定したかです。彼らは、疑問や問題が発生することなくフォームに入力できましたか? 新しいイベントに必要な情報をすべて追加できると感じましたか? また、次のユーザー シナリオを作成して、参加者とともに、ニュースフィード ページにハッカー向けの投稿を残すことをテストしました。
「ハッカソン中にハッカーをサポートするには、ヒントのリストを投稿する必要があります。アプリを使用してこれらのヒントを共有します。
ヒント:
-
- 起き上がって動き回って目を覚まします。
- 眠気を解消するために昼寝をします。
- 目の疲れを防ぐために目を休めましょう。
シナリオを書き出す際には、参加者がどのようにすべてを完了したいかを決めることができるよう、最小限のガイダンスが追加されました。このようにすることで、完了するための厳格な方法を指示するよりも、より貴重な洞察が明らかになります。
次に、アプリケーションはテスト環境に追加されました。 Mendix プラットフォーム。現実的なテスト環境を生成するために、他のハッカソン イベントのダミー データを追加し、参加者がアプリケーションに入るためのユーザー アカウントを作成しました。最後に、パイロット テストを使用してテストのセットアップと環境を検証しました。
セットアップに最後の変更を加えた後、実際のユーザビリティ テストを開始する準備ができました。
ユーザビリティテストの実施
各セッションの開始時に、ファシリテーター (今回はデザイナーでしたが、チームの誰でもかまいません) がセットアップを説明し、後でチームが確認できるようにセッションを録画する許可を参加者に求めました。
セッション中、観察者はカメラをオフにし、音声をミュートして、参加者とファシリテーターのやり取りを維持しました。さらに良い方法は、参加者に誰かに監視されている（あるいは判断されている）という感覚を与えないように、観察者に「別の部屋」から観察してもらうことです。
参加者は、ユーザー シナリオを実行する際に声に出して考えるように求められました (「思考発話法」)。これにより、チームは、見ているだけの場合よりも、何が起こっているかについてより深い洞察を得ることができました。たとえば、ある参加者は「新しいハッカソン」ボタンを見つけられませんでした。彼がボタンがどこにあると思うかを「教えてくれた」おかげで、チームは、アプリケーションの最も重要なボタンの位置を改善する方法について貴重な洞察を得ることができました。
参加者がシナリオを順に進めていく間、ファシリテーターは必要に応じてガイドするだけに留まりました。信じてください。誰かが行き詰まり、自分で解決策を見つけなければならないときに、最も貴重な洞察が得られます。参加者、ファシリテーター、オブザーバーからの質問は記録され、セッションの最後の 15 分間で処理されました。この部分は、参加者の「問題点」を振り返るのに最適です。特に、「アプリケーションで変更できる点が XNUMX つあるとしたら、それは何ですか?」などのより一般的な質問をするときに役立ちます。
この例では、3 人の参加者全員がこの質問に同じ回答をしました。「ニュースフィード」ページへのナビゲーションを改善する」。観察者も、ページを見つけるのが本当に大変であることに気づいていました。
ユーザビリティテストを確認する
セッションの直後、オブザーバーとのレビュー ミーティングが行われ、調査結果について話し合いました。ミーティングの開始時に、全員が見つけた最も重要なユーザビリティの問題を 1 つ選択して発表しました。その後、チームは協力して最も重要なユーザビリティの問題を 5 つ決定し、5 (最も重要) から 7 (それほど重要ではない) までランク付けしました。重要な問題がいくつ見つかったかによって、「トップ 10」は「トップ XNUMX」や「トップ XNUMX」などになります。
私たちが見つけた重大な問題の 1 つは、アプリケーションに賞品や賞品を追加するフローが不明瞭だったことです。参加者の誰も、間違いを犯さずにそれを行うことができませんでした。その方法は、アプリの作成に携わる全員にとってあまりにも明白だったため、チームはこれを潜在的な問題として認識していませんでした。
レビューの最後に、最も重要な問題は新しいストーリー/タスクに変換され、プロジェクトのバックログに追加されました。 Mendix プラットフォームのおかげで、新しいストーリーやタスクはチームによって迅速に処理されました。その結果、1 スプリント (2 週間) 以内にアプリケーションの改善バージョンが完成しました。
結論
ユーザビリティ テストの重要な点は、複数のテストを成功裏に実施した後、そのメリットが明らかになることです。より成功する製品が製造されるだけでなく、製品がどのように使用され、どのように改善できるかを直接確認できるため、関係するチームも、ユーザビリティ テストを、参加したい開発プロセスの重要な要素として扱うようになります。
ぜひ、あなたのテストを始めてみてください。 Mendix 分野の様々なアプリケーションで使用されています。
さあ作って（そしてテストして）みましょう！