참가자가 막혔을 때, 사용성 테스트 진행자는 뭐라고 말해야 할까요?
사용성 테스트 진행 방법. 참가자를 유도하지 않고 세션을 이끄는 법을 오프닝 멘트 템플릿과 상황별 문장, 침묵을 견디는 기준으로 정리했어요.
2026년 8월 2일 발행
결제 태스크를 시작한 지 15초, 참가자가 멈춰요. 화면을 위로 올렸다가, 내렸다가, 다시 올려요. 버튼은 진행자 자리에서도 보여요. 침묵이 길어지니 괜히 미안해져서 한마디 하게 되죠. "오른쪽 위쪽 한번 보시겠어요?" 참가자는 바로 찾아내요.
이건 관찰한 게 아니라 유도한 거예요.
사용성 테스트 진행의 대부분은 말하지 않는 일이에요
세션에서 진행자가 할 일은 참가자의 생각을 지키는 거예요. 그걸 가장 많이 망가뜨리는 습관이 두 가지 있는데, 너무 일찍 도와주는 것과 아직 태스크를 하는 중인 사람에게 이유를 묻는 거예요. 둘 다 친절해서 나오는 말이지만, 그 순간 우리가 보려던 게 사라져 버려요.
다행히 이건 타고나는 재능의 문제가 아니에요. 방금 말한 두 가지만 피하고 몇 가지 요령만 익히면 누구나 진행자가 될 수 있어요. 사용성 테스트의 다섯 단계 중 진행 단계에 필요한 건 오프닝 멘트 하나와 어느 세션에서나 돌려 쓸 중립적인 문장 예닐곱 개가 거의 전부거든요. 그것만 준비해 두고 침묵을 채우고 싶은 충동을 참으면, 깔끔한 세션에 필요한 건 거의 다 갖춘 거예요.
오프닝 멘트는 한 번만 써두면 돼요
오프닝 2분이 세션 전체의 분위기를 좌우해요. 순서는 편한 대로 하되 이 네 가지는 꼭 넣으세요.
오늘 시간 내주셔서 감사해요. 웹사이트에서 제가 요청드리는 몇 가지를 직접 해보시게 될 텐데, 저는 대체로 조용히 지켜보면서 메모만 할 거예요.
하나 말씀드리면, 오늘 보려는 건 [참가자 이름]님이 아니라 저희 제품이에요. 그래서 틀린 답도 없어요. 헷갈리거나 불편한 게 있으면 그게 바로 저희가 들어야 하는 얘기니까 편하게 말씀해 주세요.
하시는 동안에는 머릿속에 드는 생각을 소리 내어 말해 주시면 좋아요. 당연해 보이는 거라도요.
혹시 저한테 뭘 물어보셔도 바로 대답을 안 드릴 수 있어요. 불친절해서가 아니라, [참가자 이름]님 혼자 쓰실 때 어떻게 하실지를 보고 싶어서예요. 궁금한 건 끝나고 다 알려드릴게요.
바로 대답을 안 드릴 수 있다는 말을 빼먹기 쉬운데, 안 넣으면 세션 중에 꼭 어색해져요. 조용히 있겠다고 미리 알려두면, 진행자가 말이 없어도 참가자가 그러려니 하고 넘어가요. 닐슨 노먼 그룹(NN/g)의 모더레이팅 체크리스트도 같은 두 가지를 짚어요. 사람을 시험하는 자리가 아니라 리서치라고 알려줄 것, 그리고 질문에 바로 답하지 않을 수 있다고 미리 말해둘 것.
같은 체크리스트에서 하나 더 참고할 팁이 있어요. 참가자 앞에서 '테스트'라는 말을 안 쓰는 거예요. '리서치'나 '조사'가 나아요. 채점당하는 중이라고 느끼면서 편하게 생각하는 사람은 없거든요.
"생각을 말해 주세요"는 괜찮고, "왜 그러셨는지 설명해 주세요"는 위험해요
진행자 눈에 보이는 건 참가자가 무엇을 했는지, 거기까지예요. 어디를 찾고 있었는지, 무엇을 다른 걸로 착각했는지는 안 보이죠. 그래서 세션을 시작할 때 생각을 소리 내어 말해 달라고 부탁해요. UX 업계에서 워낙 흔한 요청이라 관행처럼 보이지만, 에릭슨과 사이먼(Ericsson & Simon)의 언어 보고 연구에서 나온 방법이에요.
머릿속에 있는 걸 그대로 말하게 하는 건 참가자의 행동을 바꾸지 않아요. 하지만 왜 그랬는지 설명하게 하면 바뀌어요. 세션 중에 무슨 말을 해도 되고 무슨 말은 안 되는지가 여기서 갈려요.
생각을 그대로 말하게 하는 쪽부터 볼게요. 연구 94편, 참가자 3,500명을 모은 메타분석(Fox·Ericsson·Best, 2011)에서 소리 내어 생각한 사람과 조용히 태스크만 한 사람의 결과는 사실상 똑같았어요. 딱 하나, 말하면서 하면 시간이 조금 더 걸려요. 그래서 소요 시간만큼은 말없이 했을 때와 나란히 놓고 보면 안 돼요.
문제는 설명을 시킬 때예요. 같은 연구에서 "지금 뭘 하는지 설명해 보세요"라고 요구하자, 참가자들은 조용히 한 사람들보다 오히려 더 잘 해냈어요. 설명을 하려면 자기가 뭘 하고 있는지 한 번 더 들여다봐야 하고, 그러면서 평소보다 신중해지거든요.
"왜 그렇게 하셨어요?"가 태스크 중간에 위험한 이유가 여기 있어요. 무례해서도 아니고 나쁜 질문이라서도 아니에요. 다만 그 한마디에 제품을 쓰던 사람이 제품을 해명하는 사람이 돼요.
그때부터 우리가 보는 건 평소보다 신중해진 사람이지, 알고 싶던 그 사용자가 아니에요. 한번 설명을 시작하면 남은 세션 내내 그래요.
이유는 나중에 물으세요. 태스크가 끝난 뒤나 세션 막바지라면 "아까 거기 누르실 때 뭘 기대하셨어요?"는 아주 좋은 질문이고, 잃을 것도 없어요.
참가자가 태스크를 하다가 말이 없어져도, 뭘 하는 건지 다시 설명해 주지 마세요. 대신 "지금 무슨 생각 하고 계세요?" 한마디면 충분해요. 화면이나 목표, 참가자가 찾고 있을 법한 걸 조금이라도 언급하면 그 순간 힌트가 돼요.
진행자가 실수하기 쉬운 네 장면
세션에서 나오는 실수는 거의 다 이 넷 중 하나예요.
| 장면 | 참아야 하는 반사 반응 | 대신 이렇게 |
|---|---|---|
| 막혀 있는 걸 보기 힘들 때 | "위쪽 메뉴 한번 보시겠어요?" | "지금 무슨 생각 하고 계세요?" |
| 대놓고 도움을 청할 때 | "아, 오른쪽 아이콘 누르시면 돼요." | "제가 없었다면 어떻게 하셨을 것 같아요?" |
| 한참 말이 없을 때 | "설정 찾으시는 거죠?" | "지금 뭘 보고 계신지 말씀해 주실래요?" |
| 진행자에게 의견을 물어올 때 | "아, 거기 저희도 불편하다고 봐서 바꾸는 중이에요." | "그건 끝나고 말씀드릴게요. 지금은 어떻게 느끼셨는지 말씀해 주세요." |
참가자가 대놓고 도움을 청할 때 질문을 되돌려주는 방법을 NN/g는 부메랑(boomerang)이라고 불러요. 부담 없는 일반적인 질문으로 바꿔서 되돌려주면 돼요. "그거 누르면 어떻게 될 것 같으세요?" "평소라면 여기서 어떻게 하시겠어요?"
이렇게 물으면 참가자가 뭘 기대했는지가 드러나는데, 사실 그게 우리가 찾던 발견이에요.
NN/g에는 비슷한 기법이 둘 더 있어요. 에코(echo)는 참가자가 방금 한 말에 살짝 물음표만 얹어 그대로 돌려주는 거예요. "이 표 좀 이상하네요"라고 하면 "이상하세요?" 하고 되받는 거죠. 그러면 진행자의 말이 아니라 참가자의 말로 이야기가 이어져요. 콜롬보(Columbo)는 형사 드라마에서 이름을 딴 기법인데, "아, 그러니까 혹시 이걸 누르면…" 하고 문장을 반쯤만 던져 참가자가 채우게 두는 거죠.
참가자가 진행자한테 의견을 물어오는 상황은 보기보다 중요해요. "이거 원래 이런 건가요?" "좀 불편한데 저만 그런가요?" 같은 질문이죠. 대답해 주고 싶어지죠. 그런데 진행자 생각을 말하거나 저 화면은 이미 바꾸는 중이라고 흘리는 순간, 그 뒤에 나오는 말은 전부 거기에 영향을 받아요. 의견은 세션이 끝날 때까지 아껴두세요. 끝나고 나면 얼마든지 얘기해도 되고, 그때쯤이면 참가자도 궁금해할 만하니까요.
말하기 전에 속으로 열까지 세보세요
'조용히 있기'를 실천할 방법이 하나 있는데, NN/g에서 그대로 가져왔어요. 끼어들기 전에 속으로 열까지 세면서, 지금 말하는 게 정말 리서치에 도움이 되는지 따져보는 거예요.
처음엔 열까지 세기도 전에 입이 먼저 나갈 거예요. 누가 헤매는 걸 보는 10초는 1분처럼 느껴지거든요. 그런데 발견은 바로 그 구간에 있어요. 화면을 세 번 훑고 나서 스스로 버튼을 찾아낸 참가자는 우리에게 뭔가를 알려줘요. 진행자가 위치를 짚어준 참가자한테선 끝내 못 듣는 이야기죠.
물론 정말 도와야 할 때도 있고, 그건 괜찮아요. 2분째 완전히 막힌 사람한테서 더 얻을 건 없고, 남은 태스크도 기다리고 있으니까요. 그럴 땐 최대한 늦게, 최대한 조금만 도와주세요.
그리고 도왔다는 사실을 반드시 적어두세요. '도움 받아 완료'와 '완료'는 같은 결과가 아니거든요. 둘을 똑같이 적어두면 나중에 디자인을 실제보다 후하게 본 기록이 남아요.
Interbang에서는 태스크마다 성공 수준을 독립 수행, 경미한 어려움, 힘겹게 해결, 도움 받음, 실패 다섯 단계로 남길 수 있어요. 도움 받아 끝낸 태스크와 혼자 해낸 태스크를 구분하고, 어떻게 도왔는지 노트에 적어두면 리뷰할 때 맥락이 그대로 살아 있어요.
가능하면 2인 1조가 좋아요
한 사람이 진행과 기록을 같이 하면 놓치는 게 생겨요. 손으로 메모하거나 타이핑하는 동안엔 관찰하기가 어려우니까요.
참가자와 이야기하고 태스크를 관리하는 진행자, 아무 말도 하지 않고 기록만 하는 기록자로 나눠 보세요. NN/g도 두 역할을 나누라고 권하고, 루빈과 치스넬(Rubin & Chisnell)의 'Handbook of Usability Testing'에서도 둘을 별개의 역할로 구분해요.
혼자라면 세션 중엔 노트를 조금은 거칠게 작성하고, 끝나고 나서 기억이 남아 있을 때 정리하는 방법도 있어요.
연습보다는 준비가 중요해요
지금까지 얘기한 것 중에 연습으로 느는 건 별로 없어요. 대부분 준비의 문제죠. 오프닝 멘트를 한 번 써두고, 중립적인 문장 예닐곱 개를 눈에 보이는 곳에 두고, 침묵해도 된다고 세션 전에 미리 정해두면 돼요. 진행에서 지킬 건 사실 그게 다예요.
태스크도 그만큼 중요해요. 유도하는 태스크는 진행을 아무리 잘해도 관찰할 내용이 사라지거든요. 아직 안 썼다면 태스크를 시나리오로 쓰는 법을 참고해 보세요. 그리고 세션이 끝나면 쌓인 노트를 정리하는 일이 남는데, 고칠 문제 몇 개로 줄이는 법은 따로 정리해 뒀어요.
자주 묻는 질문
참가자를 도와주면 안 되나요? 도와도 돼요. 완전히 막혀서 더 배울 게 없는 상태라면, 남은 세션을 살리기 위해서라도 도와주는 게 맞아요. 다만 최대한 늦게, 막힌 걸 풀어줄 만큼만 알려주고, 그 태스크는 독립 수행이 아니라 도움 받아 완료한 것으로 기록하세요.
참가자가 거의 말을 안 하면요? 소리 내어 생각하는 게 어색한 사람도 있어요. 더 밀어붙이면 참가자가 오히려 위축돼요. "지금 무슨 생각 하세요?" 정도로 가볍게 한 번 물어보고, 그래도 조용하면 그냥 두세요. 행동도 데이터거든요. 어디서 망설이고, 어디로 되돌아가고, 어떤 문장을 다시 읽는지만 봐도 말 없이 꽤 많은 걸 알 수 있어요.
"왜 그렇게 하셨어요?"는 언제 물어도 되나요? 태스크 중간 말고, 끝난 뒤에요. 하는 중에 물으면 참가자가 수행에서 해명으로 넘어가고, 그 전환이 이어지는 행동까지 바꿀 수 있어요. 궁금한 순간은 노트로만 남겨뒀다가 태스크가 끝나면 돌아가서 물어보세요. "아까 그 화면에서 좀 머무르셨는데, 그때 어떠셨어요?"처럼요.
내가 만든 제품을 내가 진행해도 되나요? 할 수 있고, 작은 팀이라면 그럴 수밖에 없어요. 대신 위험이 둘 있어요. 진행자는 디자인을 변호하고 싶어지고, 참가자는 만든 사람 앞이라는 걸 알면 말을 부드럽게 다듬어요. 소개할 때는 리서치를 맡은 사람 정도로만 밝히고, 만든 사람이라는 얘기는 끝날 때까지 미루세요. 내가 제일 깊이 관여한 화면만이라도 동료가 진행해 줄 수 있다면 그게 제일 좋아요.