이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 앱 내 특정 기능 이탈률이 높다는 데이터를 보고 리서치를 설계하였습니다. 처음에는 UI가 문제라는 가설을 세웠으나, 인터뷰를 진행해보니 기능 자체를 왜 써야 하는지 모르는 것이 원인이라는 사실을 알게 되었습니다. 가설이 틀렸던 것입니다. 이후 기능 설명을 강화하는 방향으로 문제를 재정의하였습니다. UI를 바꾸는 것보다 진입점에 안내 텍스트를 추가하는 쪽이 효과적이라는 결론이 나왔습니다. 이 과정에서 가설은 검증을 위해 세우는 것이지, 결론으로 출발하는 것이 아니다라는 것을 배웠습니다. 이 경험 이후로 리서치 전에 가설을 먼저 적는 습관이 생겼습니다.
수업 프로젝트에서 배달 앱 리서치를 진행할 때, 가설을 먼저 세우고 인터뷰를 시작했어요. 사용자들이 배달 시간이 길어서 불만이 많을 것이라고 생각했는데, 실제 인터뷰에서는 배달 시간보다 정확한 도착 예측이 없다는 게 더 큰 불만이었습니다. 가설이 일부 맞고 일부 틀렸어요. 이 경험으로 가설을 검증하는 것이 리서치의 역할이고, 틀린 가설도 인사이트가 된다는 걸 배웠습니다. 이후엔 인터뷰 전에 열린 질문을 먼저 배치하는 방식으로 바꿨어요. 이후엔 인터뷰 전에 열린 질문을 먼저 배치하는 방식으로 바꿨어요. 틀린 가설도 인사이트가 되고, 검증 자체가 배움이라는 걸 배웠습니다.
사이드 프로젝트 리서치에서 처음엔 사용자 경험 전체가 문제라는 너무 넓은 가설을 세웠어요. 인터뷰를 해보니 불만이 너무 다양해서 어디서 시작해야 할지 몰랐습니다. 리서치 결과를 자주 언급된 순서로 정렬하고, 가장 많이 나온 문제에 집중하기로 했어요.
회원가입 후 첫 화면에서 무엇을 해야 할지 모른다는 게 핵심으로 떠올랐습니다. 그 문제를 기준으로 좁은 가설 두 개 — 진입점이 불명확하거나, 첫 기능이 어렵거나로 재정의했어요. 리서치는 문제를 넓히는 게 아니라 좁히는 과정이라는 걸 배웠습니다. 리서치는 문제를 넓히는 게 아니라 좁히는 과정이라는 걸 배웠습니다. 좁게 정의된 문제가 더 실행 가능한 해결책을 만든다는 걸 직접 경험했어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 UX 리서처 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.