처음 프로젝트에 온보딩하는 기획자와 나누고 싶은, 이커머스 web 사이드 프로젝트 신입 기획자의 한달치 레슨런

 

이커머스 분야의 web 사이드 프로젝트에서 기획 파트를 맡아 일한 지 거의 한 달이 다 되어 간다.

프로덕트 상위기획, 상세기획까지 거의 완료되었고 요구사항정의서, 화면설계서 같은 기획 산출물도 만들었다.

Monthly Review를 위해 오늘은 그동안 프로젝트에서 배운 레슨런들을 리뷰해보려고 한다.

처음 이런 사이드 프로젝트에 참여해서 기획을 하는 사람이라면 기본적인 마인드셋이나 태도에 관해서 도움이 될지도 모르겠다. 

 

 

 

이렇게 일하고 있어요.

인원도 거의 20명 가까이 되고 온보딩부터 론칭 듀데이트까지 약 두 달을 목표로 작업 중이어서 굉장히 애자일하다.

장점은, 매일매일 개선하고 고민하다 보니 몰입력이 굉장히 높다는 것이고 단점은 백엔드에 빨리 넘겨주기 위해 급하게 작업하다 보니 화면설계서까지 작업해 놨는데 파트마다 기획의 아구가 잘 안 맞는다거나 디자이너, 개발자들이랑 회의하는 과정에서 꽤나 핵심 수준의 기능이 replace 되는 일도 있다는 것.

 

 

나름 소통 전문가라고 자부해왔지만...

초반에 상위기획할 때만 해도 기획을 내가 만족할 수준에서 완성하고 나서 다른 팀원들에게 공유하려고 했었다. 결론이 없거나 논리가 완전하지 않은 데 다른 사람들에게 공유하는 게 부끄러워서.

근데 PM이 전화통화로 지금처럼 사업개발하는 단계일수록 작은 인사이트라도 서로 공유해야 한다며 자주 공유할 것을 요청했다. 되게 뻔한 교훈 같지만 그때 엄청 크게 다가왔다. 원래 스스로 공유 잘한다고 생각했었지만 나에게 공유는 docx파일, 즉 완전한 형태일 때 주로 하는 것이었기 때문에.

 

사실 유니크하면서도 현실적인 사업전략을 혼자서 A to Z 기획하려고 하면 골치 아프고 쉽게 결론이 안 나는 게 당연한 거 아닌가? 그걸 혼자서 다 하려고 한 나도 참. 또 결론까지 완벽하게, 길게 가지고 오면 회의할 때 그 사람의 의견을 반박하는 것도 더 머쓱해진다.

 

이후 PM이 프로덕트 관련 주제로 지인을 인터뷰하고 인사이트를 3~4줄로 정리해서 슬랙에 공유했는데, 그 질문들을 참고해서 내가 지인들 대상으로 유저 인터뷰를 했고 여기서 얻은 인사이트를 나도 바로 공유했다. 이런 과정이 프로덕트의 방향성 정하는 데 도움이 됐다.

 

그래서 내가 이 포인트에서 배운 것은, 현재 아이데이션이 중요한 단계라면 더더욱 자주 팀원들과 아이디어나 인사이트를 공유할 것. 결론이 완전하지 않더라도.

 

 

 

 

 

줏대 있는 기획자가 되어야 해

화면설계서 가지고 세부 기능 기획할 때도 놓치면 안 되는 서비스 정의와 타겟 페르소나.

보통 상위기획 할 때 ...-> 유저 페르소나-> IA/메뉴트리 -> 요구사항정의서 순서대로 진행하지만, 우리는 타이트한 일정으로 인해 고객의 Painpoint와 서비스 컨셉 등을 정의하고서 기능정의에 대한 논의를 간단하게 생략하고 IA 문서 작성 없이 바로 와이어프레임과 요구사항정의서 작성으로 넘어갔다. 이렇게 유저와 주요 기능들에 대한 촘촘한 얼라인 없이 냅다 와이어프레임부터 그리다 보니 문제가 발생하는데.. !

 

유저 페르소나에 대한 학습이 부족하다 보니 기획사항을 의사결정할 때 확신이 없는 것이었다.

예컨대 디자이너분들은 보통의 이커머스 서비스가 제품 상세페이지에서 다른 옵션 보기를 기본 정보 밑에 배치하니까 우리도 그렇게 하자고 주장했는데, 나는 '보통 그렇게 한다'라는 설명을 듣고 설득을 당해서 상단에 배치하는 데 협의했다.

 

그런데 다시 기획회의 때 리뷰해 보니까 '우리 서비스의 핵심 가치를 고려할 때는 ㅇㅇ기능이 스크롤하지 않는 화면에서 먼저 보여야 한다. 그래야 유저들이 처음 이 화면에 들어왔을 때 이 서비스는 뭐가 다르구나 라는 걸 느낄 것이다. 그러니 다른 옵션 보기는 후순위라 밑으로 내려가야 한다.' 라는 결론이 나왔다.

 

이 회의를 통해 기획자가 서비스의 핵심 가치를 항상 되새기면서 작업해야 한다는 소중한 깨달음을 얻었다. 줏대 없는 기획자라면 디자이너나 개발자의 각기 다른 의견에 휩쓸려서 매번 고개를 끄덕이며 정체성이 중구난방인 기획을 하게 될 것이다. 뭐가 중요한지도 모른채.

 

이게 최선의 기획인가?를 끊임없이 의심하기

IT 프로덕트 기획은 '유저들이 생각한 그 곳에 그 기능이 있어야 한다'라는 내용의 강의를 들은 적이 있었다. 전통적인 제품에 비해 이탈이 참 쉽기 때문이다. 대부분의 앱들은 검색창이 상단에 있고, 마이페이지는 하단 네비게이션바의 우측에 있고 상품 리뷰는 맨 하단에 있는 것처럼. 이렇다 보니 나도 와이어프레임 작업할 때 올리브영이나 11번가, SSG 같은 유사한 서비스들을 수없이 들어갔고 많이 참고했지만, 동시에 새로운 위치에 새로운 기능을 넣는다는 생각을 잘 안하게 되기도 했다.

 

아래는 앞서 이야기한 '다른 옵션 보기의 위치' 에피소드에서 더 이어지는 내용이다.

그러면 우리 서비스는 다른 옵션 보기는 하단에 배치하는 걸로 할게요. 하고 회의가 넘어가려는 순간,

누군가 '하지만 유저들이 다른 옵션보기가 보통 상단에 있을 거라고 기대한다면..' 하고 입을 열었다.

타협인 줄 알았는데, 새로운 아이디어였다.

 

'상품명 옆에 다른 옵션 보기'를 넣어주면 어떨까요?'

 

다른 이커머스 앱/웹을 쓰면서 한 번도 본 적 없던 위치여서 듣는 순간에는 엥? 이라는 반응이 먼저 올라왔지만,

서비스 방향성을 해치지도 않고, 디자인적으로도 잘 풀어내면 자연스러운 기능이 될 수 있는 아이디어였다.

 

이렇듯 관습을 깨는 아이디어가 참 좋다고 생각했다.

이 아이디어는 나에게 기존의 플로우, 기존의 위치라는 내 머릿속의 라인을 넘어가야 겠다는 다짐을 하게 해준 계기였다.

 

여기서의 레슨런: 관습적으로 작업하지 말고 이게 최선의 기획인지, 그냥 작동을 하게 만드는 기획은 아닌지 생각하자.

 

 

 

기획자는 기획의도로 말해요.

수십번 고치면서 정성껏 작성한 화면설계서를 들고 디자이너들이랑 회의를 했다.

개발자를 위해 기능이 어떻게 작동하는지, 어떤 데이터가 필요한지 정말 길게 열심히 써놨지만

정작 디자이너를 위한 기획의도가 부족했다.

 

아무래도 기획회의에서 '이 기능은 이런 것이구요, 왜 필요해요.' '유저는 이런 생각을 하면서 이 기능을 쓸 거에요.'라고 우리끼리 이야기하면서 이미 좋습니다 그렇게 합시다 탕탕탕 하고서 이 기능이 필요한 이유를 납득했기 때문이다.

 

기획의도는 이미 충분히 전달되었다고 생각하고, 안 그래도 긴 디스크립션, 불필요한 건 조금이라도 지우겠다는 마인드로 문서를 다듬었기 때문이다.

 

하지만 안타깝게도 기획회의 때 참석하지 못한 디자이너도 있었고, 설사 참석했더라도 방대한 양의 기능과 화면을 작업하다 보면 '이 기능이 왜 여기에 있지?' 같은 것들을 당연하게도 잊어버리곤 한다.

 

기획의도를 잘 써놓으면 디자이너분들은 기획의도를 잘 살릴 수 있는 디자인을 해주신다. 때로는 기획의도를 바탕으로 완전 다른 그래픽을 가져오시기도 하는데 역시 파트 상관없이 모든 팀원들이 기획에 어느정도 인게이지 하는 팀이 훨씬 좋은 결과를 만든다는 걸 다시금 느끼면서, 기획자는 기획의도라는 방향키를 잘 쥐고 소통해야 한다는 것을 깨달았다.

 

한편 세세한 기능, 그중에서도 '공유하기'처럼 너무 당연히 필요하고 의문도 들지 않을 것 같은 기능들도 왜 존재하는지, 사용자들이 어떻게 쓰길 바라는지 기획의도를 써야했다.

예컨대 사용자들이 상품이 딱 2시간만 특가니까 빨리 지인들한테 공유해야지 라고 생각하면서 공유를 하기도 할 것이고, 올웨이즈처럼 공동구매를 해야 가격이 싸지니까 지인들에게 알려야지 라고 생각하면서 공유를 하기도 할 것이다. 그 상황에 따라 카카오톡 채팅방에 공유를 완료했을 때 나타나는 메시지나 정보의 배치도 달라져야 한다. 우리 서비스의 유저들은 이중에 어떤 상황에 해당하는지 생각하면서, 웹 밖으로 나가는 문구와 배치도 기획의도와 함께 작성해야 한다는 것을 배웠다.

 

 

---

요새는 web 기획은 거의 마무리 중이지만 디자이너분들이 작업하신 와이어프레임을 가지고 더 나은 UI/UX와 로직 등을 고민하며 여전히 매일매일 수정중이다. 정말 기획문서만 만들면 끝이 아니라 거기서부터 시작이라는 걸 배워나가고 있다.