마상 없는 서비스 프로젝트 초기 기획
조직의 의견은 어떻게 하나가 되는가?
프로젝트 최초 기획을 하며 거시적인 시장 분석이 아닌 미시적으로 서비스를 기획 할때 생각보다 체계를 갖추지 않고 프로젝트를 수행하는 경우가 많습니다.
필요한 분석을 다하지만 결론에 맞춰 분석 행위를 요식행위로 하거나,
모든걸 생략하고 경쟁사 벤치마킹만 한 후 서비스 디테일을 바로 접근하여 바로 설계에 들어가버린 경우도 봤습니다.
그 과정에서 프로젝트에는 많은 생채기가 납니다.
초기 컨셉을 불분명 혹은 잘못 잡아 프로젝트가 이리저리 휘둘리기도 하고,
탑다운 혹은 일부 프로젝트를 주도하는 사람들의 의견만 받아들여져 팀내 케미스트리가 붕괴되는 경우도 발견하곤 합니다.
디자인 씽킹 내의 공감과 정의의 과정을 통해, 이러한 문제를 어떻게 해결하는 지 써보도록 하겠습니다.
1. 고객 공감 요소 찾기
프로젝트 수행을 위해 초기에는 여러 의견들이 넓게 개진되어야 합니다. 그리고 그 방향성은 고객에게 공감하기 위한 절차입니다.
이 상황에서 가장 그릇된 예시는 논리 배틀 입니다.
주니어가 회의에 참석해서 의견 하나를 내면, 주변에서 득달같이 태클이 들어옵니다.
'우리가 이걸 생각안해본 줄 아냐.' '이거 하는 데 돈이 얼마나 드는지 아냐.' '아 그것도 맞는 데 사실 옳은 건'
다양한 태클들이 들어옵니다.
- 실제 조직에서는 연차와 직급이 논리를 가장하는 경우가 많고
- 목소리 큰 사람의 의견이 논리처럼 받아들여질 때가 있으며
- 실제 이용자는 비논리적인 UX를 보여주는 경우도 있습니다.
그렇기에 초기 기획의 단계는 서로간의 논리 배틀이 되어서는 안되고,
이 서비스 혹은 이 서비스와 유사한 서비스를 사용하는 이용자를 공감하는 방향성을 가져야 합니다.
"내가 생각했을 때, 이게 더 직관적이고 편해."가 아니라, "20대 여성 이용자들은 이렇게 영상을 보더라."를 주로 이야기 해야 합니다.
내부에 Google Analytics나 분석 툴이 있다면 그것을 활용해도 좋고,
설문지 설계가 중요하지만 설문조사를 활용해도 좋고,
답을 정해 놓지 않고 이용자 페르소나, 니즈, 페인 포인트를 관점으로 하여 장시간 인터뷰를 하는 것도 좋습니다.
최초에는 개인의 생각이 덜 들어갈수 있게, 다양한 방법으로 이용자의 정보를 습득하여 그것을 바탕으로 이용자에게 공감되는 요소를 하나씩 넓게 펼쳐야 합니다. 논리를 배틀하는 것이 아닌, 고객 공감 포인트를 찾는다는 마음으로 접근해야 합니다.
2. 수렴의 기획
고객 공감의 요소를 찾았다면(혹은 앞선 과정에서 논리 배틀을 펼쳤더라도), 넓게 펴져 있는 요소들을 일반화하는 과정을 거쳐야 합니다.
Google Analytics를 퍼넬 분석을 해보니, 재생까지 고객이 많은 화면을 거치고 있다.
이용자 인터뷰를 해보니 아무 생각없이 화면을 뒤적거리고 있다고 한다.
-> 고객이 원하는 콘텐츠를 빠르게 찾을 수 있게 하자.
처럼 퍼져 있는 일련의 단서들을 통합하는 과정이 필요합니다.
(참고로 저러하니, 하이라키를 재설계하고 추천 시스템을 고도화 하자는 건 아이디어 구상 단계 입니다.)
이러한 일반화의 과정이 반복되면
육회를 좋아하는 나의 취향과 고사리를 좋아하는 너의 취향이 합쳐지듯,
비빔밥같이 너의 의견과 나의 의견이 하나되는 아름다운 결과를 확인할 수 있을 겁니다.
요소들이 분해되고 합쳐지기를 반복하고, 소통이 깊어질수록 너의 의견과 나의 의견의 경계는 불분명해지고, 오랜 시간 소통한 결과 프로젝트에 참여한 인원들이 공통의 목소리를 가지게 되는 아름다운 모습을 경험할 것입니다.
추가로 프로젝트 인원 외에 기타 이해관계자 및 임원의 의견을 되려 적극 참여시키고 받는다면, 프로젝트 수행 당시에는 다소 껄끄러울순 있지만, 결과적으로 프로젝트가 수행되는 데는 큰 도움이 될 것 입니다.
이런 일련의 컨셉을 정의하는 게 시간 낭비라 생각할 수 있습니다.
하지만
- 서비스 컨셉을 최초에 정의하지 않으면, 설계 동안 과도한 아규가 발생할 수 있습니다. 정의된 서비스 컨셉은 기획/디자인/개발 의 의사결정을 하는데 있어 우선순위가 될 것입니다.
- 고객에 맞추지 않은 서비스의 성공 가능성을 낮게 봅니다. 쓸데 없는 서비스를 만들어 과도한 비용을 지출할 수 있습니다.
정도를 걷는 기획이 성공할 수 있는 서비스를 만들 수 있는 지름길이라 생각합니다.
또한 적당한 정도의 아규는 긴장감을 주고 팀의 케미스트리를 올려주지만,
프로젝트가 단순히 논리 배틀이 되거나 탑다운으로 의사를 찍어버리는 상황이 발생하면 역효과가 날 수 있습니다.
조직내의 적당한 긴장감을 유지하고 조직이 하나된 의견을 낼 수 있게,
Product Owner나 PM이 적합한 방법론을 선정하고, 조정자의 역할을 수행해야합니다.
