사용성 테스트 태스크, 지시문이 아니라 시나리오로 쓰세요

"가입 버튼을 눌러 계정을 만드세요."라고 참여자에게 태스크 하나를 제시해요. 참여자는 큰 '가입' 버튼을 누르고, 양식을 채우고, 끝났어요. 그리곤 노트에는 '성공'이라고 적어요. 하지만 여기서 우리가 알아낸 건 하나도 없어요.

태스크는 지시문이 아니라 목표가 담긴 시나리오여야 해요

좋은 태스크는 참여자에게 단계가 아니라 목표를 줘요. 참여자가 알아볼 만한 상황과 그 사람이 이루고 싶은 결과를 주고, 거기까지 가는 길은 스스로 찾게 두는 거죠. 태스크가 무너지는 건 거의 늘 같은 식이에요. 문장 안에 화면에 있는 무언가, 버튼이든 메뉴든 기능 이름이든 적어 넣으면, 참여자는 그 단어를 화면에서 찾아 누르기만 하면 되거든요. 가입하는 길을 스스로 찾을 수 있는지 보려던 테스트가, 글자를 읽을 수 있는지 보는 테스트로 바뀌어 버려요. 태스크를 지시문이 아니라 시나리오로 쓰면, 그제야 세션에서 사람들이 우리 제품을 실제로 어떻게 경험하는지가 드러나요.

태스크를 쓰는 건 전체 사용성 테스트에서 두 번째 단계지만, 이 단계에 따라 나머지 이어지는 단계들이 헛수고가 되느냐 아니냐가 결정될 만큼 중요해요. 태스크를 잘못 쓰면 그 뒤의 모든 관찰이 오염되거든요.

지시문은 독해력을, 시나리오는 제품을 시험해요

이 차이는 겉치레가 아니에요. 지시문은 참여자에게 무엇을 할지 알려주고, 시나리오는 스스로 알아낼 이유를 줘요. NN/g의 표현을 빌리면, 태스크 시나리오는 요청에 맥락을 입혀서 "왜" 그 행동을 하는지 동기를 줘요. 그래야 참여자가 명령을 기계적으로 따르는 대신, 진짜 사용자처럼 인터페이스를 대하거든요.

유도 단어 함정

테스트를 가장 많이 망치는 실수가 바로 이거예요. 태스크 문장에 든 단어가 화면의 라벨과 똑같으면, 이미 답을 건넨 셈이에요. NN/g는 이렇게 짚어요. 태스크에 인터페이스의 단어가 들어가면 "참여자의 독해력과 같은 단어를 찾아내는 능력을 시험하는 것이지, 우리 라벨과 내비게이션을 시험하는 게 아니"라고요. 찾기 과제가 단어 맞추기로 쪼그라드는 거죠.

가령 사람들이 내보내기 기능을 찾을 수 있는지 보려고 해요. 태스크가 "이 리포트를 PDF로 내보내세요"인데 버튼에 '내보내기'라고 적혀 있으면, 태스크는 '내보내기라는 단어 맞추기'로 무너져요. 목표로 다시 쓰면 이렇게 돼요. "이 리포트를 계정 없는 동료에게 메일로 보내고 싶어요. 첨부할 수 있는 형태로 만들어 보세요."

예외가 하나 있어요. 어떤 단어는 그냥 사람들이 평소에 쓰는 말이에요. '검색' 같은 거요. 검색창을 찾을 수 있는지가 시험 대상이 아니라면 '검색'을 언급해도 괜찮을 수 있어요. 하지만 스스로 찾아내는지가 궁금하다면 말하지 마세요. 애매하면 빼는 쪽이 안전해요.

나쁜 태스크와 좋은 태스크, 여섯 가지

참고할 수 있는 사례를 준비했어요. 규칙은 매번 같아요. 버튼이 아니라 목표를 말하기.

커머스

• 나쁨: "'장바구니 담기'를 눌러 검은색 운동화를 구매하세요."
• 왜 실패하나: 버튼 이름을 알려줬고 상품까지 골라 줬어요. 관찰할 결정이 남지 않았고, '장바구니 담기'는 과제가 아니라 단어 맞추기예요.
• 좋음: "이번 봄에 러닝을 시작하려고 운동화를 하나 사려고 해요. 예산은 6만 원 안쪽이고요. 실제로 살 만한 걸 하나 골라 보세요."

B2B 세팅

• 나쁨: "설정에서 연동 메뉴로 들어가 Slack을 연결하세요."
• 왜 실패하나: 클릭 경로를 문장에 그대로 적어 줬어요. 연동 메뉴를 스스로 찾을 수 있는지는 영영 못 봐요.
• 좋음: "계약이 성사될 때마다 팀 Slack으로 알림이 왔으면 해요. 그렇게 되도록 맞춰 보세요."

모바일 앱

• 나쁨: "메뉴 아이콘을 눌러 다크 모드를 켜세요."
• 왜 실패하나: 조작할 컨트롤과 목적지를 다 알려줬어요. 메뉴를 못 찾는 사람에게 위치를 이미 일러 준 셈이에요.
• 좋음: "밤에 보기엔 화면이 너무 밝네요. 눈이 편하도록 바꿔 보세요."

가입 폼

• 나쁨: "가입 양식을 채우고 '완료'를 누르세요."
• 왜 실패하나: 목표도 동기도 없고, '완료'는 UI 라벨이에요. 가입이 아니라 타이핑을 시험하는 거죠.
• 좋음: "친구 추천으로 이 앱을 한번 써보기로 했어요. 실제로 쓰기 시작할 수 있는 데까지 가 보세요."

뱅킹

• 나쁨: "가까운 지점을 찾아 내일 영업시간을 확인하세요."
• 왜 실패하나: '지점'은 사이트가 쓰는 말 그대로일 가능성이 크고, '지점을 찾아'는 기능을 곧장 가리켜요. (NN/g가 이 함정의 예로 든 것과 비슷한 경우예요.)
• 좋음: "내일 은행에 들를 일이 있어요. 지금 계신 곳에서 가기 편한 곳이 몇 시에 여는지 알아봐 주세요."

예약

• 나쁨: "캘린더에서 오전 10시 슬롯을 예약하세요."
• 왜 실패하나: '캘린더'와 '슬롯'은 UI를 지칭하고, '오전 10시'라고 시간까지 콕 집으면 참여자가 내릴 결정이 하나도 안 남아요.
• 좋음: "다음 주에 가장 이른 오전 시간으로 예약을 잡아 보세요."

태스크 쓰는 법: 두 줄 공식

태스크마다 두 줄로 써 보세요.

• 상황 한 줄: 참여자에게 동기를 주는 맥락. "주말 여행을 계획 중이에요..."
• 목표 한 줄: 끝난 상태가 어떤 모습인지, 진짜 제약 하나와 함께. "...이틀 묵을 곳을 15만 원 안쪽으로 찾아 보세요."

세션에 넣기 전에, 모든 태스크에서 이 단어들을 걷어내요.

• 버튼·링크 이름 (완료, 장바구니 담기, 계속)
• 메뉴·탭·화면 이름 (설정, 연동, 대시보드)
• 우리가 붙인 기능 이름 (스마트 싱크, 빠른 공유)
• 마케팅 표현 ("강력한 새 기능")
• 단계 그 자체 ("먼저 ...로 가서, 그다음 ...를 누르고")

그래도 태스크가 설명서처럼 읽힌다면, 스스로 한 번 물어봐요. 실제 사용자가 실제 상황에서 이렇게 생각할까? 아니라면, 그 사람이 진짜 원할 법한 일로 바꿔 써요.

이 규칙을 매번 직접 챙기기 번거롭다면, AI의 도움을 받을 수도 있어요. Interbang에는 이 원칙을 그대로 담은 시나리오 작성·점검 프롬프트가 준비돼 있어요. 초안 작성을 요청하거나, 이미 작성한 태스크를 규칙에 맞게 수정할 수 있어요.

이제 남은 건 지켜보는 일이에요

태스크가 시나리오처럼 읽히기 시작하면 세션 자체가 단순해져요. 목표 하나를 건네고, 조용히 지켜보면 되거든요. 유스케이스와 그에 딸린 태스크를 미리 세팅해 두면, 세션 중에는 세팅에 손댈 필요 없이 관찰하고 노트 다는 데만 집중할 수 있고요.

그런데 조용히 지켜보는 건 생각보다 어려워요. 참여자가 얼어붙었을 때 어떤 말은 도움이 되고 어떤 말은 오히려 유도가 되는지, 세션을 이끄는 데 필요한 기술은 다음 글에서 다룰게요.

자주 묻는 질문

태스크에 인터페이스 단어를 절대 쓰면 안 되나요? 거의는 안 쓰는 게 맞아요. 예외는 '검색'처럼 사람들이 평소에도 쓰는 말이면서 시험 대상이 아닐 때예요. 검색창을 찾을 수 있는지가 궁금하다면 '검색'을 말하지 마세요. 검색이 그저 목표에 닿는 수단일 뿐이라면 대개 괜찮아요. 애매하면 빼세요.

시나리오가 막연하면 참여자가 헷갈리지 않을까요? 시나리오는 막연한 게 아니에요. 목표에는 구체적이고, 경로에는 침묵하는 거예요. "이틀 묵을 곳을 15만 원 안쪽으로 찾으세요"는 아주 구체적이죠. 걷어내는 건 '어떻게'지 '무엇'이 아니에요. 진짜 결정을 내릴 만큼의 맥락은 꼭 줘요.

태스크는 얼마나 길어야 하나요? 한두 문장이면 돼요. 동기와 분명한 결승선을 세울 정도면 충분하죠. NN/g는 배경 설명이 과하면 원래 단순했을 과제가 오히려 복잡해진다고 경고해요. 결정에 도움이 안 되는 설정은 덜어내세요.

세션 하나에 태스크는 몇 개가 적당해요? 피로가 쌓이지 않는 선에서 목표를 덮을 만큼이요. 30~60분 모더레이티드 세션이라면 잘 쓴 태스크 몇 개가 긴 체크리스트보다 나아요. 실제 사람이 마주칠 순서대로 배열하세요.