이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 교내 시설 예약 서비스를 만들기 전에 사용자 조사를 했습니다. 처음에는 설문으로 시작했는데, "불편하다"는 응답은 많아도 어디가 불편한지가 구체적으로 나오지 않았습니다.
그래서 5명에게 직접 기존 예약 방법으로 예약을 완료해달라고 부탁하고 옆에서 지켜봤습니다. 그 과정에서 모두가 같은 단계에서 멈췄습니다. 로그인 후 예약 메뉴를 찾지 못하는 것이었는데, 메뉴 이름이 예약하려는 시설 이름과 달랐기 때문이었습니다. 설문에서는 이 문제가 전혀 나오지 않았습니다.
그 경험에서 사용자 문제는 말로 묻는 것보다 직접 쓰는 것을 보는 게 더 정확하다는 걸 배웠습니다. 이후에는 관찰을 먼저 하고, 관찰에서 나온 패턴을 인터뷰로 확인하는 순서로 방법을 바꿨습니다.
학부 UX 수업 프로젝트에서 도서관 좌석 예약 앱 개선을 맡았습니다. 먼저 앱 사용 데이터를 분석했는데, 특정 화면에서 이탈률이 다른 화면보다 2.5배 높았습니다. 그 화면이 어떤 문제인지는 수치만으로는 알 수 없었습니다.
그 화면을 집중적으로 8명에게 써보게 하면서 말로 설명해달라고 했습니다. 대부분이 같은 버튼을 찾지 못했는데, 버튼 색상이 배경색과 비슷해서 눈에 잘 안 띄는 것이었습니다. 수치는 "어디서 문제가 나는지"를 알려줬고, 관찰은 "왜 그런지"를 알려줬습니다.
두 방법이 각각 다른 걸 알려준다는 걸 그때 배웠습니다. 수치 없이 인터뷰만 하면 위치 파악이 어렵고, 인터뷰 없이 수치만 보면 원인을 모릅니다. 두 방법을 연결하는 것이 사용자 문제 수집의 핵심이라고 생각합니다.
동아리에서 행사 참가 신청 양식을 개선하는 프로젝트를 했습니다. 팀원들이 "너무 항목이 많아서 불편할 것"이라고 생각했고, 저도 처음에 그 가설을 믿었습니다.
그런데 10명에게 실제로 양식을 작성해보게 했더니, 항목 수가 문제가 아니었습니다. 어떤 항목에 무엇을 써야 하는지 설명이 없어서 "이게 맞나"를 계속 확인하는 것이 피로감의 원인이었습니다. 항목 수를 줄이는 게 아니라 각 항목에 예시를 넣는 것이 해결책이었습니다.
그 경험에서 "우리가 문제라고 생각하는 것"과 "실제 사용자의 문제"가 다를 수 있다는 걸 배웠습니다. 가설을 먼저 세우되, 사용자 조사로 검증하는 단계가 빠지면 엉뚱한 곳을 고치게 된다는 걸 직접 겪었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프로덕트 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.