이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
논리적인 디자인을 위해 사용하는 프로세스는 문제 정의 → 근거 수집 → 선택지 생성 → 결정 네 단계입니다. 디자인 결정에서 가장 흔한 실수는 솔루션부터 시작하는 것이라고 생각합니다. 학부 프로젝트에서 사용자가 불편하다고 한 말을 그대로 기능으로 만들었다가 실제 사용에서는 다른 문제가 더 크다는 걸 발견한 적이 있습니다. 그 이후로 왜 불편한지를 먼저 파악하고, 근본 원인이 밝혀진 뒤에 솔루션을 생각하는 순서를 의식합니다.
Why-How-What 프레임으로 발표 자료를 구성하면 디자인 의도를 논리적으로 설명하기도 쉬워집니다. 아직 복잡한 서비스에서 이 프로세스를 완전히 적용해본 경험은 없지만, 간단한 과제에서도 이 순서를 지키면 결과물에 이유가 생긴다는 걸 배웠습니다.
논리적 설계 프로세스를 적용한 후 실제로 결과가 달라졌는지 확인하는 과정도 진행했습니다. 문제 정의 없이 만든 첫 번째 화면과 근본 원인을 먼저 파악하고 만든 두 번째 버전을 각각 5명에게 보여줬습니다. 첫 번째는 3명이 3단계에서 막혔고, 두 번째는 같은 단계에서 막히는 사람이 1명으로 줄었습니다. 샘플이 작아서 정확한 수치라고 하기는 어렵지만, 방향이 맞다는 것을 확인하는 데는 충분했습니다.
프로세스가 있다고 결과가 보장되는 것은 아니지만, 방향이 잘못됐을 때 빨리 알 수 있다는 점에서 가치가 있었습니다. 검증 없는 프로세스는 반쪽짜리라는 것을 그때 이해했습니다.
논리적인 설계를 팀에 설득할 때 Why-How-What 순서로 발표하는 방식이 효과적이었습니다. 이전에는 만든 결과물을 먼저 보여주고 설명하는 방식이었는데, 왜 이 문제를 풀어야 하는지부터 시작하자 팀원들이 설계 의도를 더 빨리 이해했습니다. 같은 내용이었는데 설득에 걸리는 시간이 줄었고, 의견 충돌도 적었습니다.
이유가 공유되면 결과물에 대한 수정 제안도 더 건설적으로 바뀐다는 것을 그때 경험했습니다. 아직 복잡한 이해관계자를 설득하는 경험은 부족하지만, 논리 구조가 명확하면 설계 결정을 지키는 것이 더 쉽다는 것을 배웠습니다. 이후 팀 발표에서는 결과보다 이유를 먼저 말하는 습관이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 그래비티랩스 프로덕트 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.