이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
처음으로 혼자 사용자 3명을 대상으로 사용성 테스트를 진행했을 때 생각보다 훨씬 어려웠습니다.
사전에 시나리오를 준비했지만, 사용자가 예상과 다른 방향으로 화면을 탐색하면 제가 당황해서 유도하는 질문을 해버렸습니다. '이 버튼 보이시죠?'처럼요. 그러니 사용자 반응이 진짜인지 제가 유도한 건지 구분이 안 되었습니다. 첫 테스트 데이터는 모두 버려야 했습니다.
이후 말하지 않고 관찰하는 것을 원칙으로 삼고, 궁금할 경우 '방금 어떤 생각으로 그걸 눌렀나요?'처럼 열린 질문으로만 물어보았습니다. 결과가 훨씬 자연스러워졌습니다. 진행자 개입이 데이터를 오염시킨다는 것을 그때 배웠습니다.
사용자 인터뷰를 준비할 때 미리 가설을 세우고 그걸 확인하려는 질문을 많이 만들었어요. '사용자들이 알림이 많다고 불편하게 느끼겠지'라고 가정했거든요.
막상 인터뷰하니 알림 이야기는 거의 안 나오고, 검색 기능이 불편하다는 말만 계속 나왔어요. 처음엔 인터뷰 방향을 어떻게 해야 할지 몰라서 당황했지만, 이 예상치 못한 반응이 오히려 더 중요한 발견이었습니다. 가설을 버리고 그 방향으로 파고들었더니 훨씬 유용한 인사이트를 얻었어요.
이 경험에서 인터뷰의 도전은 기대한 답이 안 나올 때 유연하게 따라가는 것이라는 걸 배웠어요. 가설은 출발점이지, 인터뷰를 이끄는 목적지가 되면 안 된다고 생각합니다.
팀 프로젝트에서 3명이 함께 사용자 테스트를 진행했는데 역할을 미리 정하지 않았어요. 진행자, 관찰자, 기록자를 나눠야 하는데 모두 번갈아 질문을 하다 보니 사용자가 어디를 봐야 할지 몰라 혼란스러워했어요.
테스트 후 반성 회의에서 진행자는 한 명만, 나머지는 조용히 관찰하고 기록하는 역할을 다음 테스트부터 고정하기로 했습니다. 이후 사용자 반응이 훨씬 자연스러워졌어요. 처음부터 이렇게 했으면 좋았을 거라고 팀원들 모두 느꼈습니다.
이 경험에서 사용자 테스트는 역할 분담이 테스트 품질을 결정한다는 걸 배웠어요. 준비물보다 사람 구조가 더 중요한 경우가 있다는 것도요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 UX 리서처 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.