Tanzu Labs' Design Process
프로덕트 디자이너 관점에서 본 탄주랩스의 제품 개발 프로세스
VMware 탄주랩스에서(Formerly Pivotal Labs) 1년을 보내고, 프로덕트 디자이너 관점에서 정리해본 제품개발 프로세스.
경험하고 난뒤 보이는 것들
랩스 내부에는 방대한 자료의 Labs Practice 문서들이 아카이빙되어있다. 서울 랩스에 조인하게 된 이후로 매니저님과 팀원분들의 도움으로 온보딩을 진행하면서 다양한 툴을 통해 우리가 실천하고 있는 방법론과 프랙티스(Practice-한국어로 어떻게 표현하면 좋을까?)를 접할수 있었지만 초기에는 머리로는 이해하면서도 아직 내것이라는 느낌이 들지 않았었다. 모르는게 있으면 질문하라고 하는데, 내가 뭘 모르는지도 잘 모르는 상황. 짧지 않은 디자인 경력에 비해 랩스 프랙티셔너로써 공부해야 할것 들이 제법 많아서 처음엔 다시 신입이 된 느낌이었는데, 1년이 지난 지금은 실무를 통해 많이 체득하게 된것 같다. 역시 몸소 체험하며 얻는 경험의 가치란.
탄주랩스의 개발 방법론
탄주랩스에서는 XP, Agile, User Centerd Design, Lean Startup 방법론에 기반하여 통상적으로 알려진 더블 다이아몬드 디자인 프로세스를 제품 개발에 사용하고있다 (탄주랩스에서 사용하는 명칭은 Discovery& Framing). MVP 개발을 위해 PM 1명, 디자이너 1명, 개발자 2명으로 최소한의 멤버구성을 하고 우리는 이 구성을 Balanced team이라고 부르며 프로젝트 시작부터 사용자 중심으로 일하며 적극적인 소통과 협업을 중시한다.
Discovery를 통해 문제를 정의하고 Framing을 통해 최소단위제품 (MVP - Minimum Viable Product) 개발요건에 들어갈 솔루션을 우선순위를 통해 정한다. MVP는 16주안에 릴리즈하는 것을 목표로 하며 이중D&F는 약 3-4주정도의 기간동안 진행되며 PM과 디자이너가 주 진행자(Facilitator)가 된다. D&F가 끝나면 실제 개발에 들어가는데 이터레이션을 통해 제품의 완성도를 차근차근 높여나간다.
Discovery & Framing (From Labs' Miro Board)제품 개발 프로세스의 도식화 버전과 사용되는 프랙티스들. 탄주랩스에서 사용하는 프랙티스들은 다양한데, 프로덕트 디자이너입장에서 진행해온 프랙티스 위주로 실무에서 주로 사용했던 것 위주로 정리해보았다.
Discovery
문제 발견 (Problem discovery) - 리서치 단계
우리가 소프트웨어를 통해 해결하고자 하는 문제는 무엇인가?
가설생성 (Assumption) - 문제 해결을 위한 아이디어는 가설을 기반으로 시작된다. (ex- 핸드폰 번호이동 프로세스를 00을 통해 간단하게 만들어준다면 가입자들이 늘어날 것이다) 가설은 우리가 사실이라고 믿지만 사실이나 증거가 있는것이 아닌 추측에 기반한 것이다. 이러한 가설을 설정하고 리서치를 통해 초기에 검증해 나가면서 비지니스 리스크를 줄여나간다.
페르소나 구축 (Proto-Persona) - MVP 개발을 위한 타겟 유저를 정하고 그에 맞는 페르소나를 생성한다. 페르소나는 사용자 중심 디자인 (User Centered Design)프로세스의 가장 중요한 부분이다. 가상의 사용자를 생성함으로써 사용자 중심의 스토리와 시나리오를 작성해 나갈수 있고, 문제 해결의 목적이 변질되지 않도록 돕는다(몇몇 회사에서는 의사결정권자의 입맛에 맞춘 제품을 개발하고 있는 모습을 심심치 않게 발견할수 있다). 초기 설정한 페르소나의 needs & goals 등은 탐색 인터뷰를 통해 검증해가면서 점진적으로 변경될수 있다.
�팀원 모두 같이 진행하는 페르소나 시각화 작업은 사용자에게 몰입할수 있는 중요하고 즐거운 액티비티이다.
탐색 인터뷰 (Exploratory Interview or Generative Interview) - 우리가 생성한 가설과 프로토 페르소나를 검증하기 위한 사용자 인터뷰 단계. 타겟 페르소나와 겹치는 연령대의 사용자를 리크루팅하여 방향성을 확인한다. 대면인터뷰 보다는 대부분 줌 인터뷰를 통해 진행했다.
�사용자 인터뷰시 질문지를 작성하여 진행하기보다는, 팀원들과 워크샵을 통하여 검증해 보고싶은 방향성을 카테고라이징한 토픽맵(Topic map)를 만들어 인터뷰에 활용한다.
인사이트 정리 (Insight Prioritization) - 인터뷰를 기반으로 발견한 인사이트를 정리하는 과정. 인터뷰 Synthesis 와 동시에 진행한다.
우선순위 결정 (Problem Prioritization) - 해결해야 할 문제를 하나로 좁혀가기
우리가 설정한 가설을 검증한뒤 가장 먼저 해결해야하는 문제를 우선 순위를 통해 정한다. 우선순위를 정하기 위해 사용하는 툴은 아래와 같다.
2x2 Prioritization - 투바이투 차트를 이용하여 우선순위를 결정하는 방법은 다양한 워크샵에서 사용된다. 팀원이 전부 참여해 해결해야하는 문제를 덤핑하고, 우선적으로 해결해야 하는 우선 순위를 함께 결정함으로써 최우선 되어야 할 문제(또는 기능)을 정하는것을 물론 팀원 모두가 공통의 이해를 갖을수 있도록 도와준다.
Affinity Diagram - 친화도 다이어그램(어피니티 다이어그램)은 수집된 데이터를 그룹핑하는 방법이다. 어피니티 다이어그램은 아이디어나 솔루션등 다양한 내용이 덤핑되는 워크샵을 진행할시 진행자로써 데이터 정리를 하며 진행하며 기본적으로 사용한다. 각 정보의 연관성을 찾아 카테고리화 하고 규칙을 발견함으로써 흩어져있는 문제를 통합하여 보기좋게 정리하고 인사이트를 얻기 쉽도록 돕는다.
Framing
Finding Solution - 솔루션을 정의 하는 단계
솔루션 브레인 스토밍 (Solution Brainstorming or Feature Ideation) - 해결해야 할 문제가 하나로 정의 된다음 어떠한 방법으로 그 문제를 해결이 가능할지 아이디어를 덤핑해 보는 시간. 만들고자 하는 프로덕트의 단편적인 기능을 덤핑해도 좋고 추후 2x2, 보팅을 통해 먼저 구축할 기능들을 정리해 볼수 있다.
가치제안 설계 (Value Proposition) - Value Proposition Canvas로 작성해 보는 방법도 있지만, 페르소나를 적용하여 우리가 만드려는 제품이 사용자이 어떤 문제를 해결할 수 있는지 한줄로 작성해보고 (ex- With [ 프로덕트 ] 페르소나 Can [ 해결할수 있는것 ]) 그 상황을 시각화 해본다. 앞서 생각해본 기능 or 솔루션을 통해 사용자에게 어떠한 가치를 줄 수 있는지 정리해 볼수있다.
시나리오 라이팅 (Scenario Writing) - 페르소나 입장에서 우리 서비스에서 진입과정과 서비스 사용 방식을 머릿속에 그려보며 시나리오를 작성해 나가는 방법. 사용자 입장에서 가상의 스토리텔링을 작성해 보며 좀더 사용자 입장에 몰입하며 서비스의 user journey를 상상해 볼수 있다.
디자인 스튜디오 (Design Studio) - 앞서 진행한 브레인스토밍과 시나리오 라이팅을 통해 예상되는 서비스의 화면을 같이 그려보는 작업. 디자인 배경지식이 없더라도 모두가 참여하여 생각하는 서비스의 화면을 빠르게 그려보고 공유하는 시간이다. 이 워크샵에서 나온 아이디어를 디자이너는 추후 와이어프레이밍 작업에 참고 할 수 있다. Crazy 8 이라는 방법을 통해 a4용지를 8분면으로 접어 한칸에 한화면씩 1분의 타임바운드를 정하여 개인적으로 생각하는 화면UI를 빠르게 그려본다. 1분의 시간제한을 두는것은 너무 깊게 생각하는것보다 무의식적으로 떠오르는 아이디어를 빠르게 캐치할수 있도록 돕고, 8개의 그림을 그려보면서 점진적으로 이전에 그린것과 다른 새로운 아이디어를 끄집어 내도록 돕는다.
와이어프레이밍 (Wire Framing) - 디자이너의 페어링 작업 시작. 앞서 진행했던 워크샵에서 우선적으로 고려할 제품의 기능들과 사용자 시나리오, 디자인스튜디오를 통해 팀원 모두 제품개발의 방향성 과 제품에 대한 이해가 동일 선상에 있다. 디자이너는 이러한 정보를 토대로 와이어프레임을 그리기 시작한다 (Feat. Figma) 제품의 시각적인 완성도는 차차 높여 나가는것이 중요하다.
�디자이너가 와이어프레임을 그리는동안 개발자는 테크니컬 디스커버리, PM은 스토리 작성을 시작한다.
밸리데이션 인터뷰 (Validation Interview - User Testing) - 피그마로 와이어프레임 프로토타이핑을 제작한뒤 사용성과 기능을 검증하는 첫번째 인터뷰를 진행한다. 비대면일 때는 줌을 통해 피그마로 인터뷰어가 인터뷰이에게 질문을 던지고 직접 조작하는 방식으로 테스팅을 진행하고, 동시 모니터링을 통해 노트테이커들이 인터뷰로 얻은 정보를 스티키에 나열하고 어피니티 다이어그램으로 정리한뒤 추후 인사이트를 뽑아 낸다.
서비스 블루프린트 (Service Blueprint) - User Journey를 작성해보고 사용자가 프론트에서 어떤 인터랙션이 일으키고 그 기능을 작동시키기 위해 백단에서는 어떤 기능을 어떠한 방식으로 데이터를 주고받는지 정리해보고 확인하는 단계.
�와이어 프레임을 완성한 뒤 서비스 블루 프린트를 진행하면 화면의 워크플로와 인터랙션을 확인하며 개발에 필요한 것을 좀 더 명확하게 들여다볼 수 있다.
D&F가 중요한 이유
4주간의 D&F가 끝나면 프로그램 개발 시작을 알리는 Inception meeting을 시작하고 실제 개발에 착수하게 되며 이터레이션을 통해 제품의 살을 붙여 나간다. 디자이너 입장에서 피그마로 화면 그리기 시작할때가 제일 재미있는 반면, D&F프로세스를 통해 팀원 및 사용자들과 커뮤니케이션을 끊임없이 하면서 인사이트와 솔루션을 뽑아내는 일은 실제 화면을 디자인하는 일보다는 좀 더 피곤한 일이긴하다. 하지만 이러한 과정을 통해 팀원 모두가 제품에 관한 같은 이해도를 갖게된다는 큰 장점이 있으며 실제 개발(디자인)에 착수한 뒤에도 사용자 인터뷰와 테스트 그리고 리서치를 통해 지속해서 제품력을 검증해 나가기에 누가 시켜서가 아니라 제품에 대한 오너십이 자연스럽게 생겨난다는것도 또 하나의 장점이 아닐까.
