배경
내가 만든 앱인데도 도무지 앱에 손이 가질 않았다. QA를 할 때나 앱을 열어봤다. 알림이 있는데도 그랬다. 나는 원래 뉴니커였고, 매일 뉴닉 레터를 읽는 낙으로 출근했었다. 그런데 입사하고 몇개월이 지나자 예전 같은 마음으로 콘텐츠를 읽기가 어려웠다. 일이 되니까 예전처럼 마냥 좋지 않았다는 말은 하기 쉬운 말이다. 하지만 나도 쓰지 않을 제품을 다른 사람이 쓰기를 바랄 수는 없었다. 무언가 대대적으로 제품을 바꿔야 겠다는 생각이 들었다. 당시 뉴닉의 제품 팀은 아직 만드는 속도가 느렸다. 검증되지 않은 기획으로 개발에 돌입하기엔 리스크가 컸다. 만들지 않고도 검증할 수 있는 방법이 필요했다.
디자인 스프린트
디자인 스프린트는 개발 없이 프로토타입을 통해 유저 반응을 검증할 수 있는 프로세스다. 정석적인 방법은 이런 자료들을 참고하면 알 수 있다.
- 책 <스프린트>
- 스포카의 디자인 스프린트 툴킷
- 유튜브 Design Sprint Explained in 1 Minute (영어)
- 유튜브 Design Sprint? 구글벤처스의 디자인 스프린트 8분 안에 익히기
디자인 스프린트는 6-8명 정도의 구성원과 5일을 꽉 채워서 진행된다. 뉴닉의 상황을 고려해 스프린트를 조금 조정해서 진행했다. 뉴닉의 제품 팀은 21년 6월에야 팀빌딩이 되었다. 그 전에는 제품팀 없이 일했다. 그래서 뉴닉의 구성원들은 제품 팀과 함께 일하는 것이나 제품 중심적으로 생각하는 것이 익숙하지 않았다. 그렇게 동떨어져 제품 팀이 제품을 만들어가다 보니까 팀의 대부분을 차지하는 다른 직군이 애플리케이션에 관심을 갖기가 어렵다는 문제도 있었다. 그래서 최대한 많은 사람들이 참여하되 리소스를 낭비하지 않는 방향으로 디자인 스프린트를 간소화 하여 진행했다.
뉴닉의 디자인 스프린트
디자인 스프린트를 시작하기 전 스프린트의 방향을 잡기 위해 사용자 인터뷰를 진행했다. 사용자 인터뷰와 간단한 UT를 통해 리텐션을 높이기 위해 해결할 수 있는 문제 리스트를 만들고 그 중 가장 중요하다고 생각한 문제를 위주로 정리했다.
첫째날에 진행하는 액티비티는 거의 그대로 진행했다. 앞으로 의사결정을 함께 내려야 하기 때문에 장기적으로 어떤 목표를 가지고 있는지 맥락을 공유하는 일은 중요하다고 판단했다. 또, 유저 플로우 지도를 작성함으로써 제품에 대한 이해도도 맞출 수 있었다. 제품을 만들 때 가장 중요한 것은 문제 정의라고들 한다. 이런 앞단계를 함께 하는 것이 앞으로 '내가 변화를 만들 수 있다'고 믿을 수 있게 만들어 동기부여에 도움이 된다.
둘째날과 셋째날에 나누어 진행하는 액티비티는 합쳐서 컴팩트하게(빡세게) 진행했다. 오전에 아이데이션은 시간을 제한해두고 진행하기 때문에 재미있게 진행할 수 있다. 오후에 미술관처럼 나온 시안들을 전시한 다음에 논의를 이어가는 시간부터 조금 어렵다. 이미 오전에 2-3시간에 걸쳐 아이데이션을 마친 상태이기 때문. 그래서 아이데이션과 이제 미술관처럼 나온 시안들을 전시해두고 논의를 이어가는 부분 부터가 조금 어려운데 그 전에 점심 시간을 충분하게 갖고 간식도 잘 준비해 두는 것이 팁이라면 팁이다.
대략적인 아이디어와 유저스토리를 합의한 후의 프로토타이핑은 모두가 참여하지는 않고, 프로덕트 디자이너, 에디터 1명과 PM인 나 이렇게 세 명이서 진행했고 그렇게 진행하는 동안 다른 참가자들이 모집한 사용자 대상으로 인터뷰를 진행하면서 디자인 개선점을 도출했다.
회고
좋았던 점
1. 소프트웨어 제품만으로 경험이 완성되지 않는 제품들이 있다. 그런 제품을 만들 때는 그 제품을 완성시키는 직군들 (MD, 콘텐츠 에디터 등)과의 협업이 반드시 필요한데, 디자인 스프린트 프로세스를 통해 제품에 대한 배경지식이 없는 사람들도 제품을 만드는 과정에 쉽게 참여할 수 있다.
2. 문제 해결이 막막할 때, 함께 모여 각자 아이데이션을 하는 것은 가장 효과적인 방법이다. 문제 해결은 PM이 아닌 누구라도 제안할 수 있고, 갇혀서 보지 못하는 생각들을 쉽게 만들어낼 수 있다.
3. 제품 팀이 원래 없었던 조직에서 제품 팀과 콘텐츠 팀이 어떻게 협업해야 할지 고민을 시작할 수 있었다. 콘텐츠 에디터들은 이렇게 생각을 하는구나, 제품 팀은 이런 식으로 결정을 하는 구나 하는 것을 서로 지켜보고 피드백하면서 이해할 수 있는 좋은 기회가 되었다.
2년이 지난 지금 돌아보면,
처음에 디자인 스프린트를 했을 때는 이벤트성으로 가끔 이렇게 문제를 정의하고 여러 명의 아이디어를 받고 솔루션을 확정하는 방식으로 진행했다. 같이 일하지 않는 사람들도 있다보니 협의를 해야할 내용도 많았고 사전에 준비도 많이 필요했다.
그런데 가장 최근에 일했던 방식을 생각해보면 이걸 자연스럽게 스프린트 운영에 녹여서 진행했다. 문제 정의한 과정과 인터뷰 또는 데이터 분석 결과 문제를 왜 이렇게 정의했는지부터 공유하면서 솔루션 아이데이션도 혼자하지 않았다. 이건 최근에 읽었던 <Continuous Discovery Habits> 의 영향이 큰데 그렇게 한 결과 문제로 정의한 것은 웬만하면 항상 해결할 수 있는 방향으로 솔루션을 만들어낼 수 있었다.
이렇게 일하지 않는 환경에서 모두를 설득해서 이런 방식으로 일하게 세팅하는 것은 사실 조금 어려운 일이다. 퍼블리에서는 PM에게 자유도가 많이 주어지기 때문에 이런 일들이 가능하기도 했는데, 만약 전체 프로세스를 변경하는데 품이 든다면 디자인 스프린트 처럼 이벤트 성으로 천천히 도입해보는 것도 좋은 방법이 될 것이다.
디자인 스프린트에 관심이 있다면,
이틀 만에 압축적으로 디자인 스프린트를 경험할 수 있는 노트폴리오 디자인 스프린트 워크숍에 참여해 주세요! 비즈니스 임팩트를 만들어내는 솔루션을 찾는 방법을 확실하게 알려드릴게요.
루나님의 창작활동을 응원하고 싶으세요?
