디자인 스프린트 첫 도입기 (2_feat. 실전편)
스타트업 일지
이번글에는 저번에 얘기해봤던 디자인 스프린트를 그러면 어떻게 적용했는지 회고록을 써보려고 한다.
Knapp이 쓴 Sprint를 읽다보면 이런 생각이 든다.
ㅎ... 이건 우리 현실이랑 많이 다른데...?
구글이라는 글로벌 대기업에서 디자인 스프린트는 사실 정말 이상적이다. Understand 과정부터 일단 프로젝트에 도움을 줄 수 있는 전문가들은 섭외되어있고 투표식으로 서로의 아이디에이션에 대해 결정하고 그리고 마지막 날에는 5명 정도의 인터뷰이도 준비되어있어야한다.
팀원이 곧 저고 팀장도 곧 전데요 하는 초기 스타트업은 유연하게 이 방법을 적용해볼 수 있어야 했다.
있는 리소스의 활용이 중요해
우선 처음부터 디자인 스프린트를 밞아오지 않았기 때문에 현재 단계에서 어떤 점들을 활용할 수 있을지를 생각해봐야했다. 현재는 우리가 어떤 문제들을 해결해야하는 구나까지 모두가 참여해서 큰 그림이 그려진 상태였다. 이제 어떻게 구체화를 할까? 어떤 형태로 앱에 들어가게 될까?
이 단계에서부터 디자인 스프린트를 활용해보기로 했다.
Ideation (Sketch) & Decide
전 단계에서 매트릭스를 통해 우선순위를 정한 문제들과 그 해결방법에 대해서 ideation을 해보기로 했다.
곧 핵심적인 기능에 대한 ideation 이었다.
참고해봤던 Ideation 단계의 방법론들 두 가지를 먼저 소개해보고자 한다.
1. Crazy 8
2. Sketch Solution
Crazy 8
구글에서 잘 쓰는 방식이라고 하는데 생각보다 무척 초등학교 수업같은 느낌의 방식이다. A4 용지를 접어서 8 등분을 한 후 한 문제에 대해서 여러 방식으로 아이디에이션을 해보는 것이다. 나는 이건 결국 시간안에 아이디어를 쏟아내기 위한 프레임워크라 생각하는데 결국에는 정해진 10분이라는 시간안에 8칸을 채워야 한다는 압박감을 주며 일종의 '마감 Magic'을 부릴 수 있게 도와주는 것같다.
당연히 스케치를 잘 하는 것이 중요하지 않다. (그럴 수도 없을 것이다) 다만 얼마나 다양한 아이디어들을 많이 쏟아낼 수 있는지가 중요하다.
Sketch Solution
Sketch Solution은 조금 더 성의를 기울인 Brainstorming이다. 팀원들은 자신이 흥미로워하는 문제에 대해서 어떻게 풀어갈 지 구체적으로 스토리보드처럼 스케치를 한다. 이미 이전에 어느정도 방법에 대한 이야기도 나왔기 때문에 Sketch Solution이 좀 더 빠르게 의사결정을 내리는데 도움이 되었다.
두 방식 모두 다 스티커를 붙여 투표의 형식으로 좋은 아이디어를 팀원들끼리 의견합의를 한다. 물론 "어떤 아이디어가 좋은 것인가?"에 대한 기준을 여러 면에서 종합적으로 정리를 해서 알려줘야 하는 것도 퍼실레이터의 역할이다. 참 민주적이고 좋은 방법이다. 다만 소규모 팀일 때는 해당 방식이 투표가 애매하게 비기기 쉽다는 단점이 있다. 그래서 우리의 팀의 경우는 각자 돌아가며 아이디어를 설명하고 피드백을 바로바로 주고받았다. 확실히 서로가 서로의 아이디어를 시각화를 하면서 구체화를 한 만큼 의사소통이 훨씬 더 명확해졌다는 것을 느꼈다.
Prototype
Sprint에서는 프로토타입은 가설을 검증을 해볼 아주 최소한의 도구라는 것을 강조한다. 왜냐하면 프로토타입에 공을 들이는 시간과 노력은 곧 수정하려는 의지와 반비례 하기 때문이다. 그렇다고 해서 테스트에서 신뢰성 있는 결과를 얻기 위해선 진짜처럼 보이기는 해야한다. (Lo-fi 프로토타입을 보여주면 유저는 몰입을 하지 못할 것이다). 많은 시간을 들이지 않으면서도 진짜처럼 보이는 퀄리티를 가져야 한다? 많은 시간을 공들일 수록 프로토타입에 대한 애정이 깊어진다. 애정이 아니더라도 노력을 들인 결과를 그만큼 써먹고 싶은 생각이 들 확률이 높지만 프로토타입은 재활용이 권장되는 친구가 아니다. 이렇게 미련없는 퀄리티를 가지고 있는 품질을 '골디락스 품질'이라고 부른다. 효율적인 프로토타입이 가져야 하는 품질이다. 이는 어떤 제품, 프로젝트냐에 따라 다르다. 수단과 방법을 가리지 않고 적절한 '골디락스 품질'을 각자 찾아 제작한다.
구글에서는 하루만에 나오는 프로토타입을 만들기 위해서 상당한 분업을 한다. 제작, 연결, 에셋 리소스, 그리고 콘텐츠를 채우는 사람, 그리고 프로토타입의 대본을 쓰는 인터뷰어까지 말이다. 하지만 스타트업에서는 이 모든 것을 거의 혼자해야하지....
시범적으로 한 번 프로토타입을 보며 점검을 하고 인터뷰 일정까지 잡으면 이제 다음단계인 Validate로 넘어간다.
프로토타입을 만들면서 느꼈던 점은 제작 전까지 상당히 많은 것들이 촘촘하게 정리되고 맞춰져야한다는 것이었다. 그것이 아니라면 당장 유저에게 골딜락스 품질을 가진 프로토타입을 보여주는 것보다 Lo-fi로 만든 프로토타입을 내부 점검으로 보는 것이 더 시급하고 중요할 수 있다.
Validate
Validate 과정은 말 그대로 제작한 Prototype을 통해서 제품을 검증해보는 과정이다. Knapp 이 소개한 Design Sprint에서 Validate 과정은 총 5명 이내의 인터뷰이들에게 프로토타입을 보여주는 방식으로 진행된다.
- 왜 5명인가?
지나친 리소스를 들이지 않고 효율적으로 리서치를 할 수 있는 수에 대해서 N/N group에서 연구한 결과가 있다. 몇 번을 인터뷰 해야 가장 중요한 패턴을 발견할 수 있을까? 연구결과, 그는 85 퍼센트의 문제가 단 5명을 인터뷰한 뒤 발견되고 있다는 것을 알았다. 즉 15퍼센트를 더 알아내느라 리소스를 투입하느니 85퍼센트만 우선 문제점을 알고 고치고 다음에 또 테스트를 해보는 것이 훨씬 경제적이라는 것이다.
-인터뷰를 하는 요령과 방법
인터뷰의 일정을 잡았다면 인터뷰를 하는 동안 스프린트 팀은 바쁘게 움직인다. 먼저 인터뷰어를 보자.
인터뷰는 목적은 제품에 대한 반응을 보는 것이지만 중요한 것은 자연스러운 환경에서 유저가 제품을 이용할 수 있는 세팅을 하는 것이다. 초반에 편안한 분위기까지 어느정도 인터뷰어와 친밀감을 느끼는 레벨로 이끄는 것이 중요하다. 프로토타입을 보여주는 과정에서도 인터뷰어는 이 제품을 사용하는데 정답은 없다, 이건 당신을 평가하는 용도가 아니다 라는 것을 계속 유저에게 상기를 시켜야한다. 프로토타입의 경험이 끝났다면 간단하게 피드백을 묻는 마무리 질문으로 인터뷰를 마무리한다. 다른 경쟁사 앱과 비교한 질문일 수 있고 이 제품에서 개선할 점은 어떤 게 있을 지 솔직하게 물어볼 수도 있다.
그리고 마치(아이러니하게) 취조실 수사를 하듯, 건너편에서는 스프린트 룸이 있다. 면접실에서는 스프린트룸이 보이진 않지만 역으로는 보인다. 스피린트 룸에서 팀원들은 동시에 인터뷰 내용을 보고 듣는다. 이렇게 하는 이유는 후에 인터뷰내용을 정리하고 서류로 가공하는 시간과 노력을 줄이기 위해서이다. 이렇게 한다면 나중에 "나는 그 인터뷰내용을 당신이 편집해서 정리한 걸 못 믿겠어!" 하는 볼맨소리도 없앨 수 있다. 그래서 스프린트 실에 거대한 화이트보드를 두고 스프린트 참여팀원들은 인터뷰를 들으며 실시간으로 흥미로운 부분을 포스트잇에 써 붙인다. 그리고 나중에 패턴을 발견하고 인사이트를 얻는다.
결론적으로 우리가 만든 프로토타입은 내부적인 점검용이 되었다. 내부적으로 전체적인 기획에 대해서 다시 한 번 생각해보자는 "If...?"라는 제안도 나오기도 했기 때문이다. 사실 이 단계에서 나온 프로토타입은 아쉽게도 외부에 공개가 되지 못해서 유저에 대한 검증은 하지 못한 채로 끝나긴 했다. 하지만 후에 좀 더 정교한 프로토타입이 나온 후, 잠재 유저들에게 보여준 결과 큰 구조변화 없이 앱을 출시해도 된다는 인사이트를 얻을 수 있었다.
첫 번째 디자인 스프린트 도입기를 되돌아보며...
정말 우당탕탕했던 도입기였다. 방법론을 유연하게 현재 상황에 대응해서 적용하는 것이 정말 어려운 점이라는 것을 다시 한 번 느꼈다. 디자인 스프린트는 목적 지향형 프로세스다. 의사소통을 하는 목적을 서로 맞추는데 시간과 노력을 어떻게 하면 줄일 수 있는가에 대한 방법을 푼 것이다. 하지만 때로는 그 목적을 맞추는 과정이 생각보다 길 수도 있다.(목적에 대해서 동의가 되는 과정까지 포함한다면, 더!) 이럴 경우에는 유연하게 조금 더 여유를 갖는 스프린트의 방식을 취해도 되었다고 생각한다.
참고링크
https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
https://uxplanet.org/generate-crazy-ideas-with-this-design-sprint-method-c6a36a16c3d5
