by
Nov 12. 2023
#23 기획 컨셉 리뷰 그리고 우리가 집중해야 하는 것
2023년 45주 차 회고
이전 회고 ☞ https://brunch.co.kr/@327roy/71
다음 회고 ☞ https://brunch.co.kr/@327roy/73
노트
#1 기획 컨셉 리뷰에 대한 회고
#기획리뷰 #컨셉공유 #회고
이번 주는 내가 조직에 온 후 첫 번째 스프린트의 첫째 주다. 따라서 지금 있는 조직 구성원들과도 처음으로 호흡을 맞추는 중인데, 다행히 이번 스프린트에 진행할 수 있을 정도의 기획물들을 개발자들에게 넘긴 상태다. 현재는 어찌어찌 다음 스프린트 개발 사항에 대한 컨셉 기획도 완료하여 리뷰를 진행했다.
이번에 리뷰를 가진 항목은 기존 앱의 메뉴 하나를 통째로 리뉴얼하는 프로젝트인데, 1) 개선의 이유와 2) 나아가려는 방향, 3) 이 항목을 서비스의 어떤 가치를 제공하기 위한 장치로 사용할 것인지에 대해서는 이해관계자에게 공감받을 수 있었다. 다만 몇 항목은 리뷰가 끝난 후에 기획 내용이 일부 변경되었다. (동일하게 고민하고 있던 내용들이 피드백에서 도출되었다.)
아래는 리뷰를 가지며 생각한 것들.
#1. 고민을 공유한 것이 이 상황에서 모두에게 긍정적인 방향이었을까?
이번 컨셉 리뷰를 진행하기 전에 기획 사항에 대한 분석과 시뮬레이션을 통해 많은 경우의 수를 뽑아냈다. 하지만 지금 와서 생각해 보면 이번 리뷰에서 내가 기획을 하며 가지고 있던 고민을 함께 공유한 것이 아쉬운 선택이었던 것 같다.
기획의 고민을 개발자들에게 까지 공유하는 행위 자체가 나쁘다는 의미는 아니다. 조직마다 가지고 있는 역할의 범위와 의사결정자가 다르기 때문에 어떤 조직에서는 효과적일 수도 혹은 그렇지 않을 수도 있다.
단, 고민을 많은 이해관계자에게 터놓을 때 발생할 수 있는 문제가 명확하기 때문에 아쉬운 선택이라고 생각했다. 고민을 공유할 때의 대표적인 문제는 공유와 이해를 위한 방향적 성격이 강한 미팅에서 아이디에이션을 위한 미팅으로 회의의 목적이 바뀌는 것이다. 특히 사람이 많아질수록 의견이 수렴되기보다 발산되는 경우가 많아진다. 이로 인해 누군가에게는 시간을 뺏는 회의가 될 수 있다는 것이 큰 단점.
그렇다면 어쩌다 고민을 공유한 형태가 되었을까? 이는 내가 기획한 것에 대한 자기확신이 부족했기 때문이라고 생각한다. 자기확신이 부족하기 때문에 더 좋은 방향을 찾고 싶었던 것이고, 이를 이번 회의까지 가지고 왔다는 것이 원인 아닐까.
#2. 자기확신이 부족했던 이유는 뭘까?
기획자는 다양한 방향과 방법을 생각하며, 그중에서 가장 최선이라고 생각하는 것을 하나씩 선택해서 기획한다. 다만 이때는 항상 잘못된 길을 선택하는 것에 대한 불안감이 따라온다. 그러다 보니 꽤 많은 사항들의 변동 가능성을 열어두게 되는 것이 아닐까.
다만 자기확신이 부족한 스탠스를 오랫동안 취하게 된다면 본인에게도 그리 긍정적이지 않을 수 있다. 당장은 '남의 의견을 잘 들어주는 기획자'로 보일 수도 있지만, 지속되면 '믿고 함께 하기 힘든 기획자'가 될 수 있기 때문이다.
#3. 다수에게 피드백을 요청하는 것이 꼭 효과적이지만은 않다.
앞서 다수와 아이디에이션 할 때 발생할 수 있는 문제를 언급했다. 또 다른 측면에서는 고민을 공유한 후 피드백을 바로 들을 때 발생할 수 있는 문제로는 피드백을 주는 사람이 생각할 수 있는 시간을 충분하게 가지지 못한다는 것이 있다.
우리는 보통 매 회의에 앞서 토론을 하듯이 사전에 주제에 대해 의견을 정리하고 자료를 찾지 않는다. 이 때문에 갑작스러운 피드백을 요청하면 대부분의 사람들은 현장에서 빠르게 이해할 수 있는 얕은 부분을 기준으로 개인의 멘탈모델에 의지한 피드백을 줄 수밖에 없다.
보통 UI와 관련된 피드백을 전달받을 때 그런 경우가 많은데, 예를 들어 '사람들은 그 기능이 대해 보편적으로 이렇게 사용할 것이에요.'라는 피드백을 말할 수 있다.
이때 피드백을 접수하는 입장에서는 조심해야 하는 포인트가 하나 더 늘어난다. 이렇게 발산된 개인의 피드백을 사용자 전체의 피드백으로 대변해서 생각하면 안 된다는 것이다. 이 때문에 수집한 피드백 중 자신의 의견에 힘을 실어줄 수 있는 것들만 채택하고, 원래 생각한 형태로 진행되는 경우를 많이 봤다.
그래서 시간의 여유가 있다면 팀원이 사전에 합의한(= 공감한) 페르소나를 정하고, 그 페르소나(= 사용자)를 기준으로 판단하는 것이 보다 효과적일 수 있다고 생각한다. (페르소나와 정반대 될 수 있는 소수의 고객을 챙기지 못함에도 불구하고 말이다.)
#4. 본인의 매몰 상태에서 벗어나기 위해 다수가 희생되지 않도록
결국 이번 리뷰를 돌아보면 방향에 대한 확신이 들어서 가진 리뷰가 사실은 스스로의 매몰 상태이서 벗어나기 위한 도구로 사용되었다는 생각이 든다.
이 때문에 다른 구성원들이 나 때문에 시간을 버린 것은 아닌지 미안한 마음. 선택과 결정을 하는 것에 정답은 없다. 하지만 과감하게 결정을 하고, 실패한다면 이에 대해 책임질 수 있는 기획자가 되어야 함을 다시 한번 느낀 하루였다.
p.s.
아무튼 돌고 돌아 개발할 형상에 대해서 (다시 한번) 확정하고, 미래에 고려해야 하는 케이스를 정리했다. 그래서 다음 주 상세 기획을 진행한 후 기획 리뷰를 가질 때는 이번에 공유한 것과 조금 다른 형태가 되어 있을 듯.
#2 아는 것이 많아질수록 우리가 정말 집중해야 하는 것
#가치 #존재의의
어떤 직무의 사람이든 시간이 지날수록 습득한 레퍼런스, 성공사례, 지식, 경험이 많아진다. 기획자의 입장에서는 이전보다 기획 시 고려할 수 있는 상황이 많아지게 된다. 예를 들어 제품의 방향, 컨셉을 설정하거나, 유저 플로우나 정책을 만들거나, 화면을 설계하는 경우.
고려할 수 있는 경우가 많다는 것은 1) 이전보다 개발 후의 비용(기획부채)을 줄일 수 있고, 2) 다른 기능과의 의존성, 확장성을 전보다 잘 고려할 수 있다는 장점이 있다.
그렇다고 모든 것이 좋은 것은 아니라고 생각한다. 내가 생각하는 대표적인 문제는 '고려할 수 있는 사항이 많아질 때 선택이 어려워진다는 것'. UX의 10개 법칙에서 말하는 '힉의 법칙'에서 다루는 내용과 유사하다. 의사결정에 걸리는 시간이 선택지의 개수와 복잡성에 비례해서 늘어나는 것.
예를 들어 본인이 모바일 앱 서비스를 제공하고 있는 입장이며, '사용자가 게시글에 댓글을 작성할 수 있다.'는 유저 스토리를 제품에 기능으로 녹여야 하는 상황을 가정해 보자.
이를 기능으로 풀 때는 여러 방법이 존재한다.
1. 새창 형태로 댓글 전용 페이지를 구현하고, 그곳에서 댓글을 작성하게 하고 노출시킨다.
- 예시: 브런치 게시글 댓글쓰기
버튼 클릭 시 새창 제공ⓒ 327roy2. 원래 게시글 화면에서 댓글을 작성하게 하고 노출시킨다.
- 예시: 카카오톡 게시글 댓글쓰기
하단 Input 클릭 시 키보드 제공 ⓒ 327roy3. 바텀시트 형태로 댓글 페이지를 구현하고, 그곳에서 댓글 작성하게 하고 노출시킨다.
- 예시: 인스타그램 홈(피드)에서 댓글보기
- 새창에서 페이지로 보여주는 것과 기술적으로는 유사하게 구현할 수 있지만 화면이 가지는 목적이 조금씩 다르다.
댓글 아이콘, 댓글 보기 클릭 시 바텀시트 제공 ⓒ 327roy동일한 유저 스토리에서 여러 케이스를 찾을 수 있다는 것은, 각 케이스별로 목표를 달성하며 함께 달성하고자 하는 가치가 다르다는 것을 의미한다. 즉 동일한 목표를 이루기 위한 기능임에도 각자 태어난 이유(사명)가 다르다. 이 때문에 비슷한 목적 하에 등장한 케이스들은 각자 장단점이 트레이드 오프되는 경우가 많다.
위의 예시를 조금 더 이어가 보자. 댓글을 새창에서 작성하게 한다는 것(1번)은 화면에서 사용자가 집중하게 만드는 영역을 '댓글'로 명확하게 만든다는 것에서 의미가 있다. 댓글을 통한 소통에 집중하게 만든다고 생각할 수 있다. 다만 댓글을 작성하는 도중에 본문을 확인하기 힘들다. 댓글을 작성하기 시작한 순간 매몰비용이 발생하며, 페이지 이탈에 대한 불안감을 줄 수 있다.
반면에 댓글을 원래 게시글 화면에서 작성할 수 있게 한다는 것(2번)은 본문을 조회하며 빠르게 댓글을 남기게 한다는 목적을 가질 수 있다. 하지만 사용자가 댓글에 온전히 집중하게 만들지 못할 수도 있다. 이처럼 각 케이스별로 장점과 단점이 각각 교환된다.
이를 통해 느낀 것은 제품에서 어떤 가치를 먼저 줄 것인지 명확해야 한다는 것. 그래야 이후의 선택들이 보다 쉬워질 수 있다. 이 반대면 어려워지는 것이고.
제품 서비스 기획의 본질은 '가치전달'로부터 시작된다는 것을 잊지 말자.
#3 상상하는 힘을 기르기
#사고 #기획 #화면설계
지금보다 더 주니어 시절에 화면을 그리는 것과 기획을 동시에 하는 것에서 한계를 느꼈다. 화면을 먼저 그리는 순간부터는 내 생각이 변하는 것에 맞춰 화면을 업데이트해 줘야 한다는 것이다. 화면과 생각의 동기화 과정을 기획의 초장부터 시작하는 것으로 인한 비용이 발생했다. (일을 두 번 하기)
이를 체감하고 난 뒤부터는 상상하는 힘을 기르고 있다. 그래서 현재는 기획을 할 때 머릿속으로 사용자의 흐름을 쭉 펼쳐놓고 형식으로 관련된 레퍼런스를 머릿속과 노션에서 뒤진다.
다만 이때 주의하는 것은 상상이 상상만으로 끝나지 않게 잘 기록하는 것이다. 상상은 무언가 혹은 누군가에게 공유될 때 비로소 존재의의를 가지기 때문이다.
상상이 글이나 말을 통해 세상밖으로 나온다면 이때부터 상상에는 살이 붙고, 구체화되며 상상하지 못했던 부분들이 메꿔지기 시작한다. 그리고 이 메꾸는 과정을 혼자가 아니라 타인과 함께 진행하면 더 온전하게 상상과 기획의 빈틈이 메꿔지는 것을 볼 수 있다.
화면부터 그리는 기획은 '디자인'을 함께 신경 쓸 수밖에 없기 때문에 기획의 힘이 분산되는 느낌이라면, 상상을 통해 머릿속으로 정리한 것을 글로 풀어내고, 풀어진 글들을 화면으로 다시 조립할 때 비로소 보다 질이 좋은 기획서가 나오는 것 같다.
아마 이렇게 여러 실험을 하며 나에게 더 적합한 기획 스타일을 찾아가고 있는 듯.
#4 사용자를 중독시키는 UX 전략
#UX #게이미피케이션 #매몰비용 #손실회피
게임 속에 쌓여있는 수많은 아이템들과 게임 머니들은 사용자가 투자한 시간과 노력을 대변한다. 현실에서는 손에질 수 없는 가상의 아이템일지라도 사용자는 자신이 달성한 것을 잃는 것을 극도로 두려워한다. 단기적으로는 저장된 가치가 생각나서 게임으로 돌아가게 되고, 장기적으로는 두려워서 게임으로부터 멀어지지 못하는 것이다. 이러한 현상을 매몰비용 감옥(Sunk Cost Prison)이라고 부른다. - 요즘 IT, '사용자를 중독시키는 'UX' 전략'
이번 주에 읽은 아티클 중 게이미피케이션, UX와 관련한 아티클이 있다. 가장 인상 깊었던 단어는 '매몰비용 감옥Sunk Cost Prison'이다.
인상 깊었던 이유를 생각해 보면, 1) 우리 주위에서도 많이 찾아볼 수 있는 사례기도 하고, 2) 이 단어의 근간이라고 생각하는 것이 내가 관심 있는 '손실 회피 성향'과 관련 있기 때문이다.
손실 회피 성향을 간단하게 말하면 '얻는 것으로 인한 즐거움보다 잃는 것으로 인한 고통이 더 크다는 것'이다. 내가 이에 관심 있어하는 이유는 운동, 글쓰기, 독서, 소통 등 나의 많은 습관을 이어가는 큰 원동력이 '쌓아 놓은 것을 잃기 싫음'으로부터 오기도 하기 때문이다.
손실 회피 성향이 크게 적용하는 사례는 우리 주위에도 많다. 대표적으로 회사에서 사용하는 노션, 컨플루언스 등 지식베이스 툴이 그 예다. 사용하는 기간이 길어질수록 아카이빙한 문서들이 많아진다. 이 때문에 서비스가 불편하더라도 데이터 이관에 대한 공포, 새로운 툴에 대한 적응 등 여러 전환비용으로 인해 꾹 참고 사용하는 경우가 많다. (전환비용의 뿌리는 사용자가 매몰시킨 비용이라고 말할 수 있다.)
그래서 이런 서비스에서는 빠르게 매몰비용을 만들 수 있는 전략을 취한다. 예를 들어 '문서 템플릿'처럼 문서 제작에 특화된 기능들을 제공하는 것을 말할 수 있다.
스스로 성장하고자 할 때부터 고객에게 제품을 제공하는 것까지 고의적으로 매몰비용을 만드는 것을 적절히 활용할 필요가 있다.
#5 재밌게 읽은 아티클(ft. 그로쓰해킹)
#아티클 #공유
1. 데이터, VOC, UT를 통한 개선 사례: 강남언니
요즘 IT에 나오자마자 읽었던 글이다.
길 가다가 한 번쯤은 접해봤을 성형수술, 피부수술 병원 중개 플랫폼, 강남언니와 관련된 글이다. 아래 공유한 아티클은 데이터+VOC+UT를 통한 개선 사례를 담고 있다.
글에서는 크게 1) 고객군을 카테고라이징하고, 2) 그들의 문제를 진단한 후에 3) 가설과 개선 지표를 설정한다. 이후에는 4) 실제로 실행을 하며 수집된 데이터로 가설 검증 여부를 판단하고 5) 성과를 정리하는 내용을 다룬다.
VOC를 통해 문제를 도출했지만 명확한 문제 진단이 불가능했기 때문에 UT를 따로 한 번 더 진행했다고 하는 부분이 인상 깊었다. 공감한 내용은 1) 자신의 감정을 명확하게 인지하고 말하는 사람은 드물다는 것과 2) 우리의 무의식적으로 불편함을 느꼈을 때 과정은 휘발되고 불편하다는 기억만 남는다는 것(이로 인해 텍스트로 내용을 전달받을 때는 더 명확한 진단을 하기 힘들어진다).
▼ PO가 비즈니스 전략에 제품을 녹이는 방법
https://yozm.wishket.com/magazine/detail/2301
2. 디스콰이엇
이 글은 디스콰이엇의 권도언 대표님이 제품을 운영하며 직접 경험한 그로쓰해킹의 사례를 다루고 있다.
나는 아래 내용에 집중해서 글을 읽었다.
1. 소셜 네트워크 모델의 디스콰이엇이 설정한 주요 지표와 제품 성장의 관계
2. 제품 성장의 적신호를 확인하고, 문제를 진단한 후 이에 대한 해결법(가설)을 세우는 것
3. 원 페이저 포맷의 문서 작성
운영 모드로 돌입한 제품의 그로쓰해킹을 다루는 것이라서 당장의 나의 상황에 대입하는 것은 쉽지 않겠지만, 제품을 만드는 메이커로서 알아두면 좋은 사례이라고 생각한다.
▼ 디스콰이엇 Operator가 주 평균 13.99% 성장을 만드는 법
https://disquiet.io/@kwondoeon/makerlog/성장을 만드는 법
#6. 컴업 2023 방문
#컴업2023 #COMEUP2023
컴업 2023 ⓒ 327roy