프로덕트 디자이너 이력서 작성법 - 포트폴리오는 충분한데 서류에서 떨어집니다

프로덕트 디자이너는 이력서를 가볍게 쓰는 직무입니다. 결과물이 포트폴리오에 다 있으니 이력서에는 회사와 기간, 그리고 링크 한 줄이면 충분하다고 보는 것입니다. 그런데 서류에서 갈리는 지점은 대개 그 링크 앞입니다. 담당자는 포트폴리오를 열지 말지를 이력서를 읽고 정하기 때문입니다. 여기에는 이 직무만의 사정이 하나 더 있습니다. 프로덕트 디자이너라는 직함은 UX와 UI와 비즈니스를 함께 다룬다는 뜻인데, 화면 이미지만 잔뜩 걸어두면 담당자에게는 UI 디자이너로 읽힙니다. 직함을 증명하는 자리는 포트폴리오가 아니라 이력서 본문입니다.

담당자가 가장 먼저 찾는 건 디자인이 움직인 숫자다

프로덕트 디자이너 이력서에서 가장 강한 문장은 디자인 결정과 지표를 인과로 연결한 문장입니다. 전환율, 이탈률, 리텐션, 활성화 같은 숫자를 디자인 용어가 아니라 비즈니스 용어로 말할 수 있느냐가 이 직무의 갈림길입니다. "온보딩 플로우를 개선했습니다"는 확인할 방법이 없는 문장입니다. 같은 일을 "가입 3단계에서 이탈이 집중되는 것을 확인하고 단계를 하나로 합쳐 활성화율을 32퍼센트에서 41퍼센트로 올렸습니다"라고 적으면 화면을 그린 사람이 아니라 화면으로 지표를 움직인 사람이 됩니다. 여기에 A/B 테스트로 두 안을 비교했다는 서술이 붙으면 더 강해집니다. 지표를 볼 수 없는 회사에 다니는 경우도 많습니다. 측정 인프라가 없으면 그건 개인의 문제가 아니니 없는 숫자를 만들어 넣을 필요는 없습니다. 대신 사용성 테스트에서 나오는 숫자를 쓸 수 있습니다. 과업 성공률과 소요 시간은 참가자 다섯 명으로도 전후 비교가 됩니다.

리서치는 했다는 사실이 아니라 결정을 바꿨다는 증거가 필요하다

"사용자 인터뷰 8회 진행"은 담당자에게 아무 정보도 주지 않습니다. 리서치를 했다는 사실은 지원자 대부분이 적기 때문입니다. 차이를 만드는 건 그 리서치가 설계를 실제로 뒤집었다는 인과입니다. 인터뷰에서 사용자들이 특정 화면을 설정 메뉴로 오해한다는 것을 발견했고 그래서 원래 안을 접고 진입 경로를 바꿨다는 식으로 적으면, 리서치를 절차로 소화한 사람과 판단 근거로 쓴 사람이 갈립니다. 발견 하나와 그로 인한 변경 하나를 붙여 쓰는 것만으로 충분합니다. 사용성 테스트를 적을 때는 방법을 함께 적습니다. 몇 명을 대상으로 어떤 태스크를 어떤 방식으로 테스트했는지가 없으면 검증했다는 말만 남습니다. 대면인지 원격인지, 게릴라 테스트인지 정량 설문인지에 따라 결과의 무게가 다르고 담당자는 그 차이를 압니다.

디자인 시스템은 연차를 가르는 신호다

비슷한 경력끼리 견줄 때 담당자 눈에 차이를 만드는 항목이 디자인 시스템입니다. 컴포넌트와 토큰을 정리하고 문서로 남겨 팀이 같이 쓰게 만든 경험은 혼자 화면을 만드는 단계를 지나 팀이 딛는 기반을 만드는 단계로 넘어갔다는 신호입니다. 규모가 작아도 괜찮습니다. 버튼과 폼 몇 개라도 중복 시안을 정리해 개발자와의 핸드오프 방식을 바꿨다면 그 자체가 시니어 방향의 근거가 됩니다. 이때도 무엇이 얼마나 줄었는지를 함께 적는 편이 낫습니다. 시안 요청이 절반으로 줄었다거나 신규 화면 제작 기간이 짧아졌다는 서술이 붙으면 시스템을 만들었다는 말이 검증 가능해집니다.

무엇을 버렸는지가 제품 조직에서 일한 깊이를 드러낸다

디자이너 이력서에는 만든 것만 적히는 경우가 많습니다. 그런데 제품 조직에서 일한 깊이는 오히려 버린 것에서 드러납니다. 일정과 개발 리소스 안에서 무엇을 먼저 내고 무엇을 다음으로 미뤘는지, 그 판단의 근거가 무엇이었는지가 PM 및 개발자와 실제로 협업한 사람에게서만 나오는 서술입니다. 가설을 세우고 작게 검증한 뒤 확장한 경험이 있다면 그 순서대로 적습니다. 처음부터 전체 화면을 다 그리지 않고 핵심 플로우만 먼저 내보내 반응을 본 다음 범위를 넓혔다는 이야기는 짧게 적어도 제품 감각을 보여줍니다.

포트폴리오는 이력서가 한 말을 확인하는 자리다

포트폴리오 자체에 대해서도 정리해두면 좋습니다. 경력직에게 포트폴리오는 판단 재료의 전부가 아니라 이력서에 적은 내용을 확인하는 자리입니다. 그래서 케이스 스터디는 화면을 늘어놓는 방식보다 문제 정의부터 탐색과 결정 근거를 거쳐 결과까지 이어지는 구성이 낫습니다. 담당자가 이력서에서 본 문장을 포트폴리오에서 다시 만나면 신뢰가 생깁니다. 신입과 주니어는 사정이 다릅니다. 회사 경력이 없으니 포트폴리오의 비중이 훨씬 크고, 이때는 실사용자가 있는 사이드 제품 하나가 가상 리뉴얼 과제 여러 개보다 강하게 작동합니다. 작아도 실제로 배포해서 전환이나 재방문 데이터를 손에 쥐어본 경험은 개인 프로젝트로 만들 수 있는 거의 유일한 지표 경험입니다. 반대로 실험 인프라 위의 A/B 검증이나 조직 안에서의 우선순위 협상은 개인 프로젝트로 만들 수 없으니 정직하게 회사 경력에서 보여줄 몫으로 남깁니다.

정리하면

프로덕트 디자이너 이력서에서 담당자가 확인하는 건 완성된 화면이 아니라 그 화면을 만든 판단입니다. 어떤 지표를 책임졌고 얼마나 움직였는지, 리서치가 설계를 바꾼 적이 있는지, 팀이 같이 쓰는 기반을 만들어봤는지, 무엇을 포기하고 무엇을 먼저 냈는지가 그 판단을 읽는 자리입니다. 이 네 가지가 본문에 있으면 포트폴리오는 짧아도 됩니다. 문제는 이런 재료가 이력서를 쓰는 시점에는 대부분 사라져 있다는 점입니다. 개선 전후의 전환율이나 사용성 테스트 참가자 수 같은 숫자는 프로젝트가 끝난 직후가 아니면 복원하기 어렵습니다. GridResume를 만들면서 이 지점을 신경 썼습니다. 평소에 커리어 기록으로 한 줄씩 남겨두면 AI 작성 보조가 그 기록을 문제와 결정, 결과의 흐름으로 정리해 이력서 문장으로 다듬어줍니다. 이력서 진단에서는 프로덕트 디자이너 기준으로 지금 이력서에 어떤 신호가 비어 있는지도 짚어드립니다. 포트폴리오에 화면을 한 장 더 얹는 것보다 이미 만든 화면 하나에 그 결정의 근거와 결과를 붙이는 편이 서류에서는 훨씬 크게 작동합니다.