프로덕트 디자이너로서 기획하고 디자인하기, 그리고 함께 더 잘하기
안녕하세요. 저는 마이리얼트립에서 프로덕트 디자이너로 일하고 있는 설자현입니다.
마이리얼트립의 프로덕트 디자이너는 서비스의 웹, 앱 UI 디자인뿐 아니라 문제 정의, 해결 방안에 대해서도 PO(Product Owner)와 함께 기획하는 역할을 하고 있습니다. 또한 디자이너들과도 의견을 나누며 기획과 디자인 결과물을 더 견고하게 만듭니다.
이렇게 한 프로젝트에서 디자인 결과물이 실 서비스에 반영되기까지 여러 사람들과 협업이 이루어지고 있는데요. 다른 회사들은 이 과정이 어떻게 이루어지고 있는지 매우 궁금했던 한 사람으로서 저와 같은 분들을 위해 마이리얼트립은 어떻게 하고 있는지 공유해보고자 합니다.
구체적으로 기획 시 어떤 관점에서 시작하는지, 그 기획이 디자인으로 어떻게 넘어가는지, 최종 디자인이 나오기까지 어떤 의사소통을 거치는지에 대해서요. 그리고 앞으로 우리가 집중하고자 하는 기획과 디자인 방향에 대한 고민도 글로 함께 나눠보겠습니다.
PO(Product Owner)와 함께 기획 시작하기
프로젝트는 ‘기획, 디자인, 개발, QA, 실 서비스 반영, 회고’의 과정으로 이루어집니다. 기획과 디자인 단계에서 PO와 디자이너가 가장 중요하게 여기는 건 문제와 목표입니다.
Step.1 문제 정의하기
우선순위에 따라 이번 분기에 진행할 프로젝트가 정해지면 어떤 문제로부터 시작했는지 PO가 회의를 통해 공유합니다. 문제에 저뿐 아니라 개발자, 사업팀 등의 프로젝트 이해관계자들이 모두 공감한다면 프로젝트가 시작됩니다. 만약 이 단계에서 문제에 대한 근거가 부족하다면 데이터를 더 뽑아보거나 사용자 인터뷰를 진행하기도 합니다. 모두가 여러 근거에 의해 정의된 문제에 동의하면 그 다음은 문제를 효과적으로 해결하는 방법에 관해 이야기가 필요한 단계입니다.
이 단계에서 PO와 프로덕트 디자이너가 자주 회의를 합니다. 프로젝트마다 이 회의에 개발자와 데이터 분석가가 함께하기도 합니다. 주로 화상 미팅을 통해 이야기를 나누지만, 추가적인 의견은 사내 커뮤니케이션 툴인 슬랙으로도 자주 공유가 되죠.
제가 참여했던 프로젝트 중 하나를 예시로 말씀 드리자면 서비스 메인화면과 도시, 두 화면 개선 작업이 있었습니다. 큰 목표는 ‘상품 탐색 시나리오를 개선함으로써 교차 판매율을 높이자’였고, 그 목표를 이루는 데 있어 우리가 해결하고자 하는 문제는 뚜렷했습니다. 데이터를 보니 마이리얼트립에 오는 사용자들이 우리가 마련한 다양한 상품들을 보지 못하고 한정된 상품만 보고 나간다는 사실을 발견했습니다. 사용자 입장에서 자신의 취향에 맞는 다양한 체험 상품을 봐야 구매까지 이어질 텐데 그 당시 메인에서 이어지는 경로는 한 두 개의 테마로 묶인 상품만 보기 쉬웠습니다.
따라서 메인에 아예 그 테마로의 경로를 제거하고 다양한 탐색 방법과 상품을 보여주는 도시 화면으로 이동할 수 있게 하자는 결론이 나왔습니다. 사실 결론이 나기까지 다양한 아이디어가 있었는데요. 아이디어를 내는 주체 역시 매우 다양했습니다. PO부터 디자이너, 회의에 참여한 개발자까지 문제에 대한 이해와 공감대를 기준으로 의미 있는 아이디어를 자유롭게 제안할 수 있었습니다.
Step.2 문제를 해결할 목표 정의하기
이렇게 나온 아이디어가 결국 문제를 해결하고 목표를 달성할 수 있을지 따져보는 일은 문제 정의만큼이나 중요합니다. 따라서 목표를 달성했다는 걸 알 수 있는 측정 지표를 설정해야 하는데요. 앞서 말씀드린 메인, 도시 화면 개선 작업같은 경우, PO와 데이터 분석가가 먼저 측정 지표를 정하고 회의 때 모두에게 공유하며 의견을 받는 식으로 이루어졌습니다. 메인 개선으로 메인에서 도시로 이동하는 비율이 늘었는지 측정하기로 하고, 도시 화면까지 개선했을 때 한 사람당 상품 상세 페이지뷰 수가 더 늘었는지 측정하기로 했습니다. 여기서 ‘한 사람’의 범위는 전체 사용자가 아니라 마이리얼트립에 들어와 상품을 잘 보지 않는 경향을 가진 항공권 구매자였습니다. 상품을 잘 보지 않는 사용자가 더 상품을 보게 만들었을 때 구매까지 일으키는 큰 효과가 있을 것으로 판단했기 때문입니다. 더 직접적인 지표로는 도시 화면 내의 상품 클릭률, 도시에서 상품 리스트로 이동하는 비율도 확인하기로 했습니다.
어떤 지표를 측정할지는 PO와 디자이너가 먼저 이야기해보고 데이터 분석가와 의견을 나누거나, 회의에서 모두가 의견을 모으는 식으로 정해지기도 합니다. 프로젝트의 성격과 규모마다 그 방식은 살짝 다르지만, 목표 지표를 설정하는 일은 매번 프로젝트 초반에 이루어집니다. 그리고 해당 지표와 더불어 우리가 설정한 목표를 회의나 문서를 통해 프로젝트 참여자와 공유합니다.
디자이너로서 이렇게 문제와 목표를 함께 논의하며 설정해가는 작업은 그다음 화면 디자인을 시작할 때 큰 영향을 미칩니다. 공감하고 있기 때문에 거기서 벗어나지 않는 디자인에 집중합니다. 결국 핵심 기능과 Flow 외 보조적인 것들은 과감히 쳐내게 되죠. 시간과 노력을 핵심 기능에 쏟다 보면 더 깊이 있게 고민하고 그만큼 세밀한 결과를 뽑을 수 있습니다.
앞서 말한 기획, 즉 디자인 시작 전까지의 단계를 체계적으로 정리하고자 ‘디자인 스펙’ 문서를 작성합니다. 이 문서는 디자이너가 이해하고 있는 문제, 목표, 측정 지표와 함께 어떤 생각으로 디자인을 할 것인지 기록하고 공유하는 목적으로 작성합니다. 문서로 적으면 지금까지 말로만 나눈 의견이나 생각만 하던 모호한 요소들을 구체화하고 프로젝트 참여자들과도 생각을 맞출 수 있습니다.
Step.3 목표에 따라 디자인하기
문서 작성 작업이 끝나면 빠르게 화면을 잡아봅니다. 본격적인 ‘디자인 단계’라고 볼 수 있는데요. 저희는 디자인 시스템이 어느 정도 갖춰진 상태라 와이어프레임을 따로 그리지 않고도 컴포넌트를 활용해 빠르게 화면을 그립니다. 수정하기도 매우 쉽죠. 여기서 포인트는 ‘빠르게’입니다. 역시 프로젝트마다 다르긴 하지만 어느 정도 규모 있는 프로젝트의 경우 처음부터 완벽한 화면을 그려낼 수는 없기 때문에 최대한 빠르게 PO에게 공유합니다. 혼자 화면을 디자인 하다보면 특정 UI나 Flow를 놓고 고민하다가 점점 그 부분에 빠져 큰 영역은 고려하지 못할 때가 있기 때문입니다. 이럴 때 계속 디자인하는 시간을 갖기보다 함께 일하는 PO나 동료 디자이너에게 공유하면 제가 보지 못한 부분으로 다시 눈을 돌릴 수 있습니다. 또 모두가 확신하기 어려운 부분이 있다면 실제 사용자를 대상으로 사용성 테스트를 진행해보자는 논의를 하기도 하죠.
도시 개선 작업에서도 메인에서 도시로 들어왔을 때 상품을 골라볼 수 있는 여러 탐색 방법을 제공하기로 했습니다. 그리고 시안을 여러개의 옵션으로 화면 구조가 완전 다를 정도로 큰 틀에서 잡았습니다. PO와 시안을 보며 설정한 목표에 맞춰 사용자에게 핵심 가치를 제공할 수 있는 안을 고민했습니다. 디자인이 나온 상태에서도 문제를 해결하는 최선의 안인지, 이렇게 개선했을 때 사용자가 더 다양한 상품을 볼 것인지, 목표 지표를 이룰 수 있을지 질문을 던져보았습니다. 기획한 탐색 방법 중 사용자가 인지하고 사용할 수 있을지 고민이 되는 필터 기능이 있었는데요. 결국, 사용성 테스트를 해보기로 했습니다.
빠르게 사용자를 모집하고 총 10명을 대상으로 테스트를 진행했습니다. 이때도 PO와 제가 테스트로 알고자 하는 것을 정하고 각각 질문을 구성했습니다. 그리고 질문에 대해 서로 피드백을 주고받으며 부족한 부분을 채웠습니다. 한 사람당 5명씩 약 이틀에 걸쳐 테스트 진행 후 느낀 점과 배운 점에 대해 나눴습니다. 인지할 수 있을지 고민되는 필터는 예상한 대로 인지하기 어렵다는 결론이 났습니다. 그 밖에도 사용자가 보인 행동을 통해 목표를 달성할 또 다른 포인트를 잡을 수 있었습니다.
이런 중간 점검을 통해 방향이 잡히면 세밀하게 UI디자인을 파고듭니다. 사용자가 오해하지 않고 쉽게 목표를 달성할 수 있고, 특별한 이유 없이 달라 헷갈리지 않는 UI에 집중합니다. 동시에 시각적인 완성도를 높여갑니다. 사실 이런 과정에서도 고민은 끊이지 않습니다. 어떤 아이콘을 써야 할지부터 레이아웃을 어떻게 잡아야 할지 등 말입니다. 대부분의 디자이너가 이런 고민에 공감하지 않을까 싶습니다. 또다시 마음속 고민이 끝나지 않으면 생각 중인 여러 안으로 시안을 잡게 됩니다. 그리고 프로젝트 참여자를 비롯해 디자이너들에게 의견을 요청합니다. 피드백을 반영해 디자인이 나오면 PO는 정책서를 작성하고 디자이너도 개발에 필요한 스펙을 정의합니다. 이 작업은 위키와 피그마를 이용합니다.
Step.4 목표를 달성했는지 확인하기
개발이 완료되고 실 서비스에 반영이 되면 어느 정도 시간이 지난 후 지표를 확인합니다. 특히 목표 지표를 달성했는지 봅니다. 도시 화면도 개선된 버전이 실 서비스에 반영되고 성과를 측정했습니다. 특히 새로 만들어진 화면의 지표도 확인할 수 있었습니다. 50%가량의 이탈이 있는 것을 보고, 새로 추가된 화면 자체가 꼭 필요하지 않은 단계였는지 확인하기 위해 추가적인 a/b 테스트를 진행했습니다. 글을 쓰는 지금 진행 중이라 액션 포인트를 정하지는 못했지만, 결과가 나오는 즉시 추가로 개선할 예정입니다.
이제 결과를 볼 예정인 도시 화면의 a/b 테스트 논의
사실 실 서비스 반영 후 회고하는 과정은 프로젝트마다 방식이 조금 다릅니다. 그러나 보통은 PO가 주도해서 보는 경우가 많습니다. 그러다보니 PO가 하지 못하면 목표 달성 확인 후 다음 액션을 이어가는 일이 어렵기도 했는데요. 이 부분은 글의 끝에서 좀 더 다뤄보겠습니다.
디자이너들과 최고의 프로덕트 논의하기
지금까지 기획과 디자인 단계에서 PO와 디자이너의 협업에 관해 이야기했다면, 이제는 디자이너 간의 피드백 문화에 대해 말해보고자 합니다. 이 피드백 문화 역시 프로젝트의 기획, 디자인 과정에 큰 영향을 주기 때문입니다.
마이리얼트립 디자인팀은 브랜드&마케팅 모듈과 프로덕트 모듈로 구성됩니다. 제가 속한 모듈이 프로덕트로, 프로덕트 디자이너들이 함께하고 있습니다. 프로덕트 디자이너 간의 피드백에서 가장 중요하게 여기는 기준은 ‘최고의 프로덕트를 만들고 있는가?’라는 질문에 의해 세워집니다. 저희가 논의한 ‘최고의 프로덕트’란 브랜딩을 잘 녹여낸 프로덕트, 사용자의 필요를 미리 알고 제안하는 프로덕트였습니다. 물론 이 밖에도 최고라고 부를 수 있는 중요한 조건들이 많습니다. 기본적으로 ‘사용자의 기본 목적과 Flow를 저해하지 않는가?’, ‘사용자에게 요구하는 행동이 많지 않은가?’ 등의 질문도 매번 하고 있습니다. 프로젝트마다 이런 기준으로 팀 내 피드백이 이루어지는 덕분에 프로젝트 안에 깊이 관여되어있기에 보기 어려운 관점도 깨달을 수 있습니다.
도시 개선 작업에서 탭별로 같은 기능을 가진 버튼들을 넣어야 했을때를 예시로 말씀 드리면, 첫 번째 탭에서는 해당 버튼이 다른 탭보다 많았고 그 밑으로 도시 개선의 핵심 영역들을 보여줘야 했는데요. 그러다 보니 상단 버튼들을 다른 탭과 다르게 배치했습니다. 이후 피드백으로 다 같은 기능과 성격인 버튼들인데 왜 첫 번째 탭만 다르냐는 질문이 나왔습니다. 질문을 듣고 다시 생각해보니 하단 영역을 많이 보여주면서도 다른 탭들과 일관성 있게 맞추는 방법도 충분히 있었습니다. 다만 제가 하단 영역을 많이 보여주면서 상단 버튼들도 모두 잘 보여주려는 두 가지 목적을 달성하려다 보니 오히려 일관성을 떨어뜨리고 있었던 것입니다. 탭별로 일관성 있는 디자인은 사용자가 해당 버튼을 사용하는 데 있어 헷갈리지 않게 하므로 중요한 부분이었습니다. 오히려 하단 영역을 많이 보여주는 것이 가장 중요했으므로 그 부분에만 집중하는 편이 도시 화면 전체 사용성을 더 낫게 만든다는 생각이 들었습니다.
이 피드백을 준 디자이너는 함께 프로젝트에 참여하지 않는 제 3자로서 다른 관점으로 의견을 줬기 때문에 제가 생각하지 못한 부분을 다르게 볼 수 있는 기회였습니다.
피드백을 주고받으며 논의하는 방식
피드백은 매일 아침 진행되는 짧은 미팅이나 피그마 화면에 코멘트를 다는 식으로 이루어집니다. 미팅은 저희 안에서 스크럼이라고 부르는데요. 주로 이 스크럼이 피드백 시간으로 활용됩니다. 각자 하는 일에 대해 자주 공유하기 위해 스크럼을 진행하기 때문에 이 시간을 활용하면 딱 좋습니다. 물론 스크럼 때마다 꼭 피드백을 주고받아야 하는 것은 아닙니다. 프로젝트에 대해 공유하면서 어떤 내용으로 기획이 되고 있는지 이야기하다 보면 자연스럽게 또 다른 관점의 의견을 받을 때가 있습니다. 또는 혼자 작업하다가 여러 시안을 두고 고민이 될 때 먼저 피드백을 요청하기도 합니다. 모두가 디자이너이기에 기획 내용이 시각적으로 표현되는 지점이나, 디자인 중인 화면의 전체 맥락에 대해서도 세밀하게 의견을 주고받습니다.
팀 내 피드백을 거치면 팀장님이 의견을 줄 때도 많은데요. 팀장님의 의견이기 때문에 꼭 적용해야 하지는 않습니다. 내가 이렇게 한 명확한 근거가 있고 그게 타당하다면 그 디자이너가 생각한 방향대로 갈 수 있습니다. 저희 팀의 주요한 기조 중 하나가 ‘좋은 의견이 이긴다.’이기 때문입니다.
도시 화면에서 탭에 아이콘을 사용한 디자인을 공유한 적이 있습니다. 아이콘과 탭 이름이 수직으로 위치한 형태가 어색한 것 같다는 피드백을 받았습니다. 제가 이렇게 한 이유는 처음 도시 화면을 들어와 사용자가 찾는 상품 단위를 탭으로 먼저 발견해야 한다고 생각해 강조하기 위함이었습니다. 코멘트로 달렸던 피드백에 저의 의견을 전달했습니다. 도시 화면은 해당 탭 디자인으로 가기로 했고 이후 다른 화면에서도 동일한 탭 디자인이 쓰였습니다.
이런 논의가 도움이 되나요?
사실 이런 디자인팀 내 논의의 장점은 무엇보다 데이터로는 측정할 수 없는 디자인의 가치에 관해 이야기해볼 수 있다는 점입니다. 전체 화면과 어울리면서도 항목별 구분이 확실히 되어야 하는 아이콘의 그래픽 스타일에 대한 결정부터 사용자의 진짜 문제로부터 목표가 논리적으로 짜였는지, 현재 하는 디자인이 해당 목표를 정말 이룰 수 있을지 등. 실 서비스 반영 후 데이터로 성과 달성 여부를 측정하는 일을 넘어 디자인이 사용자의 경험에 영향을 미치는 전반적인 부분에 대해 파고들도록 도와줍니다. 덕분에 프로젝트 결과로만 인사이트를 얻는 게 아닌, 하는 과정에서도 새로운 인사이트를 얻고 있습니다. ‘최고의 프로덕트’에 대한 기준도 높여가는 셈입니다.
기획과 디자인, 함께 더 잘하기
지금까지 마이리얼트립에서 프로덕트 디자이너로서 기획과 디자인하는 과정, 그 안에서 PO 및 디자이너와의 협업이 어떻게 이루어지는지 다뤘습니다. 현재의 과정도 좋지만, 여전히 부족한 점도 있습니다. 특히 프로젝트를 회고하고 다음 개선을 진행하는 단계가 그렇습니다. 위에서 잠시 언급했지만, 아직까지는 회고 단계가 시스템적으로 잡혀있지 않습니다. 프로젝트를 끝냈다고 하더라도 해당 개선이 정말 문제를 해결했는지, 목표를 이루고 성과가 났는지 확인하는 일은 중요합니다. 만약 예상만큼 성과가 나지 않았다면 문제를 해결하지 못한 이유에 대해 따져봐야 합니다. 혹은 문제를 제대로 정의한 것인지 봐야 합니다. 해결 방법이 최선이 아니었을 수도 있습니다.
회고를 통해 나온 개선점으로 프로젝트의 목표에 더 큰 임팩트를 가지고 올 수 있습니다. 프로젝트 과정 자체에서도 문제를 발견하고 더 나은 방향으로 다음 프로젝트를 진행하게 만듭니다.
최근 회고 단계를 프로젝트마다 꼭 하고 다음 단계로 넘어갈 수 있도록 PO들과 이야기한 적이 있습니다. 지금까지 PO의 의지로만 회고하고 넘어갔다면, 이제는 프로젝트에서 회고의 필요성을 느끼는 누구라도 진행할 수 있게 말이죠. 프로덕트 디자인팀 안에서도 회고의 필요성을 이야기한 만큼 이번에 각자가 진행하는 프로젝트에서는 실 서비스 반영 후 꼭 회고까지 추진하고자 합니다. 이 외에도 회고 이후 단계에 대한 각자의 고민을 나누고 어떻게 실제 프로젝트 과정에 녹일 수 있을지 차츰 이야기해가려고 합니다.
이 글을 쓰는 현재는 기획의 첫 시작점인 문제를 정의하고 목표 정하는 일을 집중해서 하고 있습니다. 프로젝트를 시작할 때 쉽게 문제를 찾을 수 있겠지만 그게 정말 사용자의 문제인지, 핵심적인 문제인지는 또 고민해봐야 할 지점입니다. 처음부터 중요하게 여긴 부분이기도 하고, 올바른 시작점이 결국 성과와 회고까지 영향을 미치기 때문에 이전보다 더 공을 들이고 있습니다. 이런 과정에 PO와 더 같은 방향을 바라볼 수 있도록, 디자이너 간에 새로운 관점을 던지며 기준을 고도화해갈 수 있도록 오늘도 활발한 논의가 진행 중입니다. 그리고 더 잘하기 위한 변화와 멋진 프로덕트를 만들어갈 분들을 기다리고 있습니다 🙂
함께 기획하고 디자인할 프로덕트 디자이너분들, 어서 오세요!
디자이너 채용 공고 바로가기
출처 : https://medium.com/myrealtrip-product [마이리얼트립 블로그]