04. 우린 정말 린했다고 할 수 있을까?
선택한 아이템을 서비스화 하기 위한 토론 100시간.
이 글은 시리즈로 연재되며 어썸 팀을 운영하며 겪은 경험을 기록하는 것을 목표로 합니다.
시리즈 목차.
01. 사이드 프로젝트? 그런 거 왜 해요?
02. 야 너두? 야 나두! 좌충우돌 동료 찾기
03. 우리는 아이디어 뱅크. 혼돈의 아이템 선정하기
04. 우린 정말 린했다고 할 수 있을까?
05. 그래서 우리 서비스의 와우포인트는 뭐야?
06. 알 껍질을 깰 힘이 없어. 빛을 보지 못한 우리 프로젝트
07. 새로운 도전, Awesome 시즌2
08. 완성도 습관이다.
09. 잘하는 걸 하자.
10. 어느덧 10명. 나는 조직을 책임져야 한다.
11. 사이드 프로젝트를 통해 경험한 리더의 역할
12. 나는 정말 잘하고 있는 걸까?
3편 보러 가기(이전 글)
https://brunch.co.kr/@designerlab/6
이번 글에서는 선정된 아이디어를 서비스화 시키기 위해 구체화하는 과정을 이야기한다.
프로젝트 히스토리
작년, 우리 팀원들은 자기 계발에 굉장히 많은 에너지를 쏟고 있는 시기였다. 지금은 코로나의 여파로 많은 행사들이 웨비나(스펙트럼콘 같은) 형태로 바뀌었지만, 작년만 해도 오프라인에서 대형 세미나들이 굉장히 활발하게 주최됐었다. 어썸 멤버들은 간접적인 경험과 노하우 습득에 흥미를 느끼며 외부 세미나에 빠지지 않고 다니곤 했다.
수준 높은 강연을 들었을 때 오는 만족감에 우리는 생각보다 많은 불편함을 감수한다. 크리티컬 하지는 않지만 사소한 불편함이 많은 순간들을 개선하기 위해 프로덕트를 기획했다.
프로덕트를 설계하기 위한 과정
보통 프로덕트를 설계할 때 여러 가지 방법론을 사용해서 문제의 이해도를 높임과 동시에 구체화하는 과정을 진행한다. 대표적으로 '더블 다이아몬드', 'SWOT', '4P', '4C' 등 다양한 방법론이 존재한다.
우리도 마찬가지로 비슷한 방법들을 적용해보며 프로덕트의 방향과 전략을 수립하는 과정을 거쳤다. 다양한 방법론을 적용해보면서 느낀 점이 있다면, 방법론은 말 그대로 하나의 방법일 뿐이고 절대적이지 않다는 것이다. 가끔 하나의 방법론을 마치 절대적인 기준으로 삼는 케이스들을 종종 보게 된다. 방법론을 맹신하여 그 틀에 매몰되지 않고 문제의 본질을 이해하고 해결점을 찾는 것이 더욱 중요하다.
나는 프로젝트를 진행할 때 아래와 같은 순서로 프로덕트를 설계한다.
문제 발견 → 가설 설정 → 리서치(정성적, 정량적) → 데이터 분석을 통한 가설 검증 → 문제정의 → 해결 방안 및 전략 수립 → 경쟁사 분석 → 서비스 기획 → 디자인 → 개발 → 출시 → 개선
이젠 업계에서도 어느 정도 정형화된 프로세스가 되었고, 포트폴리오에도 하나의 트렌드로 자리 잡았다. 단순한 결과물 위주였던 디자이너 포트폴리오에 과정을 담아내려는 경향이 생겼다. 이 직군도 사고 능력에 대한 중요성이 많이 부각되긴 했나 보다.
문제의 발견
경험에 의존하여 세미나에서 겪었던 불편함을 이야기하는 시간을 가졌다. 그리고 나눴던 이야기에서 도출된 문제점을 쭉 나열시켰다. 모든 문제를 해결할 수 있는 프로덕트면 얼마나 좋겠냐만은 비현실적인 망상이다. 뜬구름 잡는 미완의 해결책을 제시하는 것보다 작은 테스크일지라도 우리가 해결할 수 있는 부분에 집중하는 게 좋다고 생각했다.
나열하고 보니 문제가 발생하는 지점이 너무 다양하다. 그래서 우리는 '문제의 종류'를 구분하는 작업의 필요성을 직감했다. 이 단계는 진짜 우리가 해결할 수 있는 부분을 찾기 위한 필터링 시간이었다.
이 작업을 통해 문제를 세 가지 타입으로 분류할 수 있었다.
내부의 문제 : 참석자가 세미나를 들으면서 발생하는 모든 문제
외부의 문제 : 주최 측, 공간에서 발생하는 모든 문제
중의적 문제 : 주최 측과 참석자의 공동의 문제이거나, 누구에게도 해당되지 않는 문제
문제를 분류하고 나니 해결할 수 있는 것과 사이드 프로젝트 선에서 해결하기 힘든 부분을 명확하게 정의할 수 있었다. 아무래도 외부적인 요인은 주최 측과의 긴밀한 소통이 필요한 데다 금전적인 문제가 발생하니 사이드 프로젝트로는 적합하지 않다. 중의적인 문제 역시 쉽게 해결하기 어려운 부분이었다. 그래서 우리는 해결할 수 있는 '내부적인 문제'에 포커스를 두고 구체화하기로 했다.
가설 설정
우리가 정리한 내부적인 문제는 세미나를 듣는 중이거나 듣고 나서의 행동들에서 발생했다.
더 딥하게 문제를 들여다보면, 강의 기록/리마인드(복습)에 대한 내용이 주를 이뤘다. 강의에 집중하기 위한 고민이거나, 들었던 내용을 잊지 않기 위해 기록하는 것, 실제 업무환경에 녹여내기 위해 복기하고 싶은 니즈가 있었다.
그렇게 아래와 같은 가설을 세워봤다.
- 세미나의 신청일, 시간을 까먹는다.
- 강의 때 적어두었던 기록이 나중에 찾아봤을 때 알아보기 힘들다.
- 강의가 끝난 후 적어뒀던 기록을 방치하게 되어 기록이 무의미하다.
- 사진 촬영, 필기 등에 집중하느라 정작 중요한 연사의 말에 집중하지 못한다.
이 가설은 우리의 경험에 기반한 것이기에 완벽하게 사용자의 니즈라고 말할 수 없다. 서비스의 핵심이라고 생각한 문제가 우리만의 망상이 아니라는 '검증' 단계가 필요했다.
정량적, 정성적 리서치로 인사이트 도출하기
리서치는 다들 잘 아시는 것처럼 정량적 리서치와 정성적 리서치로 나눌 수 있다. 두 방법의 차이점과 필요성을 글에서 설명하기엔 글이 너무 길어지니 패스! 우리는 설문조사, 인터뷰, 직접적인 대상 관찰, 이 세 가지 방법을 활용해서 정량적, 정성적리서치를 진행했다.
설문조사를 통해 정량적 리서치하기.
설문조사를 하기 위해서는 문항 설계가 필요하다. 자주 경험할 일이 없는 분야라 전문성이 없어서 많은 자료들을 참고하며 설계할 수밖에 없었다. 단순히 원하는 거 물어보면 되잖아? 하며 접근했다가 예상외로 이렇게까지 어려울 일인가... 새삼 당황했다. 설문지를 만드는 것은 엄청난 고민이 필요한 영역이다. 문항 설계에서 가장 중요한 포인트는 우리가 원하는 답변을 얻기 위해, 설문자를 유도하는 질문을 하는 실수를 하지 않아야 한다는 것이다. 얼추 비슷해 보이는 질문이라도 약간의 차이가 완전 다른 결과값을 불러올 수 있다는 점을 인지하고 객관적인 질문을 설계해야 한다.
구글 설문지에 응답해주신 분들께 다시 한번 감사드립니다.총 103명에게서 응답을 받았다.
모수가 100명 이상되어야 표본이 적어서 발생하는 오차율을 최소화할 수 있을 거라 판단했기에 최소 100명을 채우려고 노력했다. 하나 아쉬운 점이 있다면 조사기관이 아닌 일반인이 직접 설문조사를 하게 될 경우, 조사 대상이 꽤 좁아진다는 것이다. 비슷한 직군의 사람들에게 물어볼 수밖에 없는 환경이 조금 아쉬운 부분이다. 물론 애초에 예상하는 서비스의 타깃 자체가 비슷하게 맞아떨어져서 그나마 다행이지만, 일반적인 경우엔 객관적인 데이터로 활용하기 아쉬운 부분이 많을 것이다.
정성적 리서치는 예상 타겟에 대한 관찰과 인터뷰를 진행했다.
앞서 설문을 진행하면서 새롭게 정리한 인사이트를 바탕으로 필드 리서치를 다녔다. 자기 계발에 관심이 많은 타깃들의 행동을 직접 관찰하고 설문과 유사하게 행동을 하는지, 실제로 불편해하는 요소가 무엇인지 관찰했다. 그리고 대상과 심층 인터뷰를 통해 사용자 니즈를 구체화하는 시간을 가졌다. 이 두 가지 방법은 설문조사와는 느낌이 또 달랐다. 대화를 통해 유저의 진심을 들여다보는 시간이 실제 업무에서도 꼭 필요하다고 느끼게 된 부분이다.
대면 인터뷰의 장점은 훨씬 더 딥한 내용을 사용자에게 직접 들을 수 있다는 큰 장점이 있다. 꼬리 질문을 통해서 설문조사로는 부족했던 디테일들을 챙길 수 있다. 이 단계에서도 마찬가지로 원하는 답을 듣기 위한 유도 질문을 자제하고, 인터뷰이가 자유롭게 이야기할 수 있도록 방향성과 환경을 만드는 것이 중요하다.
리서치 데이터 분석을 통한 가설 검증하기
응답 데이터를 바탕으로 내부적으로 세웠던 가설에 대한 검증과 새롭게 얻은 인사이트를 정리했다. 일부분은 우리가 생각한 것과 일치하는 반면, 실제 사람들은 우리가 불편하다고 예상했던 경험에 대해 불편했다고 인식하지 못하는 케이스들도 있었다. 그밖에도 우리가 생각하지 못했던 포인트들을 발견할 수 있었다.
[설문대상]
응답자의 44.6%는 20대, 23.3%는 30대로 과반수 이상이 20~30대.
74%의 회사원, 12%의 프리랜서가 다수를 차지했다.
65.2%가 1~5년 차 사이의 주니어, 34.8%가 5년 차 이상 시니어다.
[설문 분석]
- 응답자의 100명 중 94%가 연간 3회 이상 세미나에 참여한다.
- 그중 86%가 강의 도중 기록을 한다.
- 개인 업무에 활용하거나 복습을 하기 위해, 공유할 콘텐츠를 제작하기 위해. 사진, 녹음, 필기를 통해서 기록을 남긴다.
- 기록을 하지 않는 사람 중 64%가 ‘강의에 집중하기 위해’라고 답했다.
- 복습에 가장 도움이 되는 기록은 텍스트-사진-녹음 순이다.
- 텍스트는 필요한 내용만 기록하는 경우가 다수이며,
- 사진은 빠른 촬영 - 흔들림 제거가 중요하며, 특이한 점은 타인의 눈치를 본다는 것(11%)
- 녹음은 전체를 하며, 강의에 집중을 할 수 있어 선호한다. 용량이 제일 큰 걱정 포인트이다.
[유저들의 행동 분석]
- 사진을 촬영할 때마다 어플을 켜고 노출을 잡고 확대하고 초점을 잡고 촬영했다.
- 사진을 촬영하다 초점이 맞지 않아 다시 촬영했다.
- 촬영 세팅을 하다 연사가 화면을 갑자기 넘겨 촬영하지 못하고 넘겼다.
- 타이핑(+수기) 하기 바빠 연사의 말에 집중을 하지 못했다.
- 노트북의 배터리가 빨리 닳아, 중간에 필기를 그만두기도 했다.
- 앞사람이 화면을 가려 이리저리 피해 가며 스크린을 촬영했다.
문제 정의
위 상황들을 종합적으로 관찰하고 분석해 본 결과 아래와 같은 'problem definition'을 내릴 수 있었다.
- 자리배치에 따라 프레젠테이션 화면을 촬영하기 어려움을 느낀다.
- 기록에 많은 시간을 투자하게 되어, 연사의 말에 집중하기 어려움을 느낀다.
- 디바이스의 용량이 부담으로 다가와 녹음방식의 기록에 부담을 느낀다.
- 강연이 끝나고 나중에 다시 찾아보기 유용한 기록 데이터에 대한 니즈가 있다.
이런 부분들을 잘 보듬어 줄 수 있는 서비스를 만든다면 꽤나 의미 있는 프로젝트가 될 것이라 생각했다. 그렇게 찾아낸 Pain Point를 해결하기 위한 기능들을 고려하기 시작했다.
해결 방안 및 전략 수립
촬영 : 한 번의 세팅으로 흔들림 없이 빠르게 촬영되길 원한다.
→ 한 번의 초기 세팅을 통해 최적의 상태를 유지하며, 간편 자동 촬영 기능을 제공한다.
타이핑 : 복습, 개인적인 활용을 위해 저장된 콘텐츠의 텍스트 화가 필요하다.
→ 연사의 말을 실시간으로 텍스트로 바꿔주는 AI모듈을 탑재한다.
녹음 : 디바이스의 용량 걱정을 덜어줄 기능이 필요하다.
→ 녹음 파일의 음질을 사전에 설정하여, 용량을 최적화시켜준다.
위 기능들만 보면 사실 엄청 특별하다거나 와우 포인트가 느껴지지 않는다.
그냥 뻔한 기록 앱 아니야?라고 할 수도 있다. 요즘 서비스 시장은 비슷한 기능들을 가진 서비스가 굉장히 많기에 특히나 와우 포인트를 잘 만드는 것이 중요하다고 생각한다. 그래서 우리 서비스만의 엣지를 어떻게 만들지 많은 고민이 필요했다. 이 부분까지 다루기엔 글이 너무 길어지므로, 이 이야기는 다음 편에 이어서 적어보겠다.
이처럼 우리는 많은 프로세스를 거치면서, 디테일을 신경 쓰느라 결코 '린'하지 못했다.
이번 편에서 다룬 부분은 서비스를 제작하기 위한 완전 초석을 다지는 정도에 불과하다. 초석 다지기가 끝났다면 다음 스텝에선 좋은 유저 경험을 설계하고, 우리 서비스만의 킬링 포인트를 만들기 위한 고민의 시간이 필요하다.
물론 나는 차근차근 근거를 마련해나가는 이 방법이 틀렸다고는 생각하지 않는다. 단점이 있다면 이 단계에서 너무 많은 시간을 쏟게 된다는 점이다. 팀원이 지치기에 딱 좋은 타이밍이다. 사이드 프로젝트 특성상 기간이 길어질수록 끝을 보기 힘들고 팀원이 이탈할 확률이 높아진다. 오랜 시간을 들일수록 완성도는 높아지겠지만 돈을 버는 생계수단이 아닌 이상 흥미도가 줄어들기 마련이다.
그래서 사이드 프로젝트는 가능한 수준에서 최대한 빨리 MVP모델을 출시해보고, 반응을 보며 업데이트해 나가는 게 중요하다고 생각한다.
다음 편에서는 UX를 설계하고 서비스의 와우 포인트를 만드는 이야기, 이 과정에서 서로 다른 의견이 충돌했을 때 헤쳐나가는 법에 대한 이야기로 돌아오겠습니다.
05. 그래서 우리 서비스의 와우포인트는 뭐야?
혹 저에게 궁금한 점이 있으시다면 designerlab@kakao.com으로 메일 주시면 답변드리겠습니다 :)
빠른 IT 소식과 좋은 아티클들을 소개하는 페이스북 페이지 디자이너랩도 많이 찾아주세요!
https://www.facebook.com/DesignerLabStudy
긴 글 읽어주셔서 감사합니다
