テストのために採用する必要があるユーザーのタイプは、ペルソナの以前の確立によって定義されます。まず、対象となる市場を調査して確立し、次にそれらを使用するユーザーのプロファイルを定義する必要があります。このプロファイルまたはペルソナがあれば、ユーザーの募集を開始できます。
あなたはここでそれについてもっと読むことができます：
http://www.uxmatters.com/mt/archives/2010/10/using-personas-during-design-and-documentation.php
私は最近、UserTesting.comサービスについて学びました。これは興味深いオプションのようですが、対面テストの価値を過小評価することはありません。時間があれば、個人的にテストを行うことをお勧めします。そうでない場合、まあ、いくつかのテストは常になしよりも優れています。
Steve Krugは Do n't Make Me Think で述べています。インターフェースを理解するためにドメインの専門知識が必要でない限り、ほとんどの人（それが妥当な範囲内）でテストすると、貴重な洞察が得られます。ペルソナがある場合は、それらのペルソナを代表する人々とテストしてください。
ここでランダムに数人を選ぶのは良いことです。作成したペルソナを検証するのに役立ちます。
私は家族や友人のアプローチで多くの成功を収めてきました。家族、友人、同僚などを招待して、家族や友人を招待します。本のバウチャーのような小さなインセンティブを提供すれば、通常、テストを実行するのに十分なユーザーを獲得できます。
- 製品の作成（または開発）に関わるチームで製品をテストすることをお勧めします。このパフォーマンス測定は、実際のユーザーのパフォーマンスをほぼ完璧にするための有用なベースラインとして役立ちます。たとえば、UIの設計/構築に関与する開発者がユーザビリティタスクを完了するのに10分かかり、別のユーザー（フィールド内）が20分かかる場合、このユーザーは「エキスパート」ユーザーと比較して50％の効率で実行しています。
- 開発者によるテストでは、テストとテスト結果の受け入れの賛同が生まれます。部屋には、参加者が愚かすぎてタスクを理解できないとコメントする誰かが（ユーザーのインターフェースの操作を見て）常にいます。
- 今後の調査のために、テストに参加したユーザーのデータベースを維持することもお勧めします。
- 特にタスクが自己完結型である場合、AmazonのMechanical Turkで評価するためにシンプルなUIをホストすることもできます。
私は完全にランダムな参加者を強く勧めません。
検討してください：
ドメインの知識
例：それが医療専門家向けのサービスである場合、無作為の参加者が所有していない可能性がある医療ジャロンについての知識が正当に期待されます。
メンタルモデルと先入観
例えば。サービスがデジタルソーシャルネットワークの使用があまり一般的でない高齢者向けである場合、若い参加者によるテストでは、「共有」ボタンなどを理解していない高齢ユーザーを明らかにできない場合があります。
信頼性
最後に、他の利害関係者にテストからの発見事項を行動するように呼びかける必要がある場合は、彼らが顧客の人口統計と一致すると考えている参加者を使用することをお勧めします。これにより、正当な調査結果を受け入れることに対する「まあ、彼らは私たちの聴衆ではない」という異議がなくなります。
ソーシング
これらの人々を実際に見つける場所について;私はソーシャルメディア（平均的な人々は約500万の第3度のFB、LinkedIn接続を持っています）とユーザーの人口統計にほぼ対応するフォーラムを通じて広告を掲載することで最も成功しましたが、もちろん、そのような信頼できるメンバーになる必要があります最初にコミュニティ。