프로덕트 디자이너 면접 질문 — 버린 시안이 최종 화면보다 쓸모 있습니다

회사와 제품에 따라 질문 문구는 달라집니다. 그래도 프로덕트 디자이너 면접에서 최종 화면만 설명하면 한 가지가 통째로 빠집니다. 왜 이 안을 남겼고, 왜 다른 안을 버렸는지입니다.

최종 화면은 결론입니다. 누가 문제를 정의했고, 무엇을 포기했고, 어떤 근거로 팀을 설득했는지는 결론만 봐서는 안 보입니다. 그래서 버린 시안이 필요합니다. 실패작이라서가 아니라, 당신의 판단 경로가 아직 남아 있어서입니다.

🧭 실제로 보는 건 화면이 아니라 결정입니다

Cue가 보관한 프로덕트 디자인 공고와 그 공고를 바탕으로 만든 질문 아카이브를 보면, 질문의 초점은 최종 UI에 멈추지 않습니다. 사용자 행동의 맥락, 데이터와 직감 사이의 우선순위, 기술 제약, 이해관계 충돌, 예상과 다른 결과 뒤의 수정 판단을 확인합니다.

한국고용정보원 워크넷의 UX디자이너 직업 인터뷰도 버튼 배치로 직무를 끝내지 않습니다. 사용자 니즈를 디자인에 적용하려면 왜 필요한지, 어떻게 해야 하는지, 어떤 결과를 예상하는지 설명하고 설득할 수 있어야 한다고 짚습니다.

20년 넘게 사람을 뽑고 면접을 봐온 입장에서, 포트폴리오 면접에서 확인하는 건 ‘예쁜가’보다 이 사람이 다음 제약에서도 납득할 만한 결정을 다시 만들 수 있는가입니다. 화면은 결과를 보여주고, 결정은 재현 가능성을 보여줍니다. 둘은 다른 증거입니다.

🎨 포트폴리오 면접은 발표 시험이 아닙니다

완성본을 보여주고 문제·해결·성과로 곧장 달리면 이야기는 깔끔합니다. 너무 깔끔해서 당신이 사라집니다. 팀이 정한 문제인지, 당신이 정의한 문제인지. 개발자가 제안한 해법인지, 당신이 만든 선택지인지. 화면만으로는 분리되지 않습니다.

항상 같은 방식으로 진행되지는 않지만, 포트폴리오 질의응답은 이 빈칸을 꼬리질문으로 복원하는 절차가 됩니다. 이때 버린 시안은 실패작이 아니라 판단의 체크섬입니다. 다른 선택지가 있었고, 비교 기준이 있었고, 새 증거에 따라 결정을 바꿨다는 사실을 한꺼번에 보여주니까요.

‘이 안이 더 직관적이었습니다’로 끝내면 감상평입니다. 누구에게, 어떤 장면에서, 무엇이 덜 헷갈렸는지까지 가야 직무 답변이 됩니다.

🗑️ 질문 하나 — 왜 첫 시안을 버렸나요?

대표 질문은 이렇게 들어옵니다. ‘처음 검토한 안은 무엇이었고, 왜 최종안에서 제외했나요?’

답변에는 원래 가설 → 새로 확인한 증거 → 버린 이유 → 남은 제약 → 확인 방법이 이어져야 합니다. ‘더 깔끔해서 바꿨다’는 말에는 판단 기준이 없습니다. 피그마는 열렸는데 지원자는 안 보이는 답입니다. 🙃

예를 들면 이렇습니다. ‘처음에는 선택지를 한 화면에 모두 노출했습니다. 비교를 빠르게 만들려는 가설이었습니다. 그런데 사용성 테스트에서 선택 기준을 찾지 못해 멈추는 장면을 확인했습니다. 추천 로직을 새로 만들 수 없는 일정이라, 사용 목적을 먼저 묻고 선택지를 좁히는 안으로 바꿨습니다. 출시 뒤에는 이탈 지점과 문의 내용을 함께 확인했습니다.’

정답 시안을 맞히는 답이 아닙니다. 증거가 바뀌자 판단도 바꿀 수 있었다는 답입니다.

⚖️ 질문 둘 — 데이터와 직감이 충돌했을 때 무엇을 믿었나요?

‘데이터를 따랐습니다’는 안전해 보입니다. 그런데 데이터가 무엇을 보여주고 무엇을 못 보여줬는지 빠지면, 안전한 게 아니라 빈 답입니다.

좋은 답은 증거의 관할부터 나눕니다. ‘클릭 로그는 어디서 떠나는지는 보여줬지만 왜 떠나는지는 보여주지 못했습니다. 사용자 대화에서 용어가 책임 범위로 오해된다는 단서를 잡았고, 전체 구조를 뒤집기보다 문구와 안내 순서를 검증 대상으로 좁혔습니다.’ 이런 식입니다.

평가 기준은 데이터 숭배가 아닙니다. 증거의 한계를 알고, 직감을 검증 가능한 가설로 낮추고, 그래도 결정을 미루지 않았는지를 봅니다.

🤝 질문 셋 — 개발 제약 때문에 디자인을 바꾼 적이 있나요?

‘디자인을 끝까지 지켰습니다’도, ‘개발 일정에 맞췄습니다’도 반쪽입니다. 한쪽은 협업이 없고, 다른 쪽은 디자인 판단이 없습니다.

답변에서는 지켜야 할 사용자 결과와 바꿔도 되는 구현 방식을 나누세요. 충돌한 목표, 당신이 만든 대안, 각 대안의 대가, 합의에 쓴 기준, 출시 뒤 확인한 부작용 순서면 충분합니다. 협업을 ‘사이좋게 풀었다’로 설명하면 당신의 결정이 다시 흐려집니다.

면접 일정이 아직 없어도 포트폴리오를 뜯어고칠 필요는 없습니다. 진행 중인 프로젝트마다 버린 시안 하나와 버린 이유 한 줄만 남겨두세요. 최종 화면은 나중에도 찾을 수 있습니다. 그때의 제약과 망설임은 나중에 복원하기 어렵습니다.