출시 전 사용성 테스트의 핵심 답변
사업 홈페이지, 랜딩페이지, SaaS 가입 화면, 관리자 화면을 출시하기 전에는 내부에서 예쁘다·괜찮다를 평가하는 대신 실제 사용자에게 3~5개의 대표 과업을 수행하게 해야 합니다. 목표는 디자인 선호도를 묻는 것이 아니라 사용자가 첫 화면의 가치 제안을 이해하는지, 신뢰할 근거를 찾는지, CTA를 다음 행동으로 인식하는지, 입력 흐름에서 멈추지 않는지를 확인하는 것입니다.
소규모 팀이라면 한 번에 큰 리서치를 벌이기보다 핵심 세그먼트 5명 안팎으로 짧게 테스트하고, 수정 후 다시 3~5명으로 확인하는 방식이 현실적입니다. Nielsen Norman Group은 정성 사용성 테스트에서 5명 테스트가 비용 대비 발견 효율이 높지만, 정량 통계나 서로 다른 사용자 그룹을 검증할 때는 더 많은 참가자가 필요하다고 설명합니다. 즉, 5명은 마법의 숫자가 아니라 ‘같은 유형의 사용자가 같은 과업을 수행할 때’의 출발점입니다. ([nngroup.com](https://www.nngroup.com/articles/how-many-test-users/))
1. 사용성 테스트는 디자인 평가가 아니라 사업 가설 검증이다
많은 팀이 홈페이지 개편 후 전환이 오르지 않으면 색상, 이미지, 버튼 크기부터 바꿉니다. 하지만 실제 문제는 다른 곳에 있을 수 있습니다. 방문자가 이 서비스가 누구를 위한 것인지 이해하지 못했을 수도 있고, 가격이나 도입 절차가 불명확해 문의를 미뤘을 수도 있습니다. SaaS에서는 가입 버튼을 눌렀지만 이메일 인증, 권한 설정, 첫 데이터 입력에서 막히는 경우도 흔합니다.
사용성 테스트는 이런 추측을 줄이는 절차입니다. 특히 B2B에서는 구매자, 실사용자, 관리자, 결재자가 다를 수 있어 화면의 ‘이해 가능성’과 ‘신뢰 가능성’을 분리해서 봐야 합니다. 예를 들어 대표는 고객사 로고가 충분하다고 생각하지만, 실무 담당자는 보안 처리 방식과 도입 후 지원 범위를 먼저 찾을 수 있습니다. 마케터는 CTA 문구를 강조하고 싶어 하지만, PM은 가입 후 첫 설정 화면에서 사용자가 아무 데이터도 넣지 못하는 문제를 더 크게 봐야 할 수 있습니다.
Stanford Web Credibility Project의 웹 신뢰성 가이드라인도 웹사이트의 신뢰를 높이는 요소로 정보 검증 가능성, 실제 조직의 존재, 전문성, 연락 가능성, 전문적인 시각 디자인, 오류 없는 운영 등을 제시합니다. 사업 홈페이지에서 신뢰 요소를 검증한다는 것은 로고를 더 붙이는 일이 아니라 사용자가 ‘이 회사가 실제로 문제를 해결할 수 있겠다’고 판단하는 근거를 화면 안에서 찾는지 보는 일입니다. ([credibility.stanford.edu](https://credibility.stanford.edu/guidelines/index.html))
2. 테스트 전에 먼저 정해야 할 5가지 질문
사용성 테스트가 실패하는 가장 흔한 이유는 목적이 너무 넓기 때문입니다. ‘홈페이지를 테스트한다’가 아니라 ‘방문자가 첫 화면에서 대상 고객과 핵심 가치를 10초 안에 설명할 수 있는가’처럼 질문을 좁혀야 합니다. Digital.gov의 리서치 계획서 모델도 연구 목표, 질문, 방법, 역할, 일정, 참가자 모집 조건을 문서화하라고 안내합니다. 계획이 없으면 세션은 대화로 끝나고, 개발 백로그로 이어지기 어렵습니다. ([digital.gov](https://digital.gov/resources/how-write-research-plan))
| 검증 영역 | 좋은 테스트 질문 | 나쁜 테스트 질문 |
|---|---|---|
| 가치 제안 | 첫 화면만 보고 어떤 문제를 해결하는 서비스라고 이해했는가? | 이 문구 마음에 드나요? |
| 신뢰 요소 | 문의하기 전에 더 확인하고 싶은 근거는 무엇인가? | 고객사 로고를 더 크게 할까요? |
| CTA | 다음 행동을 하려면 어떤 버튼을 누를 것 같은가? | 파란 버튼과 검은 버튼 중 무엇이 예쁜가? |
| 폼 흐름 | 어떤 항목에서 입력을 망설였고, 왜 그런가? | 폼이 짧아 보이나요? |
| SaaS·관리자 화면 | 첫 업무를 완료하기 위해 어디서 시작해야 한다고 판단했는가? | 이 대시보드가 세련돼 보이나요? |
좋은 테스트 질문은 행동과 판단 근거를 봅니다. 사용자가 버튼을 못 찾았는지, 버튼은 찾았지만 누를 이유를 못 느꼈는지, 폼은 작성했지만 제출 전 불안이 생겼는지는 서로 다른 문제입니다. 이 구분이 되어야 카피 수정, UI 구조 변경, 백엔드 검증 로직 개선, CRM 연동, 관리자 화면 개선 중 어디에 개발 리소스를 써야 할지 결정할 수 있습니다.
3. 몇 명을 모집해야 할까: 5명 원칙보다 중요한 세그먼트
작은 팀은 보통 ‘최소 몇 명이면 되나요’라고 묻습니다. 실무 기준으로는 같은 유형의 사용자가 같은 과업을 수행하는 정성 테스트라면 5명 안팎으로도 핵심 문제를 많이 발견할 수 있습니다. 다만 B2B SaaS에서는 사용자 그룹이 실제로 다를 수 있습니다. 구매 검토자는 가격, 보안, 도입 사례를 보고, 운영 담당자는 엑셀 업로드, 권한, 알림, 내보내기 기능을 봅니다. 이 둘을 한 그룹으로 묶으면 테스트 결과가 흐려집니다.
| 상황 | 권장 모집 | 주의할 점 |
|---|---|---|
| 단일 랜딩페이지, 동일 타깃 | 대표 고객 조건 5명 안팎 | 광고 유입 맥락을 시나리오에 반영 |
| B2B 구매자와 실사용자가 다름 | 각 그룹 3~5명 | 구매 판단 과업과 업무 수행 과업을 분리 |
| 관리자·일반 사용자 권한이 다름 | 권한별 3명 이상 | 권한 오류와 메뉴 노출 문제를 별도 기록 |
| 정량 비교나 통계 보고가 필요 | 20명 이상 등 별도 설계 | 정성 발견과 정량 검증을 혼동하지 않기 |
초기 창업팀이나 정부지원 MVP 단계에서는 완벽한 표본보다 ‘실제 고객 조건에 가까운 사람’을 찾는 것이 더 중요합니다. 지인이나 내부 직원은 화면 용어와 사업 맥락을 이미 알고 있어 불신이나 혼란을 덜 드러냅니다. 내부 인원은 사전 점검용으로 쓰고, 출시 판단에는 외부 참가자를 포함해야 합니다.
4. 원격, 대면, 비동반 테스트 선택 기준
홈페이지와 SaaS 화면 테스트는 대부분 원격으로 충분합니다. 화면 공유를 켜고 참가자가 자신의 노트북 환경에서 실제로 탐색하게 하면 브라우저 탭, 보안 프로그램, 회사 메신저, 화면 크기 같은 현실적인 맥락도 함께 볼 수 있습니다. NN/g는 원격 사용성 테스트가 예산이나 일정 제약, 지리적으로 흩어진 참가자 모집에 유용하며, 대면이 불가능할 때 테스트를 생략하는 것보다 낫다고 설명합니다. 진행자 동반 원격 테스트와 비동반 테스트는 실시간 질문 가능 여부가 가장 큰 차이입니다. ([nngroup.com](https://www.nngroup.com/articles/remote-usability-tests/))
| 방식 | 적합한 경우 | 장점 | 주의점 |
|---|---|---|---|
| 원격 진행자 동반 | 랜딩페이지, 가입 흐름, 관리자 화면의 원인 파악 | 막힌 이유를 즉시 질문 가능 | 진행자가 힌트를 주지 않도록 스크립트 필요 |
| 원격 비동반 | 문구, 첫 클릭, 간단한 과업을 빠르게 많이 확인 | 일정 조율 부담이 낮음 | 오해가 생겨도 현장에서 바로 복구하기 어려움 |
| 대면 테스트 | 현장 장비, 오프라인 업무, 다자 협업이 포함된 서비스 | 표정, 몸짓, 주변 환경 관찰 가능 | 장소·이동·일정 비용이 큼 |
| 내부 파일럿 | 오탈자, 링크 오류, 치명적 버그 사전 제거 | 빠르고 저렴함 | 고객의 불신과 구매 망설임을 대체할 수 없음 |
소규모 팀의 기본값은 원격 진행자 동반 테스트입니다. 30~45분 동안 첫인상 확인, 3~5개 과업 수행, 후속 질문, 마무리 질문을 진행하면 충분한 의사결정 자료를 얻을 수 있습니다. 단, 비동반 테스트를 선택할 때는 안내 문구와 과업을 사전에 파일럿해야 합니다. 참가자가 지시문을 오해하면 결과 전체가 무의미해질 수 있습니다.
5. 과업 시나리오는 사용자의 목표로 써야 한다
사용성 테스트에서 가장 중요한 문서는 질문지가 아니라 과업 시나리오입니다. NN/g는 좋은 과업 시나리오가 현실적이고, 사용자의 행동을 유도하며, 인터페이스의 정답을 미리 알려주지 않아야 한다고 설명합니다. 예를 들어 ‘상단 메뉴의 요금제를 클릭해 보세요’는 CTA와 정보구조를 검증하지 못합니다. ‘팀에서 이 서비스를 도입할지 검토 중입니다. 비용과 도입 조건을 확인해 보세요’가 더 낫습니다. ([nngroup.com](https://www.nngroup.com/articles/task-scenarios-usability-testing/))
사업 홈페이지·랜딩페이지 예시
- 당신은 제조업체의 운영팀장입니다. 반복되는 엑셀 취합 업무를 줄일 수 있는 솔루션을 찾고 있습니다. 이 페이지를 보고 어떤 서비스인지 파악해 주세요.
- 대표에게 공유하기 전에 이 회사가 믿을 만한지 확인하려고 합니다. 어떤 정보를 찾아보겠습니까?
- 도입 상담을 요청할지 판단해야 합니다. 상담 전에 부족하다고 느끼는 정보가 무엇인지 말해 주세요.
SaaS 가입·온보딩 예시
- 무료 체험을 시작해 첫 워크스페이스를 만들고, 팀원 한 명을 초대해 주세요.
- 샘플 데이터를 넣어 첫 리포트를 확인해 주세요.
- 결제 전 어떤 제한이 있는지 확인해 주세요.
관리자 화면 예시
- 신규 고객사 계정을 만들고 관리자 권한을 부여해 주세요.
- 지난주 실패한 자동화 작업을 찾아 원인을 확인해 주세요.
- 특정 사용자의 개인정보 조회 권한을 회수해 주세요.
이때 참가자에게 ‘생각나는 것을 말해 달라’고 요청하되, 진행자는 답을 설명하지 않아야 합니다. Digital.gov의 사용성 테스트 진행 예시도 참가자에게 정답이 없고 솔직한 반응이 필요하다고 안내하면서, 진행자가 바로 답하지 않을 수 있음을 사전에 알리도록 구성되어 있습니다. ([digital.gov](https://digital.gov/resources/how-conduct-usability-test))
6. 관찰 지표: 전환율 대신 먼저 볼 것들
사용성 테스트의 목적은 전환율을 직접 예측하는 것이 아닙니다. 5명의 테스트로 ‘전환율이 몇 퍼센트 오른다’고 말하면 과장입니다. 대신 전환을 방해하는 원인을 관찰해 수정 우선순위를 정할 수 있습니다. 전환율은 출시 후 분석, 이벤트 추적, A/B 테스트로 검증하고, 사용성 테스트는 왜 막히는지를 밝히는 데 집중해야 합니다.
| 지표 | 기록 방식 | 해석 기준 |
|---|---|---|
| 과업 성공 | 성공·부분 성공·실패 | 완료 여부보다 어디서 멈췄는지 기록 |
| 첫 해석 | 첫 화면을 본 뒤 자기 말로 설명 | 내부 용어를 반복하면 이해가 아니라 복사일 수 있음 |
| CTA 선택 | 다음 행동으로 누른 버튼과 이유 | 버튼 위치 문제인지, 행동 명분 부족인지 분리 |
| 신뢰 이의제기 | 불안, 의심, 추가 확인 요구 | 가격, 보안, 사례, 연락처, 운영 주체별로 분류 |
| 입력 마찰 | 망설인 필드, 오류, 재입력, 포기 | 필수값, 안내 문구, 오류 메시지, 개인정보 부담을 구분 |
| 회복 가능성 | 오류 후 스스로 복구했는지 | 실패보다 복구 불가능한 상태가 더 위험 |
특히 문의·가입·결제 화면은 접근성과도 연결됩니다. WCAG 2.2는 입력 오류가 자동 감지되면 오류 항목과 내용을 텍스트로 설명하고, 입력이 필요한 콘텐츠에는 라벨이나 안내를 제공해야 한다고 제시합니다. 폼 개선이 필요하다면 내부 글인 폼 UX 최적화 가이드와 함께 오류 메시지, 필수값, 단계 분리, 개인정보 부담을 함께 점검하는 것이 좋습니다. ([w3.org](https://www.w3.org/TR/WCAG22/))
7. 1주 안에 실행하는 실무 프로세스
리서치 조직이 없는 팀도 작게 시작할 수 있습니다. 핵심은 세션 자체보다 전후 준비입니다. 다음 절차는 홈페이지 개편, SaaS 가입 흐름, 정부지원사업 MVP 출시 전 점검에 모두 적용할 수 있습니다.
- Day 1: 테스트 목표 확정 - 이번 테스트에서 반드시 판단할 질문을 3개 이하로 정합니다. 예: 첫 화면 이해, 상담 CTA, 가입 폼 부담.
- Day 2: 참가자 조건과 스크리너 작성 - 업종, 역할, 구매 경험, 현재 문제, 사용 기기, 경쟁 대안 경험을 확인합니다.
- Day 3: 과업 시나리오와 진행 스크립트 작성 - 힌트가 들어간 단어를 제거하고 내부 1명으로 파일럿합니다.
- Day 4~5: 세션 진행 - 한 명씩 진행하고, 최소 한 명은 관찰자로 들어와 타임스탬프와 발화를 기록합니다.
- Day 5: 즉시 디브리프 - 세션 직후 15분 안에 관찰자와 심각한 문제를 정리합니다. 기억에 의존한 주간 회의보다 정확합니다.
- Day 6: 패턴 합성 - 참가자별 메모를 화면·과업·문제 유형별로 묶습니다.
- Day 7: 수정 백로그 작성 - 카피, UI, 프론트엔드, 백엔드, 운영 정책으로 나눠 다음 스프린트에 넣습니다.
Digital.gov는 사용성 테스트의 유용성을 높이기 위한 조건으로 명확한 목적, 실제 사용자를 반영한 참가자, 비유도 질문, 관찰자 역할 분리, 기록, 패턴 분석, 우선순위화, 제품 백로그 반영을 제시합니다. 이 기준은 스타트업과 민간 SaaS 팀에도 그대로 적용됩니다. ([digital.gov](https://digital.gov/resources/how-conduct-usability-test))
8. 발견사항을 우선순위로 바꾸는 방법
테스트 리포트가 실패하는 순간은 ‘참가자 A는 이렇게 말했다’가 끝일 때입니다. 좋은 리포트는 관찰을 제품 결정으로 바꿉니다. 문제마다 증거, 영향, 빈도, 수정 난이도를 붙여야 합니다.
| 항목 | 기록 예시 |
|---|---|
| 문제 요약 | 첫 화면에서 ‘자동화 대상 업무’가 무엇인지 설명하지 못함 |
| 영향 화면 | 홈페이지 hero, 기능 섹션, 상담 CTA |
| 관찰 증거 | 5명 중 3명이 서비스 범위를 CRM으로 오해 |
| 사업 영향 | 적합 고객이 상담 전에 이탈할 가능성 |
| 심각도 | 높음: 핵심 가치 이해 실패 |
| 권장 수정 | H1을 결과 중심으로 변경, 적용 업무 예시 3개를 CTA 위에 배치 |
| 개발 범위 | 카피·레이아웃 수정, 이벤트명 변경, 반응형 확인 |
우선순위는 단순 빈도만으로 정하면 안 됩니다. 한 명만 겪은 문제라도 결제, 개인정보, 권한, 데이터 삭제처럼 위험도가 높으면 즉시 수정해야 합니다. 반대로 5명 모두 언급한 색상 취향이라도 과업 실패와 관련이 없다면 후순위일 수 있습니다.
9. 프론트엔드 개선으로 연결할 때의 체크리스트
사용성 테스트는 리서치 문서로 끝나면 비용이 됩니다. 화면과 코드에 반영되어야 자산이 됩니다. 프론트엔드 관점에서는 다음 항목을 함께 봐야 합니다.
- 메시지 구조: H1, 서브카피, 기능명, 고객 사례, CTA가 같은 약속을 말하는가?
- 정보 위계: 구매자가 먼저 봐야 할 신뢰 정보와 실사용자가 봐야 할 기능 정보가 섞여 있지 않은가?
- CTA 일관성: ‘문의하기’, ‘상담 신청’, ‘무료 진단’이 같은 행동인지 다른 행동인지 명확한가?
- 폼 상태: 입력 전 안내, 입력 중 검증, 오류 후 복구, 제출 후 확인 상태가 모두 있는가?
- 반응형: 모바일에서 핵심 신뢰 정보와 CTA가 지나치게 아래로 밀리지 않는가?
- 성능: 첫 화면이 늦게 뜨거나 레이아웃이 흔들려 신뢰를 떨어뜨리지 않는가? 이 부분은 Core Web Vitals 최적화 가이드와 함께 점검할 수 있습니다.
- 이벤트 추적: CTA 클릭, 폼 시작, 필드 오류, 제출 성공, 온보딩 완료 이벤트가 남는가?
- 관리자 화면 피드백: 저장 완료, 실패, 권한 부족, 처리 중, 빈 상태가 사용자의 다음 행동을 안내하는가?
MVP 단계라면 모든 문제를 한 번에 고치려 하지 말고, 사업 가설과 연결된 화면부터 수정해야 합니다. 예를 들어 정부지원사업 MVP에서 ‘AI 자동 리포트 생성’이 핵심 가설이라면 랜딩페이지보다 첫 데이터 입력과 리포트 생성 완료 경험이 더 중요할 수 있습니다. 출시 후 지표 설계는 MVP 검증 지표 설계 가이드와 연결해 보는 것이 좋습니다.
10. 테스트 진행 시 반드시 피해야 할 실수
사용성 테스트의 적은 예산 부족이 아니라 유도 질문, 잘못된 참가자, 기록 없는 회의, 실행되지 않는 리포트입니다.
- 대표가 직접 진행한다: 참가자가 솔직히 비판하기 어렵고, 대표가 설명을 시작할 가능성이 큽니다.
- 좋은지 묻는다: 사람들은 예의상 좋다고 답합니다. 실제 과업을 수행하게 해야 합니다.
- 한 화면에 너무 많은 가설을 넣는다: 메시지, 가격, 가입, 관리자 기능을 한 세션에 모두 보려 하면 결과가 흐려집니다.
- 테스트 중 바로 설득한다: 사용자가 오해했을 때 설명하고 싶어도 참아야 합니다. 그 오해가 바로 데이터입니다.
- 녹화·개인정보 동의를 생략한다: 화면 녹화, 음성, 이름, 회사 정보가 남는다면 사전 동의와 보관 기준이 필요합니다. Digital.gov의 참가자 동의 예시는 자발적 참여, 녹화, 개인정보 보호, 접근성 편의, 철회 권리를 포함합니다. ([digital.gov](https://digital.gov/resources/how-develop-user-testing-participant-agreements))
- 히트맵만 보고 결론을 낸다: 히트맵은 어디를 봤는지 알려줄 수 있지만 왜 불신했는지는 말해주지 않습니다.
11. 바로 사용할 수 있는 세션 스크립트 요약
아래 스크립트는 30~45분 원격 진행자 동반 테스트 기준입니다. 팀 상황에 맞게 줄여 쓰면 됩니다.
- 소개: 오늘은 참가자를 평가하는 자리가 아니라 화면을 개선하기 위한 자리라고 설명합니다.
- 동의: 녹화 여부, 사용 범위, 익명 처리, 중단 가능성을 안내합니다.
- 배경 질문: 현재 업무, 유사 서비스 경험, 문제 상황을 5분 이내로 확인합니다.
- 첫인상: 첫 화면을 10~20초 보고 어떤 서비스인지 말하게 합니다.
- 과업 수행: 시나리오를 하나씩 제시하고, 참가자가 실제로 클릭하고 입력하게 합니다.
- 후속 질문: 막힌 지점, 불안했던 지점, 더 확인하고 싶은 정보를 묻습니다.
- 마무리: 가장 바꾸고 싶은 한 가지, 문의 또는 가입을 망설인 이유를 묻습니다.
세션이 끝나면 참가자별 전체 후기를 길게 정리하기보다 과업별 표로 합치는 편이 좋습니다. 화면 단위로 문제가 모이면 프론트엔드 수정 범위가 보이고, 과업 단위로 문제가 모이면 제품 흐름 수정이 보입니다.
12. AgentMit가 보는 사용성 테스트의 위치
AgentMit는 사용성 테스트를 별도의 리서치 이벤트로만 보지 않습니다. 사업 홈페이지, SaaS, AI 서비스, 관리자 대시보드, 업무 자동화 화면은 테스트 결과가 곧 화면 구조, 프론트엔드 구현, 이벤트 추적, 운영 정책으로 이어져야 합니다. 특히 BizMit처럼 업무 흐름을 다루는 서비스에서는 사용자가 첫 업무를 완료하기 전까지의 빈 상태, 권한, 오류, 데이터 입력 흐름이 전환만큼 중요합니다.
내부에 리서치 담당자가 없거나, 테스트 결과를 개발 항목으로 바꾸기 어려운 팀이라면 AgentMit가 테스트 설계, 과업 시나리오, 원격 세션 운영, 화면 개선안, 프론트엔드·관리자 화면 반영, 리포트 정리까지 함께 도울 수 있습니다. 다만 먼저 팀 내부에서 위 체크리스트로 3명이라도 관찰해 보시길 권합니다. 한 번이라도 실제 사용자가 멈추는 장면을 보면, 다음 개발 우선순위가 훨씬 선명해집니다.
참고한 자료
- NN/g의 참가자 수 관련 글은 5명 안팎의 정성 테스트와 예외 조건을 정리하는 데 참고했습니다. ([nngroup.com](https://www.nngroup.com/articles/how-many-test-users/))
- NN/g의 원격 사용성 테스트 글은 원격 진행자 동반·비동반 방식의 차이를 설명하는 데 참고했습니다. ([nngroup.com](https://www.nngroup.com/articles/remote-usability-tests/))
- NN/g의 과업 시나리오 글은 현실적이고 힌트를 주지 않는 과업 작성 기준에 참고했습니다. ([nngroup.com](https://www.nngroup.com/articles/task-scenarios-usability-testing/))
- Digital.gov의 사용성 테스트 및 리서치 계획 자료는 세션 구성, 관찰자 역할, 기록·합성 기준을 정리하는 데 참고했습니다. ([digital.gov](https://digital.gov/resources/how-conduct-usability-test)) ([digital.gov](https://digital.gov/resources/how-write-research-plan))
- Stanford Web Credibility Project와 WCAG 2.2는 신뢰 요소와 입력 흐름 점검 기준에 참고했습니다. ([credibility.stanford.edu](https://credibility.stanford.edu/guidelines/index.html)) ([w3.org](https://www.w3.org/TR/WCAG22/))
FAQ
Q1. 사용성 테스트는 몇 명으로 해야 하나요?
정성 테스트라면 한 세그먼트당 5명 안팎으로 시작하는 것이 실무적으로 적절합니다. 단, 의사결정자와 실사용자처럼 행동이 크게 다른 그룹이 있으면 그룹별로 3~5명을 따로 모집하는 편이 낫습니다.
Q2. 원격 테스트와 대면 테스트 중 무엇이 좋나요?
사업 홈페이지, 랜딩페이지, SaaS 가입 흐름은 대부분 화면 공유 기반 원격 진행으로도 충분합니다. 복잡한 현장 업무, 기기 사용, 여러 사람이 함께 처리하는 오프라인 프로세스까지 봐야 한다면 대면 테스트가 더 적합합니다.
Q3. 랜딩페이지 사용성 테스트에서 무엇을 물어봐야 하나요?
좋아 보이는지보다 사용자가 첫 화면을 보고 무엇을 제공하는 서비스인지, 누구에게 필요한지, 왜 믿어도 되는지, 다음에 무엇을 눌러야 하는지 자기 말로 설명할 수 있는지를 확인해야 합니다.
Q4. 내부 직원이나 지인으로 테스트해도 되나요?
초기 오탈자나 심각한 화면 오류를 찾는 용도로는 가능합니다. 하지만 가치 제안, 신뢰, 구매 불안, 폼 부담을 검증하려면 실제 고객 조건에 가까운 외부 참가자가 필요합니다.
Q5. 사용성 테스트 결과를 개발팀에 어떻게 전달해야 하나요?
문제 목록만 전달하지 말고 과업, 관찰 증거, 심각도, 영향을 받는 화면, 권장 수정안, 개발 범위를 함께 정리해야 합니다. 그래야 카피 수정, 컴포넌트 변경, 이벤트 추적, 백엔드 검증 로직까지 실행 항목으로 이어집니다.
