프로덕트 디자이너, 뭐 하는 직무인가요?

디자이너로 첫 취업 준비를 할 때만 해도 ‘프로덕트 디자이너’라는 직무가 생소했는데, 이제는 IT 업계에서 매우 친숙해졌습니다. 당시에는 산업 제품을 만드는 산업디자이너라고 오해하기도 했었습니다. 그러나 프로덕트 디자이너가 제품 및 서비스의 전반적 사용 경험을 디자인하는 직군이라는 걸 알게 된 후에도 UI/UX 디자이너와 어떤 직무 차이가 있는지 그 경계를 명확히 인지하지는 못했습니다.

그러던 중 이직 및 업무 환경 변화를 거치며 자연스럽게 UX/UI 디자이너에서 프로덕트 디자이너로 직무가 바뀌게 되었고, 지금은 2년 차 프로덕트 디자이너로 일하고 있습니다. 이제는 프로덕트 디자이너로서의 제 업무 범위를 제대로 알고 있지만, 아직도 프로덕트 디자이너와 일해 본 경험이 없는 사람들은 다른 직무와 차이를 잘 알지 못합니다. 그래서 지금부터 제가 프로덕트 디자이너로 일하며 느낀, 프로덕트 디자이너의 업무 범위와 하는 일을 이야기해보려 합니다.

프로덕트 디자이너와 UI/UX 디자이너

UI/UX 디자인 직군은 제품에 적합한 사용성을 설계하며, 그를 이루기 위한 화면 디자인까지 담당합니다. 그래서 얼핏 ‘프로덕트 디자인'이라는 업무를 들었을 때 ‘도대체 제품(서비스)에서 UX/UI 밖의 디자인 업무 영역이 뭐가 있지?’라고 생각하기 쉽습니다. 심지어 저는 어떤 커뮤니티에서 ‘프로덕트 디자이너는 앱을 운영하는 중소기업에서 모든 디자인과 기획까지 도맡아 할 직군이 필요해 이름만 그럴싸하게 포장한 것'이라는 글(..!)까지 본 적 있습니다.

물론 이런 말도 안 되는 오해를 하는 사람은 극소수겠지만, 그래도 두 직군의 업무 영역 차이를 제대로 확인하기 위해 채용 사이트에서 두 직군의 ‘Job description(직무기술, 이하 JD)’을 살펴보겠습니다. 기업 문화에 따라 관장하는 업무 영역이 조금씩 달라지겠지만, 프로덕트 디자이너 채용의 JD에 공통적으로 쓰인 내용을 정리하면 아래와 같습니다.

[프로덕트 디자이너 JD]

• 문제 정의: 문제 가설 수립, 유저 데이터와 VOC를 통해 문제점 발굴
• 유저 이해: 유저 니즈 발굴, 사용자 인터뷰, 사용성 테스트
• UI: UI 디자인 및 프로토타입 제작, 디자인 시스템 고도화, 인터랙션 디자인
• UX: IA 설계, 사용자 여정 설계
• 퀄리티 관리 및 유지

반면 UI/UX 디자이너 채용 JD에 공통적으로 쓰인 내용은 이렇습니다.

[UI/UX 디자이너 JD]

• 문제상황별 해결책 제시
• UI: UI 디자인 및 프로토타입 제작, 디자인시스템, 서비스 그래픽요소 디자인, 인터랙션 디자인
• UX: IA 설계, 사용자 여정 설계

비교해 보면 프로덕트 디자이너의 업무 영역이 더 넓습니다.

더 상세하게 살펴보면 기본적인 UI/UX 업무는 두 직군 모두 공통인 영역이고, 문제정의와 유저 이해, 퀄리티 관리 유지 부분에서 차이가 나타납니다. 물론 기업에 따라 각 직군의 업무 영역이 조금 다를 수도 있겠지만, UI/UX 디자이너에게는 ‘HOW’에 더 집중하는 업무를 기대합니다. 반면 프로덕트 디자이너는 ‘HOW’뿐 아니라 ‘What(어떤 문제가 있는지)’, ‘Who(우리의 유저는 누구인지?)’, ‘Why(그것이 왜 문제인지)’까지 관장합니다.

프로덕트 디자이너가 하는 일

프로덕트 디자이너와 UI/UX 디자이너의 업무 차이를 알았으니, 이제 프로덕트 디자이너가 하는 일에 대해 더 자세히 기술해보겠습니다.

문제 정의

지표나 사용성에서 드러나는 문제 현상을 확인하고, 그 현상의 진짜 원인을 파악하는 과정입니다. 문제 현상은 디자이너 직관에 의해 파악되기도 하지만 유저 데이터나 유저의 목소리 (VoC)를 통해 알 수 있습니다. 때문에 유저 데이터와 VoC를 파악하고 이해할 수 있어야 합니다. 그렇게 알아낸 문제들을 해결하기 위한 가설을 세우고 해결 방법을 구체화합니다.

문제 정의 영역은 PO의 업무 범위와도 일정 부분 겹칩니다. 차이점이 있으면 PO는 좀 더 지표와 데이터, 비즈니스에 초점을 맞추어 문제를 발견하고, 프로덕트 디자이너는 사용성에 초점을 맞추어 문제를 발견하는 점입니다. 비즈니스적 지표 개선을 위한 프로젝트를 진행할 때도 프로덕트 디자이너는 사용성을 해치지 않는 측면에서 그 문제를 해결할 수 있게 사용자 입장에서 생각하고 해결 방법을 제안해야 합니다. 그렇기에 이 과정에서는 PO와 디자이너가 긴밀하게 자주 소통하고 의견을 조율하는 편입니다.

유저 데이터를 활용할 필요가 있다고 해서 ‘Data Analyst (데이터 분석가, 이하 DA)’ 만큼의 데이터 분석능력이 좋을 필요는 당연히 없습니다. 전문성이 달라서 그러기도 힘들고요. 다만 PO나 DA가 제시하는 지표들을 이해할 수 있어야 하고, 그런 지표 결과를 이끈 유저의 행동과 지표 개선을 위한 가설들을 제시할 수 있어야 합니다.

사용자 이해

우리 제품의 사용자들을 늘리고 지속해서 이용하게 하려면, 그들의 니즈를 파악해 원하는 것을 제공해야 합니다. 이를 위해 프로덕트 디자이너는 사용자를 이해하기 위한 조사를 진행하기도 합니다. 기업에 따라 UX 디자이너나 ‘Researcher(자료 조사원)’가 담당하기도 합니다.

사용자 조사만 담당하는 직군은 인지 심리학이나 통계학, HCI 등을 바탕으로 정량, 정성적인 사용자 평가를 진행합니다. 프로덕트 디자이너는 리서치 직군만큼 아주 뾰족하고 전문적으로 사용자 조사를 담당할 순 없지만, 일정 부분 이런 역할을 수행합니다.

사용자 설문을 진행해서 우리 앱을 이용하는 (혹은 이용하게 될) 사용자들의 정량적 패턴을 조사하고, 사용자 인터뷰를 통해 설문으로는 파악할 수 없었던 사용자들의 감정 맥락과 숨겨져 있던 니즈를 알아냅니다. 또 프로토타입 단계에서 사용성 테스트를 설계 및 진행하여 제품 개발 전에 미리 사용성을 평가하고, 문제가 되는 사용성을 파악해 개선합니다.

개인적으로는 이러한 사용자 조사를 통해 얻은 인사이트를 팀에 공유하여 디자이너 외 직군의 동료들도 사용성에 관심을 두게 하고 그 중요성을 깨닫게 하는 것 또한 프로덕트 디자이너의 역할이라고 생각합니다. 사용자 특성과 패턴을 나누는 것만으로도 사용성 중심의 팀 문화를 구축하는 데 도움이 되기 때문입니다.

UI/UX

앞서 정의한 문제를 해결할 수 있는 구체적인 방향을 정하고, 그 방향에 적합한 화면을 설계하고 디자인하는 과정입니다.

먼저 제품 내에서 사용자가 쉽게 행동할 수 있도록 여정 플로우를 짜고 구조화합니다. 전체적인 구조가 만들어졌으면 사용자의 실패 케이스, 성공 케이스를 정의하고 엣지 케이스(알고리즘이 처리하는 데이터의 값이 일정한 범위를 넘을 경우에 발생하는 문제)가 없는지 확인합니다. 이 작업 후에 PO 및 개발자들과 소통하며 전체 플로우에 문제가 없는지, 실제 구현에 무리가 없을지 등을 논의하며 의견을 맞춥니다.

필요한 화면의 수와 화면을 구성할 정보들이 정해졌으면 와이어 프레임이나 레퍼런스 이미지들로 디자인의 방향성을 더 구체화합니다. 이는 본격적인 디자인 작업에 들어가기 전에 관련 작업자들과 예상 시안을 더 자세히 맞추기 위해서이기 때문에 PO/PM 및 개발자들과 한 번 더 논의를 진행하기도 합니다.

와이어프레임 및 레퍼런스 이미지까지 의견 조율이 끝났다면, 이제 드디어, 본격적인 디자인 작업을 시작합니다. 우리 제품의 톤앤매너에 맞게 디자인 컴포넌트를 이용하여 화면을 구성하고, 문제 해결에 적합한 UX Writing이 무엇인지도 고민합니다. 적절하게 인터랙션을 넣기도 합니다. 시안이 완성되면 PO 혹은 다른 디자이너들과 디자인 리뷰를 거쳐 디자인을 마무리합니다.

이처럼 문제 해결을 위한 UX/UI 디자인을 하기도 하지만, 한편으로는 디자인 시스템을 구성하는 UX/UI 디자인을 하기도 합니다. 이는 제품에 반복적으로 쓰이는 컴포넌트들을 시스템화하여 어디든 응용할 수 있도록 규칙을 만드는 작업으로 통일성 있는 UI를 유지하고 효율적인 개발을 위한 업무입니다. 기업에 따라 디자인 시스템을 만드는 UI 디자이너가 따로 있기도 합니다.

또 우리 제품의 UX Writing 성격과 규칙을 정하는 일도 프로덕트 디자이너의 업무입니다. 다만 몇 년 전부터 UX Writing의 중요성이 큰 화두로 떠오르면서 UX Writer 직군을 따로 채용하기도 합니다.

퀄리티 관리 및 유지

넓게는 우리 제품의 전체 로드맵과 방향성에 대한 이해를 바탕으로 일관적인 사용성과 퀄리티를 유지하기 위한 업무를 진행하는 과정이며, 좁게는 디자인 완료 후 실제로 반영된 제품의 퀄리티를 디자인 시안과 동일하게 나올 수 있도록 관리하는 업무입니다. 보통 ‘Quality Assurance(품질 보증, 이하 QA)라고 하는 과정입니다.

디자인 QA에 대해 좀 더 덧붙이자면, ‘작업한 디자인이 똑같이 구현이 잘 되었나'를 확인하는 것을 넘어 ‘막상 실제 구현물을 보니, 이 플로우에서 경고 메시지가 떠야지 사용자의 상황 이해가 더 쉬울 것 같아. 후속 작업으로 경고 메시지 노출하는 것을 바로 제안해야겠어’와 같이 더 좋은 사용성을 위한 추가 개선을 생각하고 제안할 때도 있습니다.

일 잘하는 프로덕트 디자이너는?

앞서 살펴본 것처럼 프로덕트 디자이너의 업무 영역은 매우 넓은 편입니다. 또 다른 직군들과의 협업, 소통 지점도 많습니다. 특히 한 프로젝트를 처음부터 끝까지 관여하며 끌어가야 하기 때문에, 다른 업무를 하다가 넘어오면 많은 우여곡절과 시행착오를 거치게 됩니다. 그러면서 ‘아, 지금의 나는 이런 역량이 필요하구나’, 혹은 ‘이런 것까지 잘 해내야 하는구나’를 깨닫게 됩니다. 그래서 개인적인 경험을 바탕으로 일 잘하는 프로덕트 디자이너가 되기 위한 역량들을 정리해 봤습니다.

다른 직무의 일하는 방식을 이해하자

그 이유는 당연하게도 원활한 커뮤니케이션 때문입니다. 특히 개발자가 일하는 방식을 이해하지 못하면 많은 업무 비효율이 발생할 수 있습니다. 내가 제안한 구현 방식이 현실적으로 불가능하거나 투자한 리소스 대비 효과가 기대되지 않는다면 다른 해결 방법을 제안해야 합니다. 하지만 개발자들이 일하는 방식을 이해해서 실제 개발에 원활한 기획안을 제시한다면, 디자인과 의견 조율에 쓰이는 불필요한 리소스를 절약할 수 있습니다.

물론 프로덕트 디자이너가 항상 모든 작업자의 작업 방식을 고려한 최적의 솔루션을 제안하기는 힘듭니다. 하지만 다른 직무에 대한 이해도를 높이려고 시도하면, 당장 실행하기 무리가 있는 안을 제안했더라도 구현에 용이한 범위에 맞춰 프로젝트를 단계별로 쪼개는 시도를 할 수 있게 됩니다.

필요한 피드백을 선별하자

프로덕트 디자이너는 PO, 개발자, 다른 디자이너들, 또 QA와도 지속적인 소통하는 직군입니다. 그 과정에서 각 직무의 관점에서 들어오는 피드백을 받게 되는데, 그 의견들이 다른 직무의 의견과는 상충하게 될 때가 있습니다. 전체의 의견 조율을 하고 키를 잡는 것은 PO의 역할이지만, 프로덕트 디자이너가 피드백 무덤에 깔려 고통받거나 서로의 의견을 전달만 하는 올빼미 역할에서 벗어나기 위해서는 프로덕트 디자이너가 좋은 피드백을 선별할 수 있는 역량이 필요합니다.

필요한 피드백을 선별하기 위해선 먼저 (당연하게도) 지금 진행하고 있는 프로젝트의 목표를 잘 이해하고 있어야 합니다. 그래서 각 피드백이 목표에 부합하는지, 부합한다면 각각의 우선순위가 어떻게 되는지를 따져봐야 합니다.

또 한 가지 유념할 마음가짐은 ‘내가 사용성 전문가'라는 생각을 가지고 있어야 합니다. 때로는 공급자 입장에서 사용성을 고려하지 않은 피드백이 들어오기도 합니다. 그들도 해당 직무에서 최고의 전문가겠지만, 우리는 프로덕트 디자이너로서 그런 피드백을 사용자 관점에서 반박하고 의견을 절충하는 방향으로 발전할 수 있어야 합니다.

때로는 넓게, 때로는 좁게

우리 목표를 달성할 수 있는 사용자 여정을 그리기 위해서는 사용자의 전체 사용 맥락을 볼 수 있도록 넓은 시각이 필요합니다. 전체 그림을 바라보며 이 방법이 정말 이 문제를 해결할 수 있는지, 다른 플로우에 영향을 미치는 것은 없는지, 놓친 사용 맥락이 없는지를 확인해야 합니다.

그리고 구현 방법에 가장 적합한 UI 화면을 그릴 때에는 이 UI 요소와 UX writing 적합한지, 유저가 이 정보를 잘 인식할 수 있는지, 정보 중요도에 따른 대비가 잘 느껴지는 지 등 한땀 한땀 장인 정신으로 디테일의 완성도를 끌어올려야 합니다.

개인적으로는 넓은 시각에서 좁은 시각으로 조절을 할 때 조정이 잘 이루어 지지 않아 디테일을 놓치거나 숲을 봐야할 타이밍에 나무 이파리 하나에 몰두해서 정작 중요한 걸 놓쳐버리는 때가 있었습니다. 이런 실수를 면하기 위해선 지금 내가 보고 있는 척도가 몇인지를 점검해보며 타이밍에 맞게 시각 조정을 할 수 있어야 합니다.

같은 직무로 만나기를 기대하며

지금껏 UI/UX 디자이너와 프로덕트 디자이너가 하는 일의 차이를 알아보고, 프로덕트 디자이너가 관장하는 업무 영역과 구체적으로 하는 일들에 관해 알아보았습니다. 또 개인 경험을 바탕으로 일 잘하는 프로덕트 디자이너가 되기 위해 필요한 역량들도 이야기해보았습니다.

물론 위 업무들은 기업에 따라 조금씩 차이가 있습니다. 또 프로덕트 디자이너의 업무 영역이 넓은 만큼 더 관심 있고 욕심나는 업무 영역도 각자 다를 수 있습니다. 다만 프로덕트 디자이너의 기초적인 영역에 관해서는 최대한 열심히 설명했습니다. 이제껏 프로덕트 디자이너의 역할이 궁금했던 취업준비생이나 혹은 프로덕트 디자이너를 지망하는 분들이 이 글을 읽고 프로덕트 디자이너가 어떤 사람인지 조금은 알게 되었기를 기대합니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.