유도하지 않는 인터뷰

기능 요청에서 최근 사건으로 돌아갑니다

신청자가 “승인 알림을 만들어 주세요”라고 말할 때 신입 기획자는 알림의 종류부터 묻기 쉽습니다. 그러나 사용자는 이미 알고 있는 해결 방법으로 불편을 표현할 수 있습니다. 승인 자체가 늦었는지, 결과가 있어도 경로를 몰랐는지, 신청 완료를 승인 완료로 이해했는지는 다른 문제입니다. 인터뷰는 기능 투표가 아니라 그 사람이 실제로 하려던 일과 막힌 조건을 알아보는 작업입니다. 이번 레슨에서는 질문을 쓰고 답에 맞춰 후속 질문을 선택하는 연습을 합니다.

앞 모듈에서 정한 신청 시작부터 결과 확인까지의 범위를 사용합니다. 네 레슨의 문서 제출물을 마지막에 research.json으로 합칩니다. 미션 시작본의 project-brief.json은 앞 모듈 모범 답안을 그대로 포함하며 E001은 가상 사례, E002는 조사 가설입니다. 새 자료에는 P번호를 참여자, S번호를 출처, E003 이후 번호를 근거로 붙입니다. 제공 사례를 쓰면 mode를 provided로 표시합니다. 실제 동의한 사람을 조사한 경우에만 actual로 표시하고, 제공 사례와 실제 결과를 섞어 조사 완료라고 쓰지 않습니다.

회상할 수 있는 질문을 만듭니다

질문에는 한 사건과 한 행동을 담습니다. “최근 행사에 신청한 때를 떠올려 주세요. 공지는 어디에서 보셨나요?”로 시작하고 신청, 제출 후 확인, 결과를 알게 된 순간을 차례로 묻습니다. ‘평소에는 어떻게 하세요’만 물으면 습관에 대한 설명이 나오기 쉽습니다. 최근 사례의 순서를 들은 뒤 다른 때와 같았는지 물으면 실제 경험과 일반 의견을 비교할 수 있습니다. 정확히 기억하지 못하는 부분은 모른다고 답할 수 있게 둡니다.

좋은 질문은 답변의 방향을 미리 정하지 않습니다. “결과를 찾기 어려웠죠?”에는 어렵다는 평가가 들어 있습니다. “제출 뒤에 무엇을 하셨나요?”는 확인하지 않았다는 답도 허용합니다. “알림이 없어서 문의했나요?”는 원인을 지정합니다. “운영자에게 문의하기 바로 전에 어떤 화면을 보셨나요?”는 그때의 행동을 듣습니다. 질문을 다듬을 때 특정 기능, 감정, 원인 중 하나를 미리 넣었는지 표시하고 제거합니다.

역할별로 같은 목표와 다른 과정을 듣습니다

신청자 두 명에게는 공지 발견, 신청 제출, 결과 확인을 공통으로 묻습니다. 첫 신청 경험과 재신청 경험이 다른지 확인하되 답을 보기 전에 유형을 임의로 정하지 않습니다. 운영자 한 명에게는 최근 신청 한 건을 검토하고 결과를 기록한 순서를 묻습니다. ‘신청자들은 왜 못 찾나요’는 운영자가 다른 사람의 마음을 추측하게 합니다. 대신 실제로 어떤 안내를 남겼고 어떤 문의를 받았는지 듣습니다. 같은 질문표를 그대로 읽는 것보다 역할에 맞는 행동을 물어야 합니다.

진행 시간은 이 연습에서 15분으로 잡되, 질문 수를 모두 채우는 것이 목적은 아닙니다. 시작에 참여 선택권과 메모 조건을 안내하고, 최근 사례를 듣고, 구체적인 장면을 확인한 뒤 요약을 돌려줍니다. 앞 모듈의 동의안을 사용하며 중단이나 질문 건너뛰기를 허용합니다. 운영자가 옆에 있을 때 신청자가 불편을 말하기 어려울 수 있으므로 역할별로 따로 듣습니다. 거절한 참여자의 경험을 상상해서 실제 기록으로 채우지 않습니다.

답에 따라 후속 질문을 선택합니다

“양식을 제출하고 기다렸어요”라는 답에는 “기다린 뒤 처음 결과를 확인하려고 했을 때 무엇을 열었나요?”라고 묻습니다. “운영자에게 물었어요”에는 “물어보기 전까지 어떤 정보를 확인하셨나요?”를 이어 갑니다. 결과를 쉽게 찾았다는 답이라면 “어디에서 그 경로를 알게 되었나요?”로 성공 조건을 듣습니다. 질문표에는 기본 질문뿐 아니라 실패와 성공 답변에서 각각 물을 후속 질문을 적어 두면 원하는 답만 깊게 듣는 실수를 줄일 수 있습니다.

사용자가 “귀찮았어요”라고 말하면 평가를 그대로 인용하고 “어떤 일을 다시 하셔야 했나요?”로 행동과 비용을 확인합니다. ‘많이’라는 표현에서 임의로 횟수를 만들지 않습니다. 시간이나 횟수가 필요하면 그 사례에서 기억하는 범위를 묻고, 정확한 시각 자료가 없으면 미확인으로 남깁니다. 기획자가 시간을 추정한 값과 사용자가 회상한 값도 별도로 표시합니다. 다음 사람이 질문을 읽었을 때 그 숫자가 어디서 왔는지 알 수 있어야 합니다.

답을 대신 완성하지 않습니다

인터뷰에서 침묵이 생기면 바로 해결 후보를 제시하지 않습니다. 잠시 기다리거나 “기억나는 부분까지만 말씀해 주셔도 됩니다”라고 안내합니다. 화면을 보며 설명할 수 있는지 요청할 때는 실제 계정이나 개인정보 대신 허가된 모의 화면을 사용합니다. 참가자가 말하지 않은 내용은 원인으로 채우지 않습니다. “그러면 알림이 없어서 불안하셨겠네요”로 정리하면 조사자의 해석이 사용자의 말로 바뀌므로 “제가 이해한 순서는 제출, 공지 확인, 문의인데 맞나요?”처럼 순서만 확인합니다.

질문 순서도 답변에 영향을 줄 수 있습니다. 첫 질문부터 알림 필요성을 논의하면 뒤의 행동 설명이 그 기능을 중심으로 재구성될 수 있습니다. 먼저 과거 사건과 현재 과정을 듣고, 원하는 개선이나 제안은 마지막에 받습니다. 기능 제안을 거절할 필요는 없습니다. 제안을 의견으로 남긴 뒤 그것이 어떤 장면을 해결하려는지 되묻습니다. 참여자가 기대하는 출시 일정은 조사 중에 약속하지 않고 담당자 검토가 필요하다고 답합니다.

질문표를 작은 리허설로 고칩니다

동료에게 신청자 역할을 맡겨 질문표를 읽습니다. 동료는 일부러 결과를 쉽게 찾았다고 답하고, 한 장면은 기억나지 않는다고 답합니다. 그때도 질문이 이어지고 없는 정보를 요구하지 않는지 확인합니다. 리허설은 실제 사용자 조사로 집계하지 않습니다. 질문 문장마다 무엇을 알고 싶은지 한 줄로 적으면 질문이 많아도 같은 기능 선호만 반복하는 것을 발견할 수 있습니다. 지우기 어려운 질문은 이번 조사 범위와 연결되는지 먼저 검토합니다.

완성한 질문표에는 신청자용 기본 질문 다섯 개, 운영자용 질문 네 개, 상황별 후속 질문 세 개와 마무리 요약을 둡니다. 결과 경로를 아는 사람에게도 답할 수 있어야 하고, 검토 지연과 경로 탐색 실패를 구분할 수 있어야 합니다. 제출 전에 ‘좋겠죠’, ‘불편하죠’, ‘당연히’가 들어간 문장을 찾아 고칩니다. 더 읽기의 명세 사고 장은 요청을 조건으로 바꾸는 보충 자료이며 이 질문표를 대신 작성해 주는 인터뷰 지침은 아닙니다.