2017. 11. 23. 07:50ㆍpxd talks
지난 11월 2일, 토스(Toss)의 프로덕트 디자이너 남영철 님이 “Fintech / Start-up / Toss”라는 주제로 강연을 해주셨습니다. 남영철 님은 포털 회사와 금융 회사에서 UX 디자이너로 근무하다가 토스로 이직하면서 프로덕트 디자이너로 근무하고 있습니다.
'UX 디자이너와 프로덕트 디자이너는 어떻게 다른지', '프로덕트 디자이너는 조직 내에서 어떤 역할과 책임을 가지는지’를 시작으로 강연이 진행되었습니다. 토스의 디자인 프로세스와 함께 토스의 조직문화와 그런 조직문화를 가지게 된 이유에 대해 들을 수 있었습니다.
Toss의 팀 구조
토스는 사일로(Silo) 단위의 조직 구조로 되어 있습니다. 일반적으로는 디자인 팀, 개발팀 등 직군으로 팀을 구성하는데, 토스는 사일로라는 팀 단위의 조직에 제품을 만들 수 있는 모든 직군을 포함하고 있습니다. 사일로는 내부적으로 미니 스타트업이라고 불리며 한 사일로 당 하나의 서비스를 담당한다고 합니다. 사일로의 장인 프로덕트 오너(Product Owner)는 담당한 서비스를 책임집니다.
사일로 외에 챕터(Chapter)라는 단위를 가지고 있는데, 챕터는 각 사일로에 속한 동일 직군 사람들의 그룹입니다. 챕터 내에서는 같은 직군이지만 상하관계가 없습니다. UI 컴포넌트, 디자인 피드백 등 사일로 간의 원활한 공유를 위한 조직입니다. 토스가 일반적인 회사와 다른 구조로 운영되는 이유는 조직을 더 효율적으로 이용하기 위함입니다.
Product Designer
최근 스타트업과 실리콘 밸리의 IT 회사에서 프로덕트 디자이너(Product Designer)라는 타이틀을 자주 접할 수 있습니다. 토스 팀에서의 프로덕트 디자이너는 UX/UI 디자이너보다 역할과 책임이 확장된 디자이너라고 생각이 들었습니다. 프로덕트 디자이너의 역할과 산출물은 다음과 같습니다.
| 역할 | 산출물 |
|
|
토스의 프로덕트 디자이너의 목표는 'UI/UX 산출물 완성'에 그치지 않고 제품을 통해 '비즈니스 목표'를 달성하는 데까지 연결됩니다. 이 목표를 달성하기 위해 다음과 같은 제품 개발 프로세스 안에서 팀원들과 협업합니다.
제품 개발 Process
토스의 제품개발 프로세스는 문제 정의로 시작하여 개발과 출시 후 분석으로 이어집니다. 분석을 통해 새로운 문제를 발견하고 해결을 위한 시도를 반복하면서 제품을 발전시켜 나갑니다.
문제 정의 → 해결책 논의 → 프로토타이핑 → 개발 요구사항 작성 → UI 디자인 & 가이드 →
개발진행 → 분석 계획 → Test Case 작성 → 출시 & 분석 → 문제 정의 …
문제 정의
"팀에서 제일 중요한 목표는 XXX인데 그게 안 되고 있는 이유는 OOO 때문이야.
이 지표를 봐. 이걸 개선해야 효과가 크다니까?”
프로세스는 해결할 문제를 정의하는 것으로부터 시작됩니다. 문제 정의가 잘못되면 이후의 프로세스가 의미가 없어지기 때문에 문제를 정의하는 것이 매우 중요합니다. 토스의 디자인 문제 정의 원칙은 비즈니스 목표와 연결된 문제를 해결해야 할 문제로 정의하는 것입니다. 또한, 문제를 정의할 때는 데이터에 기반을 둔 근거를 바탕으로 정합니다.
해결책 논의
“OOO의 전환율이 떨어진 것은 XX 때문일 거야, ◻︎◻︎를 △△하면 ★★결과가 나오겠네"
문제 정의 이후에 화이트보드에 가설에 기반을 둔 대략적인 해결책을 그려가며 논의합니다. 가설에 기반을 둔 해결책을 논의하는 이유는 이후에 문제 해결이 성공했는지 혹은 실패했는지 알 수 있게 하기 위함입니다. 가설을 검증하는 가장 작은 변화를 해결책으로 채택합니다. 다시 말해, 문제라고 생각한 것이 문제가 맞는지 확인할 수 있는 가설을 해결책으로 선택하는 것입니다.
프로토타이핑
프로토타이핑으로 사용자 입장에서 본 제품을 정의합니다. 해결책 논의 과정에서 채택된 해결책을 최대한 빠르게 프로토타입으로 만들어 피드백을 받습니다.
개발 요구사항 작성
개발 요구사항으로 개발자 입장에서 본 제품을 정의합니다. 프로토타이핑한 내용을 디테일한 문서로 전달합니다. 가능한 문서를 최대한 줄이려고 노력하는 토스에서도 개발 요구사항 문서는 최대한 자세히 작성합니다. 자세히 작성된 문서는 커뮤니케이션을 원활하게 합니다.
UI Design & 가이드
토스에는 효율성과 개발 속도를 위한 UI 디자인 원칙이 있습니다. OS 내장 컴포넌트를 최대한 활용하며 커스텀 컴포먼트 사용을 지양합니다. 이전에 제작한 컴포넌트를 재사용합니다. 또한, 명확한 레이블링을 작성하는데 많은 시간을 할애합니다.
개발 진행
협업 툴을 이용해 개발자들과 협업하며 개발을 진행합니다.
분석 계획 → 수집 계획
데이터 분석가와 프로덕트 오너와 함께 출시 후 분석 계획과 데이터 수집 계획을 세웁니다. 보드에 모든 화면과 플로우를 다 볼 수 있도록 구성하고 프레젠테이션을 합니다. 프로덕트 디자이너가 플로우를 설계했기 때문에 이를 설명합니다. 이 과정에서 프로덕트 오너가 알아야 할 것과 목적 등을 설명하고 데이터 분석가에게 걱정되는 부분, 궁금한 점 등의 요구사항을 전달합니다.
Test Case 작성
사일로 내 구성원들이 함께 작성합니다.
출시 및 분석
분석 단계에서는 “결과를 보여주는 지표”보다는 “다음 행동을 일으키는 지표”를 추적합니다. '결과 지표'는 송금 액수, 누적 다운로드 수, 송금자 수 등과 같이 어떤 노력의 '결과'를 나타내는 것입니다. 이러한 지표는 '팀이 다음에 무엇을 해야 할지'에 대한 인사이트를 주지 않기 때문에 크게 신경 쓰지 않습니다. 반면, Funnel 분석이나 최종 전환율과 같이 '다음에 무슨 일을 해야 할지' 말해주는 지표가 있습니다. 분석에서는 주로 이러한 지표에 집중하고, 여기서 발견한 문제로 다음 개발 프로세스를 시작합니다.
토스에서 이런 프로세스를 통해 디자인을 하는 이유는 스타트업이기 때문입니다. 남영철님은 스타트업이 망하는 이유를 "시장이 원하는 제품을 찾기 전에 돈이 다 떨어져서”라고 했습니다. 스타트업에서 프로젝트는 인생의 역작을 만드는 것이 아니라 주어진 시간 내에 시장에서 통하는 제품을 찾는 과정이기 때문에 무엇보다 ‘속도’의 중요성을 강조했습니다.
How to survive : Speed
빠르게 시장이 원하는 제품을 출시해야 하는 스타트업에게 속도는 생명과도 같습니다. 토스의 조직 구성, 업무 문화, 프로세스는 ‘속도’에 초점이 맞춰져 있습니다. 다음 세 가지는 속도를 위한 중요한 요소입니다.
Focus + 업무 습관 + 팀 구조
Focus는 정말 중요한 일에만 집중하고 필요 없는 일을 하지 않기 위한 노력입니다. 이를 위해 우선순위 선정이 가장 중요한데, 토스 팀은 ‘비즈니스 기회’와 ‘사용자의 행동’이 교차하는 영역에 집중합니다. '사용자의 행동'을 파악하기 위해 다양한 데이터 분석을 수행하고 있습니다.
업무 습관 역시 속도와 관련이 있습니다. 내부 보고를 위한 ppt 등 쓸데없는 문서를 작성하지 않습니다. 하지만 개발 요구사항은 필수적으로 작성합니다. 명세서 작성을 통해 가장 먼저 정해져야 할 것을 빨리 발견할 수 있고, 숨겨진 문제를 찾을 수 있습니다. 또한, 명세서로 회의를 줄일 수 있고 따라서 작업에 몰입할 시간을 늘릴 수 있습니다.
팀 구조도 더 높은 속도로 움직이기 위한 고민의 결과입니다. 사일로 조직 구조를 통해 유관부서의 협조나 상사의 결정을 기다리는 시간을 제거하고, 대부분의 의사 결정을 사일로 내에서 처리하여 빠르게 실행할 수 있도록 합니다.
Fintech
강연의 마지막 주제로 핀테크(Fintech)에 대해 들을 수 있었습니다. 금융을 온라인으로 접근하는 시간이 늘어나고 있으나 기존 제품들의 경험이 좋지 않았고, 이 문제에 IT 기반의 기업과 인력이 접근하면서 '핀테크'가 시작되었다고 합니다.
IT 회사는 기존 금융회사보다 더 높은 UX 기준을 가지고 있으면서 빠르고 효율적인 업무 문화와 프로세스를 가지고 있기 때문에 기존 금융 회사를 위협하고 있다고 하였습니다. 또한, 규제, 자본, 사용자의 습관 등의 금융권으로 진입하기 위한 장벽이 존재하지만, 이 장벽은 점차 낮아지거나 없어지고 있어 앞으로 핀테크 회사들이 제공하는 높은 수준의 경험이 '새로운 표준'이 될 것으로 예상했습니다.
마치며
이번 강연을 통해 스타트업의 속도감을 느낄 수 있었습니다. 데이터를 적극적으로 활용하여 가설을 세우고 검증하는 Lean & Agile 방식의 업무를 간접적으로 경험한 것 같았습니다. 속도와 효율을 위해 조직 구조와 문화부터 다르게 한 점이 인상 깊었습니다. 마지막으로, 프로덕트 디자이너의 역할을 들으면서 앞으로 UX 디자이너의 방향이 어떻게 될 것인지 생각해 볼 수 있는 시간이었습니다.