이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사용성 테스트와 유저 인터뷰에 능숙하다고 느끼는 건 직접 여러 번 반복하면서 실수를 교정한 경험 덕분입니다. 처음 인터뷰를 진행했을 때 유도 질문을 너무 많이 써서 유의미한 인사이트를 거의 못 얻었습니다. 그 이후 「왜 그렇게 하셨나요?」와 「무슨 생각이 드셨나요?」 위주의 열린 질문 방식으로 바꾸면서 결과가 달라졌습니다. 사용성 테스트는 사용자가 혼자 화면을 탐색하는 것을 관찰하는 것이 핵심인데, 개입 충동을 참는 것이 가장 어렵고 중요한 기술이라는 걸 경험으로 배웠습니다.
아직 대규모 리서치 설계는 경험이 적지만, 소규모 인터뷰에서 얻을 수 있는 인사이트를 최대화하는 방식은 익혔습니다.
사용성 테스트에서 리서치 결과의 신뢰도는 설계 단계에서 결정된다는 것을 경험했습니다. 초반에는 편의 표집으로 참여자를 구성하다 보니 목표 사용자와 다른 행동 패턴이 데이터에 섞여 방향이 흐려지는 경험이 있었습니다. 이후 인터뷰 전에 참여자 기준을 먼저 정의하고, 탐침(Probe) 질문 순서를 미리 합의하는 방식으로 바꿨습니다.
언모더레이티드(Unmoderated) 방식은 규모 확보에 유리하지만 예상치 못한 행동이 생겼을 때 즉시 탐침이 불가해서 목적에 따라 방식을 선택하는 기준이 생겼습니다. 리서치 결과를 팀에 공유할 때는 관찰한 사실과 해석을 분리해서 합의 과정을 밟는 것이 설계 결정의 근거를 명확하게 만든다는 걸 배웠습니다. 근거를 쌓는 과정은 데이터를 모으는 것이 아니라 어떤 데이터를 왜 모았는지를 설명할 수 있는 것입니다.
사용성 테스트와 유저 인터뷰에서 데이터를 수집하는 것보다 수집 후 설계 시사점(Design Implication)을 도출하는 단계가 더 어렵다는 것을 배웠습니다. 인터뷰 후 친화도 분류(Affinity Mapping)를 통해 패턴을 묶는 과정은 경험하면서 익혔지만, 그 패턴이 어떤 설계 변경으로 이어져야 하는지를 팀에 설득력 있게 제시하는 경험은 아직 적습니다.
리서치 인사이트와 설계 결정 사이의 연결을 명확히 문서화하는 것이 시니어 디자이너와의 차이를 만든다는 걸 경험을 통해 알게 됐습니다. 리서치 결과를 설계 요구사항(Design Requirement)으로 번역하는 능력이 제가 더 채워야 할 부분입니다. 데이터를 모으는 것은 시작이고, 그것을 설계 방향으로 연결하는 것이 리서치의 실질적인 목표라는 걸 그때 배웠습니다. 능숙함은 모으는 것에서 연결하는 것으로 옮겨가는 과정에 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ제일제당 프로덕트 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.