테스트를 위해 모집해야하는 사용자 유형은 이전 페르소나 설정에 의해 정의됩니다. 먼저 조사 할 시장을 조사하고 설정 한 다음이를 사용할 사용자의 프로파일을 정의해야합니다. 이 프로필이나 개인 정보가 있으면 사용자 모집을 시작할 수 있습니다.
자세한 내용은 여기를 참조하십시오.
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를 호스팅 할 수도 있습니다.
나는 전적으로 무작위 참가자를 추천하지 않을 것입니다.
치다:
도메인 지식
예 : 의료 전문가를위한 서비스 인 경우 무작위 참가자가 가질 수없는 의료 전문 용어에 대한 지식을 합법적으로 기대합니다.
정신 모델과 선입견
예 : 귀하의 서비스가 디지털 소셜 네트워크 사용률이 낮은 노인을 대상으로하는 경우, 젊은 참가자를 대상으로 한 테스트로 인해 이전 사용자에게 '공유'버튼 등에 대한 이해가 부족하지 않을 수 있습니다.
신뢰도
마지막으로, 다른 이해 당사자들이 귀하의 테스트에서 찾은 조치 결과에 대해 협의해야한다면, 그들이 이해하는 참가자를 그들의 고객 인구 통계와 일치하는 것으로 사용하는 것이 좋습니다. 이것은 합법적 인 결과를 받아들이는 것에 대한 "잘, 우리의 청중이 아닙니다"반대 의견을 제거합니다.
소싱
실제로이 사람들을 찾을 수있는 곳에 대하여; 나는 소셜 미디어 (평균적인 사람들이 ~ 5 백만 FB LinkedIn 링크드 인 연결을 가지고 있음)와 사용자 인구 통계와 대략적으로 일치하는 포럼에 내 개인 네트워크를 통해 광고함으로써 가장 성공적으로 성공했습니다. 먼저 지역 사회.