디자인 스프린트가 진짜 강력해지는 순간
디자인 스프린트란?
디자인 스프린트는 짧은 시간 안에 문제를 정의하고, 아이디어를 도출하고 서로 공유된 이해와 공유된 결정을 하게 도와주는 협업 방법론이다.
우리 팀은 중요한 이슈나 손에 안 잡히는 이슈를 해결해야 할 때 디자인 스프린트를 진행한다.
내가 생각하는 디자인 스프린트가 가장 강력해지는 순간은?
문제 정의가 흐릿하고, 팀의 관점이 어긋나고, 결정이 미뤄지고 있을 때, 여러 사람의 일을 바꿔야 할 때라고 생각한다.
오늘은 디자인 스프린트로 문제 해결을 어떻게 했는지 경험을 공유해보려 한다.
1. 문제의 시작: 불명확한 스펙, 불균형한 품질
우리는 사용자를 처음부터 나누지 않고 ‘누구나 사용할 수 있는 서비스’를 만들어왔다.
하지만 시간이 지날수록 제품과 서비스 품질이 흔들리기 시작했다.
제품의 스펙이 명확하게 정의되어 있지 않았고, 운영 방식도 팀마다 다르며, 제품에서는 어떤 고객에게는 좋은 UX 어떤 고객에게는 불친절한 UX였다.
“제품에는 표시되지 않아서, 고객이 문의하면 저희가 내부적으로 알고 있는 내용으로 안내해요.”
운영팀과 대화를 하다가 저 말을 듣고 머리를 한 대 맞은 느낌이었다. 중요한 정보가 제품에는 없고, 고객이 물어봐야만 대답을 해주다니. 제품이 자기 자신을 설명하지 못하고 있다는 뜻이었다.
우리는 이 문제를 제품으로 풀어보자고 생각했다.
2. 그래서 우리는 디자인 스프린트를 했다
이 문제를 풀기 위해 디자인 스프린트를 선택했다. 우리는 3~4일간의 미니 스프린트를 열었고, 운영팀, 개발자, 디자이너, 제품팀이 함께 참여했다.(툴은 Miro를 활용해 의견을 시각화하고 정리했다)
이번 스프린트의 주제는 명확했다.
“일반 사용자와 비즈니스 사용자를 명확히 나누고, 각 사용자에 맞는 제품/서비스 흐름을 새로 설계하자.”
3. 스프린트 전에 했던 일들
스프린트를 본격적으로 시작하기 전, 우리는 두 가지 준비를 먼저 했다.
1) 운영자 인터뷰
가장 먼저 한 일은 운영자 인터뷰였다. 실제 사용자들과 가장 가까운 곳에서 일하고 있는 운영자들이 지금 사용자들을 어떻게 분류하고 응대하고 있는지(노하우?)를 하나하나 물었다.
그 과정을 통해 다음과 같은 것들을 확인할 수 있었다
운영자들은 이미 사용자 유형을 서비스로 구분해 응대하고 있었지만 그 기준은 일관되지 않았고 많은 정보가 운영자들만 알고 있는 상태로, 제품 안에서는 보이지 않았다
운영자의 노하우를 좀 빌려 사용자를 어떻게 나눠야 하는지 감을 좀 잡았다.
2) 개발자 인터뷰
다음으로 실제 구현을 맡을 개발자들과 함께 지금 구조에서 사용자 구분을 하면 어떤 기술적 이슈가 있는지, 이걸 만들기 위해 어떤 조건과 정보가 필요한지를 정리했다.
이 과정을 통해 자연스럽게 결정이 필요한 부분이 드러났다. 예를 들어 사용자 유형을 나누는 기준, 기존 사용자 전환 처리 방식 등. 우리는 그 상태 그대로 운영자와 리더들을 초대해 함께 판단하고 설계 방향을 정할 수 있는 구조로 스프린트를 설계했다.
4. 스프린트 구성
우리는 디자인 스프린트를 다음과 같은 흐름으로 진행했다.
1) 문제 정리
Miro에서 사용자 여정을 그려보며 일반 사용자와 비즈니스 사용자가 서비스 안에서 어떻게 흘러가는지 시각화했다. 각 흐름에서 어떤 정보가 부족하고, 어떤 혼란이 발생하는지를 구체적으로 붙였다.
2) 아이디어 도출
사용자 유형별로 필요한 정보, 화면, 기능을 모두 쏟아냈다. 이때는 정답보다 가능성을 넓히는 데 집중했다. ‘이건 꼭 보여줘야 해’, ‘이런 플로우는 오해를 줄 수 있어’ 같은 의견이 오갔다.
3) 의사결정
정리된 안들을 토대로 기존 사용자를 어떻게 전환시킬지, 회원가입/로그인 UX를 가다듬고 온보딩을 만들어 설명을 어떻게 할지 결정했다. 운영, 제품, 개발이 모두 참여한 상태에서 실질적인 판단이 이뤄졌다.
5. 디자인 스프린트 결과
우리는 그렇게 2주 만에 사용자를 구분하고 제품으로 설명하는 UX를 만들어냈다.
디자인 스프린트 이후, 팀 안에서 명확하게 달라진 것들이 있었다.
1) 제품이 사용자별 스펙을 정의할 수 있게 되었다.
예전엔 ‘어떤 사람이 들어와도 쓸 수 있는 서비스’ 여서 좋은 점도 있었지만 제품을 고도화시킬 때 문제점도 많았다. 지금은 제품이 “이 사용자에게 필요한 기능은 이거야”라고 흐름을 만들 수 있고 직접 설명도 할 수 있어 제품 스케일 업이 쉬워졌다.
2) 팀의 언어가 명확해졌다
회의 중에 “이건 일반 사용자 대상이에요”, “이건 비즈니스 플로우죠”라는 말이 자연스럽게 오간다.
제품-디자인-운영이 같은 언어를 쓰기 시작했다는 건 협업에서 큰 전환점이다.
3) 운영의 기준이 생겼다
운영팀도 이제 “이 사용자는 어떤 플로우를 거치고 있고, 어떤 메시지를 받아야 한다”는 기준을 갖고 응대하고 고객에 맞는 CRM 메시지도 자연스럽게 변했다.
6. 회고 : 이번 디자인 스프린트로 배운 것과 숙제
이번 디자인 스프린트를 통해 “사용자별로 어떤 제품 스펙이 필요한지”를 제품이 스스로 정의하고 설명할 수 있게 되었다.
하지만 아쉬운 점도 있었다.
운영자와 제품 간 커뮤니케이션은 여전히 부드럽지 않았다. 구조는 잘 짜였지만, 서로의 언어와 기대 속도가 달라서 중간중간 미묘한 긴장과 엇갈림이 있었다.
이건 단기간에 해결되는 문제가 아니고, 더 자주 대화하며 쌓아가야 할 숙제라는 걸 느꼈다.
디자인 스프린트는 만능 해결사는 아니다. 하지만 문제가 흐릿하고, 팀마다 관점이 조금씩 다를 때 강한 집중력 있게 문제를 해결할 수 있게 도와준다.
이번 경험을 통해 우리는 단순히 사용자를 나눈 것을 넘어 “사용자별로 어떤 구조로 제품을 설계해야 하는가”에 대한 공통된 언어와 기준을 만들 수 있었다.
디자인 스프린트 꼭 해보세요!
