이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
수업에서 발견부터 출시까지 전체 디자인 과정을 경험하는 프로젝트를 진행했습니다. 리서치 측면에서는 사용자 문제를 먼저 파악하지 않으면 이후 모든 결정이 추측에 의존하게 된다는 걸 배웠습니다. 와이어프레임 측면에서는 시각 디자인 전에 구조와 흐름을 낮은 충실도로 먼저 검토하는 단계가 나중에 수정 비용을 줄인다는 걸 경험했습니다. 프로토타입 측면에서는 클릭 가능한 프로토타입으로 사용자 테스트를 진행하면 가설을 빠르게 검증할 수 있다는 걸 배웠습니다. 핸드오프 측면에서는 개발자에게 디자인을 전달할 때 간격, 색상 코드, 컴포넌트 상태를 명확하게 문서화하는 것이 구현 품질을 높이는 방법이라는 걸 경험했습니다. E2E 디자인에서 중요한 건 각 단계를 완벽하게 하는 것보다 피드백 루프를 빠르게 돌리는 것이라는 걸 그때 배웠습니다.
E2E 제품 디자인에서 각 단계를 독립적으로 보면 연결 지점에서 방향이 흐려지는 경험이 있었습니다. 리서치 단계에서 정의한 문제가 와이어프레임 단계에서 어떻게 반영됐는지를 확인하지 않으면, 설계가 리서치 인사이트에서 멀어지는 방향으로 흘러가는 경우가 있었습니다.
How Might We(HMW) 질문 형식으로 문제를 구조화하면, 그것이 설계 방향의 기준이 되고 이후 검증 단계에서 무엇을 확인해야 하는지가 명확해집니다. Discover→Define→Design→Validate 순서는 각 단계의 산출물이 다음 단계의 입력이 되는 구조라서, 이전 단계 결과를 명시적으로 참조하는 습관이 연결을 유지하는 방법이었습니다. 단계 간 이해관계자 리뷰를 거칠 때 이 단계가 이전 리서치 결론과 어떻게 이어지는지를 설명하는 것이 방향 합의를 빠르게 만들었습니다. 프로세스는 단계가 아니라 연결이 완성됩니다.
E2E 디자인 과정에서 어느 단계가 가장 중요한지를 경험으로 정리한다면 문제 정의 단계라는 게 본인 판단입니다. 리서치 단계에서 데이터를 많이 모아도 어떤 문제를 풀기로 했는지가 불명확하면 이후 설계와 검증 단계의 기준이 흐려집니다. 팀 프로젝트에서 사용자 인터뷰 결과를 보고 어떤 문제에 집중할지 팀이 다르게 해석한 경험이 있었는데, 그 불일치가 와이어프레임 단계까지 이어져 수정 비용이 컸습니다.
Problem Statement를 명시적으로 문서화하고 팀이 동의하는 과정이 이후 단계의 흔들림을 줄이는 투자라는 걸 그때 배웠습니다. 문제 정의가 잘 돼 있으면 아이디어가 여러 개 나왔을 때 어떤 방향이 맞는지를 기준으로 수렴할 수 있습니다. 좋은 프로세스는 어디서 왔는지를 언제나 돌아볼 수 있는 기반 위에 세워집니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 프로덕트 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.