우리, 싸우지 말고, 정성적 VOC 수집합시다!
[PM 북클럽] DIY 평가, 갈등은 줄이고 생산성은 높이다
서론:
"사용자들은 ___을 좋아해요"
라는 말에 담긴 오류
PM 북클럽 노션에 기록한 첫 번째 독서 토론지난 일요일, 새롭게 시작한 PM 북클럽 사람들과 구글 밋에서 첫 번째 실시간 모임을 가졌다. 각자 인상 깊에 읽은 부분을 공유하면서 깨달은 점이 있다. 책 내용을 요약하는 데만 너무 집중해서 포스팅에 아쉬움을 느낀다는 사람들이 꽤 많았다는 것이다. 이에 반해 나는 책 내용과 동떨어진 내용 위주로 포스팅을 해서 자중해야겠다는 다짐을 했다.
같은 책을 읽어도 서로 다른 방향의 포스팅을 써내려갈 거라는 걸 어느 정도 예상은 했지만, 실시간 모임에 참여한 모임원의 입으로 직접 이야기를 들으니 감회가 새로웠다. 나와는 다른 생각을 확인할 수 있는 좋은 시간이었다. 이런 실시간 모임을 꾸준히 가져야 하는 이유 중 하나인 것 같다.
실시간 모임의 영향으로, 오늘 포스팅에서는 사례 이야기는 잠시 넣어두고 책 요약에 집중해보려고 한다. 나의 <(사용자를) 생각하게 하지 마!> 독서 경험에 대해 되도록 많이 기록하려고 한다. (그래서 오늘은 'PM의 시선 한 스쿱'도 생략!)
1. 근데 그거, 사용자들도 좋아할까요?
미팅에서 가장 많이 듣는 말
"제 눈에는 별론데요?"
서비스의 이해 관계자들은 충돌할 수밖에 없다. 서로의 이익과 손해가 복잡하게 얽혀 있기 때문이다. 갈등 한 번 없이 물 흐르듯 서비스가 만들어질 수는 없다. 이 이해 관계자들은 크게 다음과 같이 구분할 수 있다. 제품을 개발하고 디자인하는 제품 팀, 제품을 시장에 판매하고 운영하는 비즈 팀, 그리고 기획 팀(혹은 기획자).
개발자나 디자이너가 아니더라도 제품 팀에 속할 수 있으며, 비즈 팀에는 매우 다양한 직군의 사람들이 포함되기도 한다. 중요한 것은 카테고리의 이름이 아니라 속성이다. 그리고 저마다 다른 속성을 가진 이해 관계자 집단끼리는 대개 충돌한다. (심지어는 동일한 집단 안에서도 갈등이 끊이지 않는데, 다른 집단끼리는 오죽할까?)
ⓒ July이때, 나와 같은 PM/PO/서비스 기획 직무는 기획자에 해당한다. 기획자는 기획을 잘해야 한다. 기획을 잘하려면 나의 기획을 실현해줄 제품 팀, 그리고 나의 기획을 퍼뜨려줄 비즈 팀, 그리고 기타 이해 관계자들끼리의 소통에 어려움이 없어야 한다.
따라서 기획자는 이해 관계자들의 수많은 갈등을 조율해야 하는 입장에 놓여 있다. 각자 자신의 입장을 말하기 바쁜 상황에서 한 사람 쯤은 귀를 열고 양측의 입장을 모두 들어본 뒤 의사소통의 막힌 부분을 시원하게 뚫어주어야 하는데, 그걸 담당하게 되는 사람이 바로 기획자이기 때문이다.
이해 관계자들이 갈등하는
단골 주제
출처=스티브 크록, 『(사용자를) 생각하게 하지 마!』이들이 갈등할 때 밥 먹듯이 등장하는 논점은 바로 이것이다. "우리 사용자들은 그거 싫어할걸?" 미성숙한 감정 싸움에 대해 이야기하려는 게 아니다. 그러나 대놓고는 아닐지라도, 다들 웹·앱을 더 잘 만들고 싶은 욕심을 갖고 모인 자리일수록 저런 의미를 담은 말들이 오가는 경우가 부지기수이다.
충분히 성숙한 의사소통이 이루어지는 조직이라고 할지라도 이러한 갈등 자체를 피할 수는 없다. 게다가 다들 미팅에서 이 이야기를 꺼내들기 전, 자신의 주장을 뒷받침할 수 있는 객관적이고 사실적인 근거를 추려서 제시할 것이다. 그런데도 우리의 대화는 미끄러지고, 미팅은 지지부진해진다.
임시완도 솔의 눈을 마시면 타박 받는다...이해 관계자들에게는 한 가지 공통점이 있는데, 웹·앱을 만들어나가는 사람들이기도 하지만 웹·앱을 사용하는 사람들이기도 하다는 것이다. 모든 웹·앱 사용자들이 그러하듯 이들 또한 서비스의 구성 요소에 대한 호불호를 갖는다. (위 사진 속, 호불호가 심한 음료인 솔의 눈처럼…^^)
물론 "좋은 웹·앱이란 무엇인가?"에 대한 의견은 개개인마다 너무도 다르며, 그에 대한 어느 정도의 합의를 거친 사람들이 하나의 제품을 만들어보고자 한 자리에 모였을 것이다. 그러나 그런 과정을 거쳤더라도 서비스의 세부적인 요소, 특히 화면상의 구성에 대해 이야기할 때(버튼을 달 것인가, 말 것인가. 크기는 작게 할 것인가, 크게 할 것인가 등등)는 의견이 쉽게 좁혀지지 않는 이유가 여기에 있다.
나의 주장을 펼치기 위하여 최대한 객관적으로 수집한 증거라고 할지라도 결국에는 의견을 제시하는 사람의 취향이 반영될 수밖에 없다는 이야기이다. 방대한 양의, 철저하게 분석한 정량적 자료를 들고 온다 한들 개인의 시각이 덧씌워지지 않을 수는 없다. 어쩌면 내가 관찰한 고객들만 그런 것을 선호하고, 그런 행동을 한다는 가능성을 배제할 수 없다.
게다가 설령 나의 주장에 한 마디도 더 얹을 수 없을 만큼 빈틈없이 완벽한 근거가 마련되었다 한들, 우리끼리 잘해보자고 모인 미팅에서 주장을 관철하는 데만 집중하면 무슨 소용인가? 그리고 그 근거를 마련하기까지의 불필요한 리소스의 소모가 심할 것이다. (데이터를 들여다보고, 사용자를 관찰하고, 문서를 작성하고...)
그렇기에 호불호의 관점에서 사용자를 묘사하려는 시도부터 폐기해야 한다. 일차원적인 호불호의 관점에서 사용자를 묘사하려는 시도는 수포로 돌아가는 비생산적인 행동이다. 우리는 싸우려고 일을 하는 게 아니잖아요...?
우리는 좋은 웹·앱을 만들기 위해
소통하는 것이니까
<(사용자를) 생각하게 하지 마!>의 주제인 UI/UX에 집중하자면, 따라서 딱 잘라 옳다고 말할 수 있는 UI/UX는 없다. 모든 사용자는 다르다. 그러니 웹·앱의 사용 방식도 모두 다를 수밖에 없다. '대부분'이 무엇을 좋아하는지 발견하고자 노력하는 행위는 미팅 시간만 쓸데없이 늘일 뿐이다. 그러나 정답이 없다고 해서 더 나은 UI/UX를 제공하려는 시도를 멈출 수는 없다.
이런 굴레를 타파하려면 MVP가 필요하다. MVP는 최소 기능 제품(Minimum Viable Product)의 줄임말로, 제품의 가장 핵심적인 기능만을 담은 테스트용 제품이다. 매우 조잡한 버전이더라도 (심지어 종이에 그린 그림이 다일지라도) 이를 통해 빠르고 저렴한 방식으로 사람들이 제품을 사용하는 모습을 관찰하고 분석할 수 있다.
그리고 이 MVP를 바탕으로 사용성 평가를 시도해야 한다. 사용자를 주의 깊게 관찰하고, 그들이 본인의 의도, 동기, 사고 과정을 서비스에 표현하는 모습을 지켜보는 것이다. 이를 통해 이해 관계자들은 웹·앱에 대한 개개인의 반응을 결정짓는 변수가 너무도 많다는 사실을 깨닫고, 모든 사용자가 자기 자신과 닮았을 거라는 착각에서 벗어날 수 있다. <(사용자를) 생각하게 하지 마!>의 저자는 이것을 대체할 수 있는 방법이 없다고 말한다.
2. 정성적 VOC의 끝판왕, DIY 평가
웹·앱을
가장 빠르게
테스트하는 방법
책에 따르면, 사용성 평가는 한 사람이 어떤 물건을 가지고 일반적인 과제를 수행하는 과정을 지켜보는 것이다. 그 과정에서 사용자가 혼란스럽다거나 답답하다는 느낌이 지점을 찾아서 고치는 것이 사용성 평가의 목표다. 사람들이 제품을 사용하는 모습을 직접 관찰하면서, 도중에 문제가 발생하는 지점을 메모하고, 우리가 만든(만들려는) 웹·앱이 너무 어렵지 않은지 확인할 수 있다.
책에서는 사용성 평가의 여러 가지 방법 중, DIY 평가를 중점적으로 소개한다. DIY 평가에서 DIY란 Do It Yourself의 줄임말로, 시간이나 비용이 부담될 때 활용할 수 있는 효율적인 평가 방법이다. DIY 평가는 말그대로 사용자가 웹·앱을 통해 특정 과제를 수행하는 행위를 그저 지켜보는 데 의의를 둔다.
전통적인 평가 방법의 경우에는 서비스가 거의 완성됐을 시점에 여러 명의 사용자들을 모아서 문제를 찾는 데 집중하지만, DIY 평가는 그저 몇 명의 사용자를 불러다놓고 어떻게 쓰는지 보고 듣는 것으로 많은 인사이트를 획득할 수 있다는 장점이 있다.
DIY 평가는 정성적이다. 엄격과 거리가 멀다. 그래서 심플하고 명료하다. 수고롭지 않다. 사용자에게 해야 할 일을 주고 그걸 해결하기 위해 어떤 행동을 하는지 관찰하면 된다. 그것만으로도 수많은 인사이트를 획득할 수 있다. 나의 주장을 강화하기 위해 수집하는 정량적 자료와는 달리, DIY 평가를 하면 실행으로 옮겨볼 수 있는 통찰을 얻을 수 있다.
DIY 평가를
진행하고 마무리하는 방법
이때 유의해야 할 점은 참가자가 편안하게 본인의 임무에 집중하게 해야 한다는 것이다. 그리고 자신이 생각하는 내용을 최대한 많이 소리 내어 말하게 해야 한다. 이를 통해 내부 인원이 보기에는 무난한 부분에서 사용자가 뜻밖의 긍정적 또는 부정적 사고를 하고 있음을 깨달을 수 있다. 그러기 위해선 자연스러운 환경이 조성되어야 하고, 사용자가 자신의 사고 과정을 솔직하게 실시간으로 말할 수 있도록 해야 한다.
과제 세부사항 일부를 참가자 스스로가 선택하게 하는 것도 좋은 방법이다. 구체적으로 "14달러 미만의 요리책을 찾으시오"보다는 "구매하고 싶은 책이나 최근에 구매한 책을 찾으시오"라는 과제가 더 낫다. 이러한 과정을 거치면 참가자는 자연스럽게 자신에게 주어진 과제에 더 많은 감정과 노력을 쏟기 때문이다.
이렇게 DIY 평가로 사용자를 관찰한 뒤, 여러가지 인사이트를 얻었을 것이다. 그럼 이중에 어떤 문제를 먼저 해결해야 할까?
이해 관계자들과의 충분한 숙고 과정을 거치는 간단한 방법은 공동 목록을 만드는 것이다. 먼저, DIY 평가 결과를 바탕으로 구성원들 각각 생각하는 가장 심각한 문제 세 가지씩 말할 수 있도록 한다. 그리고 이를 투표하고, 순위 매기고, 정돈하여 우선 순위를 결정한다. DIY 평가의 효율을 높이려면 가장 중요한 문제를 먼저 고치는 데 가차 없이 집중해야 한다. (단, 구성원들이 꼽는 가장 심각한 문제는 반드시 DIY 평가 중 목격한 문제여야만 한다.)
3. '평균 사용자'라는 신화
ⓒ July개인적, 직업적 의견의 충돌이 정체기에 들어설 때, 대화는 대개 사용자의 대부분이 무엇을 좋아하는지 싫어하는지 판가름하려는 쪽으로 흘러간다. 사람들이 무엇을 좋아하는지 토론하다 보면 시간이 낭비되고 팀 에너지가 소모된다.
그러나 '평균 사용자'라는 건 존재하지 않는다. 쉬운 문제라면 사람들이 대개 선호하거나 불호하는 사항이 분명할 테지만 (버튼의 크기를 0.0001px로 만드는 건 대부분이 불호하는 사항일 거다.), 실제 우리가 해결해야 할 문제는 그보다 복잡하다.
따라서 사용성 평가가 중요한 것이다. 앞서 소개한 DIY 평가와 같은 사용성 평가를 거치면 사용자들의 호불호에만 천착하던 토론이 효과의 영역으로 넘어간다. 다시 말해, 사용자들에게 어떤 UI/UX가 효과적일지 논의하는 토론의 장으로 도약할 수 있다는 말이다.
따라서 책에 소개된 대로 웹·앱의 초기 단계부터 상용화 직전, 이후 운영 단계에서 정기적으로 사용상 평가를 진행하면서 사용자들이 '진짜' 원하는 웹·앱을 만들어나가기 위하여 노력해야 한다. "나는 이거 별로던데"라며 상대방보다 나의 의견이 더 논리적이고 합당함을 밝히려는 행동은 싸움 상대에게나 소용이 있다.
결국 우리는 한 팀이기에, 갈등이 있더라도 성숙하게 풀어갈 줄 알아야 하며, 이 갈등을 통해 동반 성장할 필요가 있다. 그러기 위해선 손을 들고 "그럼 '진짜' 사용자들이 어떻게 웹·앱을 이용하는지 관찰해볼까요?"라고 말할 수 있는 용기 있는 중재자이자 기획자가 되어야겠다는 다짐을 했다.
