web-dev-qa-db-ja.com

チェックアウト時の紙のプロトタイプテスト?

チェックアウトの再設計で、ユーザーテストを数回繰り返し実行したいと思います。このプロジェクトはまだ初期段階なので、状況を十分に活用して、紙のプロトタイプでテストセッションを実行したいと思います。したがって、テストはチェックアウトの経験やフォームの記入などに重点が置かれるので、ウェブプロトタイプの非常に重点を置いた側面で紙のプロトタイプをテストするのは良い考えだと思います。

あなたはまだ良い考えだと思いますか?タスクの設定方法に関するヒントはありますか?

10
Davide

紙のプロトタイプをテストすることは、情報アーキテクチャとコンテンツの発見可能性をテストするための素晴らしいアイデアです。私は何度かそれを行い、そうすることによって有用な結果を生み出しました。ユーザーは紙を使用するときの不信を一時停止するのが得意で、プロトタイプをすばやく展開できます。 Win-Win。

問題は、インタラクティブ要素のため、Webフォームやインターフェースの動作をテストするのにasしていないということです。フォームデザインは、コンテンツの検証、自動デフォルト設定、プログレッシブ開示などの動的戦略について多くのことであり、紙に複製するのは非常に困難です。繰り返しになりますが、これらの要素はユーザビリティの最も重要な側面ではない可能性があります-ユーザーは、彼らが望むものを理解していると確信している場合、次善のフォームと混同しますそれを見つける方法、つまりそれが最大の質問であり、紙のテストで簡単に答えることができます。

もう1つの問題は、紙のプロトタイプが非常にローファイであるため、ユーザーがサービスの信頼性と「安定性」を認識する方法をテストするのが難しくなることです。また、コンテンツのブランディングもうまくいきません。これは、消費者向けの状況では重要です。

紙のプロトタイプを使用しないと言っているのではありません。データはデータがないよりも優れており、設計の問題を早く解決できればするほど、修正が安くなります。私は制限に気づいているだけです。

3

テスト方法を選択するときは、常に最初にテストの目的を尋ねる必要があります。1つの方法がすべての可能な目的に適合するわけではないためです。最も基本的なレベルでは、さまざまな方法がdiscoveryに適していますが、他の方法はvalidationに適しています。

ペーパープロトタイピングは、発見と理解のためのテスト方法であり、設計サイクルの初期に理想的に使用されます。

もちろん、ペーパープロトタイピングを使用して、Webサイトの特定のセクション、特にワークフローを表すセクションをテストできます。ペーパープロトタイピングには、いくつかの代替アプローチをすばやく簡単にテストできるだけでなく、迅速な再設計をサポートできるという利点があります(ユーザーセッションが途中である場合でも)。

プロセスにはいくつかのメタメリットもあります。

紙のプロトタイピングの利点:

ペーパープロトタイピングは、インターフェースワークフローの初期段階のテストに非常に適しています。これにより、設計モデルとユーザー固有のタスクのメンタルモデルとの間に不一致があるかどうかを発見できます。変更されたメンタルモデルを念頭に置いて、(簡単に)新しいユーザーをサイトに誘導することはできませんが、デザインモデルはいつでも変更できます。非互換性について説明することで既存のUIを単純化するのではなく、できるだけユーザーのメンタルモデルと優先ワークフローを見つけたいと考えています。

Lo-fiプロトタイプを使用すると、ユーザーは 不信を保留して、より抽象的なレベルで考えることが容易になります (つまり、問題を適応させる代わりに、問題のメンタルモデルにより近いそれらの前のインターフェースの癖を理解する)。

また、ラフな線画、美術のスケッチ、漫画の画像、さらにはワイヤーフレームのプリントアウトのコラージュミックスを使用します。 「アート」の名誉と誠実さに対する(偽の)尊敬の欠如は、参加者が相互作用しているデザインを批判するライセンスと許可を与えます。 (時々、テスト参加者は礼儀正しすぎて、設計ミスを犯したと言いたくない、または 社会的に受け入れられる答え を与えることに頼りたくない)。

Lo-fiプロトタイプを使用すると、簡単に 赤ん坊を殺す -これは、デザイナーが自分の作品に恋するときではありません。 プロトタイプは破棄されることを意図しています

紙のプロトタイピングは、コンテンツやブランディング、スタイリングなどの邪魔をせずにワークフローや基本的なUIインタラクションをテストするのにも適しています。プロセスのどの段階でユーザーが信頼の問題を抱えているのかを発見したり、コンテンツがウェブサイトからですが、サードパーティのものです。これらの弱点がどこにあるかがわかれば、影響のない場所でこれらの問題に対処する時間と労力を無駄にすることなく、確実に対処することができます。

いくつかのヒント

紙のプロトタイピングテストを行う際のヒント:

  • デザインサイクルの非常に早い段階で、おそらくワイヤーフレームの作成に進む前に、ペーパープロトタイピングを実行します。

  • 設計チーム全体をさまざまなパーツの作成に関与させる-これを早期に行うと、チーム構築の ストームとノルミング フェーズに対処するのに役立ちます。

  • 最高のスケッチャーにすべてのスケッチを実行させないでください。ラフな線画と美術のスケッチを組み合わせてもかまいません。 (このコラージュ効果は、実行の詳細に興味がないことを伝えます)

  • lo-fiスケッチを使用 可能な場合-メンタルモデルを公開するモードでユーザーを維持し、実行時の問題でハングアップしないようにします。また、設計者がトンネルのビジョンを得て、実行の詳細に取り付かれることを望まないでしょう。

  • インターフェース「ブランク」をスケッチし、それらをコピーして、すばやく再設計できるようにします(たとえば、ドロップダウンメニューのバリアントでは、メニュー項目名を追加するだけでよく、追加の図面は必要ありません)。

  • 重要度の低いページ(つまり、テスト目的にとって重要度が低い)には、既存のワイヤーフレームのプリントアウトを使用します。すばやく変更する必要がある場合は、先に進んでlo-fi紙の要素をオーバーレイします。

  • 参加者に 思考の音声プロトコル を使用するよう依頼します。

  • オペレーターとオブザーバーの少なくとも2人の関係者がいる。


サービスのカスタムチェックアウトフローにペーパープロトタイピングを使用しました。この特定のサービスには2つの相互依存セクションがあり、モジュールBの前にモジュールAを完了するのか、またはその逆を行うのかをユーザーに知らせていませんでした。テストを行い、ユーザーに大声で考えるプロトコルに従うようにさせることで、アプローチの1つとの潜在的なメンタルモデルの不一致を明らかにし、望ましいワークフローを理解しました。

また、ワークフローの前半で別の冗長なセクションを特定し、そのステップを完全に排除しました(製品の選択とプレビューのステップでした...が、発売時には1つの製品しかなかったため、たとえそれが存在してもかなり無意味でした。かなりの写真と製品の機能の箇条書き)。

7
Erics

紙のプロトタイプではなく、インタラクティブなプロトタイプテストを実行すると、メリットが得られる場合があります。これは、PowerPointまたは類似のbalsamiq種類のツールを使用して実行できます。これは、ユーザーがどのように考えているか、またはユーザーのユーザーまたは利害関係者と認知的ウォークスルーを行うために役立ちます。

紙のプロトタイプは、実際のシナリオ(ここでは実際の世界はWebの世界です)でユーザーを完全に作成するわけではないため、ユーザーの問題を理解することはできません。思考を合理化することは良いことですが、インタラクティブなプロトタイピングは、タスクを設定して効率的にテストするのに役立ちます。

タスクを設定するときは、人々が話し合っている問題のケースを書いてみてください。紙のプロトタイプで参加型の設計セッションを実行し、ユーザーのタスクをチェックして、意思決定が意図したとおりに行われたかどうかを確認することもできます。

幸せなプロトタイピング!

1
inkmarble

現在、チェックアウトもテストしています。

私の意見は次のとおりです:テストが現実的であるほど良い

最初の反復:実際のWebサイト、偽のデータ—現在のチェックアウトソリューションの落とし穴を見つけて、何を改善すべきかを知るのに適しています。

2回目の反復:改善されたデザインのクリック可能なプロトタイプのインビジョン。準備は比較的簡単で、ユーザーの体験がかなり現実的であったことを除いて、ユーザーはジェスチャーエラーをほとんど発生しませんでした。多くの有用な発見。

紙のプロトタイプはアイデアを探索するのに適していると思います。ユーザーが近くにいる場合は、デザインスプリント中にすばやくテストします。可能な限り現実的なアプローチを採用することをお勧めします。完全に機能するプロトタイプを提供できる場合はそれを、要求が厳しすぎる場合は高忠実度のクリック可能なプロトタイプを使用してください。

0
Anton T