次の方法で共有


Office アドインのユーザビリティ テスト

ユーザーの動作を考慮してデザインされたアドインは優れています。 独自の先入観は設計上の決定に影響するため、実際のユーザーで設計をテストして、アドインが顧客に対して適切に機能することを確認することが重要です。

使いやすさテストはさまざまな方法で実行できます。 多くのアドイン開発者にとって、リモートでモデレートされていないユーザビリティスタディが最も時間とコスト効率に優れています。 一般的なテスト サービスは次のとおりです。

これらのテスト サービスは、テスト計画の作成を効率化し、参加者を探したりテストをモデレートしたりする必要をなくすのに役立ちます。

デザインに関するほとんどのユーザビリティの問題を見出すのに必要な参加者は 5 人だけです。 製品がユーザー中心になっていることを確認するには、開発サイクル全体にわたって小規模なテストを定期的に組み込んでください。

注:

複数のプラットフォームでアドインの使いやすさをテストすることをお勧めします。 アドインを AppSource に発行するには、定義したメソッドをサポートするすべてのプラットフォームで動作する必要があります。

1. テスト サービスにサインアップする

詳細については、「Selecting an Online Tool for Unmoderated Remote User Testing」 (モデレートされていないリモート ユーザー テスト用のオンライン ツールの選択) を参照してください。

2. 調査での質問項目を設定する

調査での質問項目を設定することにより、調査の目的を定義し、テストの計画を導いていることになります。 質問は、採用する参加者と実行するタスクを特定するのに役立ちます。 特定の観測値または広範な入力が必要な場合を理解します。

具体的な質問の例

  • ユーザーは、ランディング ページ上の "無料試用版" リンクに気が付きますか。
  • ユーザーがアドインからドキュメントにコンテンツを挿入するとき、ドキュメント内のどこに挿入されているかを理解していますか?

広範な質問の例

  • ユーザーにとってアドインの最大の懸案事項は何ですか。
  • ユーザーは、コマンド バー内のアイコンの意味を、クリックする前に理解していますか。
  • ユーザーは設定メニューを簡単に検索できますか。

ユーザー エクスペリエンスの側面

アドインの検出からインストールと使用まで、ユーザー体験全体に関するデータを取得することが重要です。 アドイン ユーザー エクスペリエンスの次の側面に対処する調査の質問を検討してください。

  • AppSource 内でのアドインの検索
  • アドインのインストールの選択
  • 初回実行時エクスペリエンス
  • リボン コマンド
  • アドイン UI
  • アドインが Office アプリケーションのドキュメント領域と相互作用する方法
  • ユーザーがコンテンツ挿入フローを制御できる程度

詳細については、「Gathering factual responses vs. subjective data」 (実際の反応と主観的データを収集する) を参照してください。

3. ターゲットとする参加者を特定する

リモートのテスト サービスで、テストの参加者の多くの特性を制御できます。 ターゲットとするユーザーの種類を慎重に検討してください。 データ収集の初期段階では、幅広く参加者を募集して、ユーザビリティの問題をより明確に識別する方が良い場合があります。 後の段階では、上級の Office ユーザー、特定の職業、特定の年齢範囲などのグループをターゲットとするよう選択することもできます。

4.参加者のスクリーナーを作成する

ススクリーンは、試験参加者に提示する一連の質問と要件で、テストのためにそれらをスクリーニングします。 UserTesting.com などのサービスの参加者は、お金目的でテストの条件を満たそうとしていることに留意してください。 テストから特定のユーザーを除外する場合は、ス画面ャーにトリックの質問を含めるのが良い方法です。

たとえば、GitHub に精通している参加者を見つけようとしている場合に、身元を偽っている可能性があるユーザーを除外するには、考えられる回答の一覧に偽の回答を組み込みます。

次のソース コード リポジトリのうちどれに精通していますか。
a. SourceShelf [Reject]
b. CodeContainer [Reject]
c. GitHub [Must select]
d. BitBucket [May select]
e. CloudForge [May select]

アドインのライブ ビルドをテストする予定の場合は、これを実行できるユーザーに対して次の質問が表示される場合があります。

このテストでは、最新バージョンの Microsoft PowerPointが必要です。 最新バージョンのPowerPointはありますか?
a. はい [必ず選択]
b. いいえ [拒否]
c. [拒否] がわからない

このテストでは、PowerPoint用の無料アドインをインストールし、それを使用する無料アカウントを作成する必要があります。 アドインをインストールして無料アカウントを作成しますか?
a. はい [必ず選択]
b. いいえ [拒否]

詳細については、「Screener Questions Best Practices」 (スクリーナーの質問のベスト プラクティス) を参照してください。

5. 参加者のタスクと質問を作成する

参加者のタスクと質問の数を制限できるように、テストしようとしている項目の優先度の設定を試みてください。 一定の時間だけ参加者に利益になるサービスもあるので、超過しないように確認することもできます。

可能な限り、参加者の動作について質問するのではなく観察するよう試みてください。 動作について質問する必要がある場合、特定の状況で参加者が行うであろうと予想することではなく、参加者が過去に行ってきたことについて質問してください。 その方が、信頼性の高い結果が得られる傾向があります。

モデレートされていないテストの主な課題は、参加者がタスクとシナリオを確実に理解することです。 指示は明確で簡潔なものである必要があります。 必然的に、混乱の可能性がある場合、誰かが混乱します。

テスト中の特定の時点で、ユーザーが表示されるはずの画面に表示されることを想定しないでください。 次のタスクを開始するにはどの画面上にいる必要があるかユーザーに伝えることを検討してください。

詳細については、「Writing Great Tasks」 (優れたタスクの作成) を参照してください。

6. タスクや質問に対応するプロトタイプを作成する

Live アドインをテストするか、プロトタイプをテストすることができます。 Live アドインをテストする場合は、Office の最新バージョンがあり、アドインのインストールを予定しており、アカウントのサインアップを予定している (ログオン資格情報を提供しない場合) 参加者を選別する必要があることに注意してください。後で、アドインを正常にインストールしたかどうかを確認する必要があります。

平均すると、ユーザーがアドインのインストール方法をひととおり実行するには約 5 分間かかります。 明確で簡潔なインストール手順の例を次に示します。 テストの仕様に基づいて手順を調整してください。

次の手順に従って、PowerPoint用のアドイン (アドイン名をここに挿入) をインストールしてください。

  1. Microsoft PowerPoint を開きます。
  2. [新しいプレゼンテーション] を選択します。
  3. [ ホーム>アドイン] を選択し、[ アドインの取得] を選択します。
  4. ポップアップ ウィンドウで、[ストア] を選択 します
  5. 検索ボックスに (アドイン名) と入力します。
  6. (アドイン名) を選択します。
  7. 少し時間を取って [ストア] ページを参照し、アドインに精通します。
  8. [追加] を選択して、アドインをインストールします。

いずれの相互作用や表示の忠実性のレベルでもプロトタイプをテストできます。 より複雑なリンクと対話性を得る場合は、 Figma のようなプロトタイピング ツールを検討してください。 静的な画面だけテストする場合は、オンラインで画像をホスティングして対応する URL を参加者に送信したり、オンラインの PowerPoint プレゼンテーションへのリンクを提供したりできます。

7.パイロット テストを実行する

プロトタイプや、タスクと質問の一覧を正しく作成するには、テクニックを要する場合があります。 ユーザーがタスクのために混乱したり、プロトタイプで途方にくれる可能性があります。 1 人から 3 人のユーザーを用いてパイロット テストを実行し、テストの形式に関する避けられない問題を解決する必要があります。 これにより、質問が明確になり、プロトタイプが正しく設定されていること、探しているデータの種類がキャプチャされていることを確認するのに役立ちます。

8.テストを実行する

テストを注文すると、参加者がテストを完了すると電子メール通知が届きます。 特定の参加者グループを対象にしていない限り、通常、テストは数時間以内に完了します。

9.結果を分析する

これは、収集したデータを理解しようとする部分です。 テストのビデオを見ている間に、ユーザーが直面した問題や成功についてメモを記録します。 すべての結果を見終えるまで、データの意味を解釈しようとしないでください。

1 人の参加者が使いやすさの問題を抱えているだけでは、設計を変更する必要はありません。 複数の参加者が同じ問題に直面している場合は、一般集団内の他のユーザーもその問題に直面するであろうことを示しています。

一般に、データを使用して結論を導き出す方法に注意してください。 データを特定の物語に合わせようとする罠に陥らないでください。データが実際に何を証明するか、反証するか、または単に洞察を提供できないかについて正直に言います。 オープンマインドを保つ。ユーザーの動作は、多くの場合、デザイナーの期待に反します。

関連項目