테스트는 끝났는데, 이 노트 더미로 뭘 하죠?
사용성 테스트 결과 정리 3단계. 노트를 한곳에 모으고, 패턴으로 묶고, 심각도와 빈도로 고칠 순서를 정하는 법을 실제 예시와 함께 담았어요.
2026년 7월 17일 발행
마지막 참가자와의 UT가 끝나고 보니, 오늘 다섯 번의 세션에서는 노트 104개, 스크린샷 몇 장, 총 3시간 48분 분량의 녹음 파일이 남았어요. 내일이면 팀장님이 "그래서 뭘 알아냈어요?"라고 물을 거예요. 세션을 전부 직접 지켜봤는데도 지금 떠오르는 건 참가자가 막히던 장면 몇 개뿐이라, 분명 많이 알아냈을 텐데도 뭐라 답하기가 어려워요. 정리 전엔 다 그래요.
사용성 테스트 결과 정리, 3단계면 돼요
정리는 결국 세 가지예요. 모든 관찰을 한곳에 모으고, 쌓인 노트를 패턴으로 묶고, 패턴을 심각도와 빈도로 줄 세우는 거죠. 방법 자체는 도구를 가리지 않아요. 스티키 노트를 붙인 벽에서도, 스프레드시트에서도, 리서치 도구에서도 똑같이 돌아가요. 그리고 목표는 10페이지짜리 보고서가 아니에요. 근거를 단 문제 세 개쯤, 팀이 실제로 고칠 짧은 목록이죠.
세션 5개 규모라면 반나절 정도가 필요해요. 단계별로 볼게요.
1단계: 한곳에 모으기, 노트 하나에 관찰 하나
먼저 전부 한곳에 모아요. 세션 노트, 인용문, 녹취록에서 표시해 둔 순간까지요. NN/g는 이 단계를 리서치 질문에 답이 되는 관찰과 인용을 추려내는 과정으로 설명하면서, 주의할 점을 하나 짚어요. 데이터라고 다 똑같이 중요한 건 아니라서, 참가자가 하는 걸 직접 보고 남긴 노트가 참가자가 스스로 말한 의견보다 더 중요해요. "참가자 3이 엉뚱한 탭을 두 번 눌렀다"는 증거지만, "참가자 3은 디자인이 깔끔하다고 생각한다"는 감상이거든요.
노트 하나에는 관찰 하나만 담고, 누가·언제를 꼭 붙여 두세요. "참가자 2, 12분: 팀원 이메일을 검색창에 입력"은 나중에 누가 따져 물어도 근거를 댈 수 있지만, "사람들이 초대를 헷갈려했다"는 그럴 수 없어요. 세션 중에 노트마다 시간이 찍혀 있었다면 이 단계는 사실상 더 이상 할 게 없어요.
2단계: 쌓인 노트를 패턴으로 묶기
이제 고전적인 방법, 친화도 매핑이에요. 노트를 펼쳐 놓고, 같은 행동을 가리키는 것끼리 모아요. NN/g가 소개하는 진행 순서도 정확히 이래요. 노트를 만들고, 테마로 묶고, 그다음 묶음의 우선순위를 정하는 거죠. 화이트보드 앞에 팀이 모여도 되고, 스프레드시트에서 혼자 해도 문제없어요.
묶음이 쓸모 있으려면 규칙 두 개면 충분해요.
- 사람들이 한 행동으로 묶기. "설정 페이지 노트들"은 그냥 폴더예요. "사람들이 초대를 세 군데서 찾아 헤맨다"는 세 화면에서 나온 노트여도 하나의 발견이죠.
- 묶음 이름은 숫자가 붙은 발견으로. "초대 관련 이슈" 말고 "5명 중 4명이 팀원 초대 방법을 못 찾았다"처럼요. 묶음 이름만 떼어 Slack에 올려도, 앞뒤 설명 없이 무슨 문제인지 전달될 정도여야 해요. 숫자가 작다고 덜 중요한 건 아니에요. 몇 명이 겪었는지는 다음 단계에서 우선순위를 정할 때 심각도와 함께 참고할 정보예요.
노트에 처음부터 종류 태그가 달려 있다면 이 단계가 한결 수월해요. 관찰·문제·인사이트·버그를 미리 갈라 두면, 의견이나 버그를 먼저 걷어내고 행동 관찰만 놓고 묶을 수 있거든요.
노트 100개는 보통 패턴 열몇 개로 줄어들어요. 큰 묶음도 있고, '로고가 아쉽다' 같은 노트 두 장짜리 자잘한 묶음도 있을 거예요. 괜찮아요. 이 단계를 지나면 흩어져 있던 순간들이 근거를 댈 수 있는 발견으로 바뀌어요.
3단계: 심각도 먼저, 빈도는 그다음
찾아낸 패턴 열두 개가 전부 스프린트 티켓이 될 수는 없어요. 우선순위를 정해야죠. 표준은 야콥 닐슨(Jakob Nielsen)의 심각도 등급이에요. 겪었을 때 빠져나오기가 얼마나 어려운지, 알고 나서도 반복되는지, 얼마나 자주 일어나는지까지 세 요인을 종합해 0~4점을 매겨요.
| 등급 | 의미 | 처리 |
|---|---|---|
| 0 | 사용성 문제가 아님 | 제외해요 |
| 1 | 수행에는 지장 없는 미관상 문제 | 여유 있을 때만 |
| 2 | 수행을 조금 늦추는 가벼운 문제 | 낮은 우선순위 |
| 3 | 수행을 크게 방해하는 중대한 문제 | 높은 우선순위 |
| 4 | 재앙: 과제 수행 자체가 막힘 | 무엇보다 먼저 고쳐요 |
닐슨의 등급엔 이렇게 빈도가 이미 녹아 있지만, 참가자 5명 규모에선 '얼마나 치명적인가'와 '몇 명이 겪었나'를 두 축으로 나눠 보는 편이 다루기 쉬워요. 교차하면 고칠 순서가 나와요.
| 빠져나오기 어려움 | 빠져나오기 쉬움 | |
|---|---|---|
| 대부분 겪음 | 지금 고쳐요 | 가볍게 다듬기 |
| 한두 명 겪음 | 다음에 고치고, 다음 라운드에서 지켜봐요 | 백로그 |
숫자를 읽을 땐 조심할 게 하나 있어요. 참가자 5명일 때 빈도는 측정값이 아니라 나침반이에요. "5명 중 4명"은 문제가 실재하고 흔하다는 뜻이지, 사용자의 80%가 겪는다는 뜻이 아니거든요. (작은 표본의 숫자가 그래도 방향은 맞게 가리키는 이유는 참가자 수를 다룬 글에서 다뤘어요.) 어느 쪽을 먼저 고칠지 애매할 땐 심각도를 따르세요. 한 명만 겪은 '재앙' 등급 문제가, 모두가 알아챈 미관상 결함보다 먼저예요.
실제 예시로 한번 볼게요
프로젝트 협업 도구의 온보딩을 세션 5개로 테스트했고, 노트 104개가 쌓였다고 해볼게요. 정리하다 보면 화면은 제각각인데 같은 행동을 가리키는 노트들이 눈에 들어와요.
| 노트 | 나온 화면 |
|---|---|
| 참가자 1 (3분): "초대 버튼이 있을 줄 알았는데" 하며 메인 화면을 두 바퀴 훑음 | 메인 |
| 참가자 2 (12분): 팀원 이메일을 검색창에 입력하며 "여기다 하는 건가?" | 메인 검색창 |
| 참가자 4 (7분): 초대를 찾으러 설정을 열었다가 두 번 되돌아 나옴 | 설정 |
| 참가자 5 (9분): 포기하고 "그냥 Slack으로 링크 보낼게요" | 멤버 목록 |
넷 다 팀원 초대 방법을 못 찾은 거죠. 화면 단위로 나눴다면 세 폴더에 흩어졌을 노트들이, 행동으로 묶으니 "메인 화면에서 팀원 초대가 보이지 않는다"(5명 중 4명)라는 발견 하나가 돼요. 네 명 모두 몇 분씩 헤매거나 포기했으니 심각도는 3이에요.
같은 방식으로 끝까지 묶으면 패턴 11개가 남아요. 이제 패턴마다 심각도와 겪은 인원을 매겨 고칠 순서를 정할 차례예요.
| 묶음 이름 | 심각도·인원 | 우선순위 |
|---|---|---|
| 온보딩 중 뒤로 가기를 누르면 입력한 내용이 사라진다 | 4 · 1명 | 1순위 |
| 메인 화면에서 팀원 초대가 보이지 않는다 | 3 · 4명 | 2순위 |
| 설정을 마쳐도 다음에 뭘 해야 할지 몰라 멈춘다 | 3 · 3명 | 3순위 |
| 나머지 8개 (문구·정렬 같은 가벼운 문제) | 1-2 · 1-3명 | 백로그 |
총 세 가지 문제로 정리가 됐어요. 모두 근거가 명확해서 이해관계자를 말로 설득할 필요가 없어요.
손이 많이 가는 부분은 덜 수 있어요
여기까지가 정리 방법이에요. 전용 도구 없이도 충분히 할 수 있어요. 그런데 돌아보면 정리의 절반은 세션 중에, 노트를 적는 순간에 이미 결정돼요. 관찰 하나에 노트 하나로 쪼개기, 누가·언제 붙이기, 종류 태그 달기가 그래요. Interbang에서는 노트를 적으면 시간이 자동으로 찍혀 녹취록 시간과 바로 연결되고, 종류 태그도 적으면서 함께 붙일 수 있어요. 이런 준비를 따로 신경 쓰지 않아도, 세션이 끝나는 순간 1단계는 이미 끝나 있는 셈이죠.
묶는 단계에서 AI에게 패턴 초안을 부탁할 수도 있는데, 여기서도 재료가 절반이에요. 정리 안 된 노트와 녹취록을 통째로 던지면 시간과 토큰만 쓰고 뭉뚱그린 답을 받기 쉽거든요. 시간과 태그, 근거가 붙은 노트를 Markdown 하나로 묶어 넘기면 훨씬 또렷한 패턴 초안을 받을 수 있어요. 그다음 살릴 것과 버릴 것만 직접 고르면 되죠.
10페이지 말고, 세 가지만 공유하세요
보고서가 길어지는 순간, 애써 찾은 인사이트도 그대로 묻혀요. 그러니 읽힐 만큼만 작게 만드세요.
- 상위 문제들. 각각 묶음 이름 그대로 쓰고, 심각도·인원수·증거가 될 인용문 한두 개를 붙여요.
- 잘 작동한 것 한두 가지. 방법에 대한 신뢰가 생기고, 멀쩡한 걸 "고치는" 사태도 막을 수 있어요.
- 다음 계획. 어떤 수정을 반영하고 언제 다시 테스트할지를 계획해요. 사용성 테스트는 한 번으로 끝나지 않고, 테스트하고, 고치고, 다시 테스트하는 흐름까지 이어져야 비로소 의미가 있거든요.
그런데 다음 계획을 적다 보면 궁금해져요. 고치고 나서 두 번째 테스트를 돌리면, 정말 나아졌는지는 어떻게 확인할까요? 이 이야기는 다음 글에서 따로 다뤄 볼게요.
자주 묻는 질문
세션 끝나고 얼마 안에 정리해야 하나요? 하루 이틀 안에, 세션에 대한 기억이 아직 생생할 때가 좋아요. 며칠만 지나도 노트만 봐서는 무슨 뜻이었는지 가물가물해져서, "참가자 4가 여기서 막힘" 같은 메모는 '여기'가 어디였는지 기억날 때만 쓸모가 있거든요. 세션을 잡을 때 정리할 시간도 같이 잡아 두면 좋아요.
한 명만 겪은 문제는 어떻게 하나요? 빈도보다 심각도를 먼저 보세요. 과제가 막히거나 데이터가 날아가는 문제라면 한 명에게서만 관찰됐더라도 개선할 이유가 충분해요. 가벼운 문제라면 백로그에 두고 다음 라운드에서 다시 나타나는지 지켜봐요. 5명 표본에서 빈도는 나침반일 뿐이니, 결정은 문제의 심각도와 영향도를 보고 내리세요.
결과물은 실제로 어떤 모양이어야 하나요? 한 페이지면 돼요. 우선순위를 매긴 주요 문제 서너 개와 각각의 근거, 잘 작동한 부분 한두 가지, 그리고 다음 단계(어떤 수정을 반영하고, 다음 테스트는 언제 할지)까지요. 이해관계자용으로 긴 부록이 필요하면 전체 묶음 목록을 링크로 달되, 한 페이지는 부록 없이도 그 자체로 읽히게 쓰세요.