사용성 테스트 태스크 예시: 경로를 알려 주지 않고 목표 쓰기

좋은 사용성 테스트 과제는 참여자에게 목표와 행동에 필요한 맥락을 주되, 그 목표에 이르는 경로는 직접 찾게 합니다. 기대하는 결과는 진행자용 메모에 따로 적으세요. 검증하려는 메뉴, 버튼, 순서를 과제 문구에서 알려 주면 인터페이스를 이해하는 능력보다 지시를 따르는 능력을 측정하게 될 수 있습니다.

사용자와 검토할 프로토타입을 만들 때는 모든 화면을 다듬기 전에 현실적인 과제 몇 개를 먼저 준비하세요. 아래에서는 운영 대시보드를 예로 듭니다. 팀원이 주간 배송 보고서를 찾고, 배송지를 바꾸고, 내보내기 실패를 해결하는 세 가지 과제는 서로 다른 설계 결정을 드러냅니다.

조사 질문·참여자 과제·관찰할 결과 구분하기

아직 모르는 것부터 정하세요. ‘대시보드가 쉬운가?’보다 ‘주간 보고서를 찾을 수 있는가?’가 범위가 분명하고 다음 행동으로 이어지기 쉽습니다. 참여자에게는 그 정보가 왜 필요한지 설명합니다. 결과 기준에는 어떤 관찰 가능한 행동이 조사 질문에 답하는지 적습니다.

결과 기준에서 특정 클릭 경로 하나만 요구하지 않은 것은 의도적입니다. 인터페이스가 다른 유효한 경로를 제공한다면 그것도 기록하세요. 참여자가 올바른 건수를 말했지만 잘못된 기간의 보고서를 내보냈다면 전체 과제를 성공으로 처리해서는 안 됩니다. 정보를 찾는 것과 의도한 결과물을 만드는 것을 구분합니다.

Nielsen Norman Group의 과제 작성 안내(영문)는 인터페이스 용어와 정해진 절차가 참여자를 유도할 수 있다고 설명합니다. 초안을 검토할 때 이 원칙을 적용하되, 실제 고객이 아는 일상적인 용어까지 모두 없애지는 마세요. 익숙한 단어를 전부 빼면 현실적인 과제가 수수께끼처럼 바뀔 수 있습니다.

해답을 알려 주는 지시문 고치기

과제 문구를 실제 인터페이스와 비교하세요. 화면 라벨과 같은 표현을 표시한 뒤, 고객이 자연스럽게 쓰는 용어인지 경로를 알려 주는 단서인지 판단합니다. ‘배송지’는 고객도 쓰는 말일 수 있습니다. ‘배송 환경설정 관리자’처럼 제품 메뉴에만 있는 이름은 더 자연스러운 설명으로 바꾸는 편이 좋습니다.

참여자가 임의로 정하기 어려운 정보는 제공하세요. 보고 기간, 가상의 배송지, 팀에서 맡은 역할 등이 여기에 해당합니다. 기억 부담을 늘리는 복잡한 이야기는 피합니다. 민감한 정보에는 가상 데이터를 사용하고, 조사용 프로토타입에 개인의 금융 정보나 계정 인증 정보를 입력하도록 요구하지 마세요.

현실적인 시작 상태 준비하기

과제 문구가 좋아도 프로토타입에 찾아야 할 정보가 없다면 조사가 제대로 이루어질 수 없습니다. 배송 보고서 예에서는 적어도 두 개의 비교 가능한 기간을 준비하고, 지연 배송과 정시 배송을 구분하며, 내보낸 자료가 선택한 기간과 일치하게 만드세요. 모든 경로가 같은 성공 화면으로 이어진다면 참여자가 선택을 이해했는지 알 수 없습니다.

각 과제에 역할, 현재 화면, 기존 데이터, 이미 일어난 일, 의도적으로 제공하지 않는 내용을 적은 시작 상태 메모를 준비합니다. 내보내기 복구 과제는 실패하거나 중단된 요청에서 시작해야 합니다. 먼저 내보내기에 성공하게 한 다음, 다른 곳에 숨어 있는 실패를 상상하도록 요구하지 마세요.

과제들이 독립적인지, 이어지는 이야기인지도 정해야 합니다. 같은 계정을 계속 사용하면 준비는 줄어들지만 학습 효과가 생깁니다. 첫 과제가 두 번째 과제에 필요한 메뉴를 알려 줄 수 있기 때문입니다. 탐색 경로를 발견하는 능력이 중요하다면 적절한 경우 세션마다 과제 순서를 달리하거나, 뒤의 과제는 앞선 노출 이후에 수행했다는 점을 기록하세요. 시작할 때의 지식이 같았던 것처럼 비교해서는 안 됩니다.

세션 전에 진행자 메모 작성하기

각 과제에서 완료, 부분 완료, 중단, 도움 제공을 어떻게 구분할지 정하세요. 진행자가 보고서 메뉴를 가리킨 뒤 올바른 파일을 내려받은 참여자와 스스로 찾은 참여자는 서로 다른 결과입니다. 단순한 성공 표시에 도움을 감추지 말고 실제로 제공한 내용을 기록합니다.

‘지금 무엇을 찾고 계신가요?’, ‘다음에는 어떻게 하시겠어요?’처럼 중립적인 질문을 준비하세요. ‘메뉴를 열어 보셨나요?’처럼 해결 경로를 알려 주는 질문은 피합니다. 더 이상 진전이 없을 때 언제 과제를 끝낼지는 조사 목적과 참여자의 편안함을 기준으로 정하세요. 모든 연구에 적용할 임의의 제한 시간보다 진행자의 일관된 판단 기준이 필요합니다.

관찰과 해석은 따로 기록합니다. ‘배송 집계를 찾다가 결제 메뉴를 두 번 열었다’는 관찰 근거입니다. ‘보고서는 결제 메뉴 아래에 있어야 한다’는 가설입니다. 다음 디자인에는 더 명확한 보고서 라벨, 맥락에 맞는 링크, 다른 정보 묶음이 필요할 수 있습니다. 한 번의 잘못된 이동이 정답을 바로 알려 주는 것은 아닙니다.

Pixso에서 과제 흐름 만들기

Pixso에서 대시보드, 보고 기간 선택, 보고서 미리보기, 내보내기 실패, 완료된 자료를 각각의 프레임으로 만듭니다. 기간과 배송 건수를 일관되게 유지하세요. 참여자가 합리적으로 선택할 만한 경로와 잘못 들어간 영역에서 돌아오는 경로를 연결합니다. 프로토타입의 제한은 조사 메모에 적고, 참여자 화면에 정답을 알려 주는 안내로 넣지는 마세요.

디자인 논의에 참여하지 않은 사람과 한 차례 예비 테스트를 해 보세요. 조작하기 전에 과제를 소리 내어 읽고 무엇을 해야 한다고 이해했는지 설명하게 합니다. 이 과정에서 모호한 날짜, 빠진 데이터, 끊어진 연결을 발견할 수 있습니다. 표현이 문제라면 과제를 고치고, 과제를 수행할 수 없게 만든 것이 문제라면 프로토타입을 고칩니다. 실제 인터페이스의 어려움을 진행 문구의 힌트로 덮지 마세요.

관찰 결과를 다음 디자인 결정으로 연결하기

참여자가 보고서를 찾았지만 선택한 주의 자료인지 구분하지 못했다고 가정해 보겠습니다. 다음 설계 질문은 대시보드의 전반적인 미감이 아니라 기간 표시입니다. 미리보기와 내보내기 완료 안내에 날짜 범위를 넣고 같은 목표로 다시 검토하세요. 기간은 이해하지만 배송 분류를 잘못 고른다면 라벨과 분류 정의를 조사해야 합니다.

실무 기록에는 과제, 관찰한 행동, 막힌 지점, 가능한 설명, 제안하는 변경의 다섯 항목이 유용합니다. 서로 모순되는 관찰도 남겨 두세요. 다른 경로로 성공한 사람은 없애야 할 이탈이 아니라 유용한 대안을 보여 줄 수 있습니다. 여러 세션의 결과를 모아 디자인 우선순위를 정할 때는 UX 리서치 결과를 종합하는 방법을 참고하세요.

다음 세션의 과제도 같은 실제 목표에서 출발하되, 새 인터페이스를 미리 가르치지는 마세요. 그래야 화면이 달라져도 조사는 고객의 실제 업무와 연결됩니다. Pixso에서 사용성 테스트 과제 흐름 만들기