책으로 배우는 것에 한계를 느껴서 멘토가 필요하다는 생각이 들었다. 멘토를 통해 가볍게라도 문서를 작성해보면 큰 틀을 파악할 수 있을 것이라 생각했다. 코멘토라는 사이트를 통해 직무부트캠프를 통해 5주 동안 현직자의 피드백을 받으며 서비스기획자가 어떤식으로 사고하며 문서를 작성하는지를 배우는 좋은 기회가 되었다.
수업 내용은 미션 과제를 작성하는 방식으로 진행이 되는데, 아무래도 서비스의 문제점과 개선사항을 수정하기 위해서는 내가 자주 사용하는 서비스여야 한다고 생각이 들어서 자주 사용하는 어플인 yes24로 선정하게 되었다.
비즈니스모델분석부터 스토리보드까지 직접 작성해보았다. 경영적인 부분을 잘 알지 못해서 고민을 많이 했는데 현직자의 도움을 받으면서 어떤 부분을 고민해야 하는지를 알 수 있었다.
전반적인 내용을 작성하고 나니 아직 부족하지만 어떤식으로 생각을 해야하는지 알 수 있었다.
1. 비즈니스 모델 분석
비즈니스 모델 분석하기 위해서는 다양한 부분을 고려해 보아야 한다. 고객분석부터 기업분석까지! 내가 생각할 때 이 부분에서 기획자의 시야가 넓고 분석적인지 알 수 있는 것 같다.
YES24같은 경우에 특이한 점은 구매자가 판매자가 될 수 있다는 것이다. 중고책의 경우에 그러한데, 구매자가 중고책을 판매하는 경우에는 직접 서점에 판매할 수 있거나 다른 소비자에게 판매할 수 있는 구조로 이루어진다.
이외에도 YES24는 온라인 서점이 메인이지만 사실 그 외에도 음반, 영화, DVD, 문구 등 다양한 상품들을 제공하고 있고 이 과정에서 다양한 파트너들과 관계를 맺고 있다.
내가 생각할 때 YES24의 경쟁력은 소비자와의 관계에 있다. 다른 서점과 다르게 YES24는 기술적인 측면이나 UI, UX측면이 부족하더라도 소비자에게 많은 혜택을 제공하려고 노력하고 있다. 저렴한 가격이나 혜택 등을 다른 서점에 비해서 많이 제공하고 있고 이러한 점 때문에 온라인 서점 1위라는 입지를 다지고 있는 것 같다.
2. 문제점
내가 생각한 문제점들과 사용자 테스트 그리고 여러 리뷰들을 검토해서 어피티니 다이어그램이나 우선순위 표를 이용해 다양한 문제점을 도출해냈다.
먼저, YES24는 서비스 플로우가 복잡하고 눈에 제대로 띄게 되어 있지 않아서 사용자가 사용하는데 굉장히 불편하다. 사용자 테스트를 시행해 본 결과, 서비스를 제대로 이용하거나 편리하게 이용하지 못한 유저들이 보였다. 사용성테스트를 통해 유저들이 원하는 책이 없을 경우 자신이 원하는 분야로 넘어가게 되는데 이 때 분야를 찾는 것이 어렵다는 것이다. 카테고리를 찾기 쉽지 않게 구성이 되어 있었다.
두 번째로 서점에서는 장바구니와 찜 기능이 다른 분야보다 중요하다고 생각하는데 이 부분이 편리하지 않다는 점이다. 중요하다고 생각한 이유는 책은 나중에 읽어야지 하고 구입하는 경우인 재구매율이 높다고 생각했기 때문이다. 나중에 주문하기라는 모호한 용어와 나중에 주문하기 목록이 맨 하단에 배치되어 이용성이 떨어진다는 것이고 로그인 없이 나중에 주문하기 기능을 사용하게 되면 지금까지 저장해왔던 책들이 다 사라지게 된다는 점이다.
나중에 주문하기라는 단어가 보통 찜으로 사용이 되는데 나중에 주문하기라는 단어를 처음 접했을 때 도대체 무슨 기능일지 파악이 잘 되지 않고, 찜 목록 대신 나중에 주문하기 목록이 가장 하단에 배치가 되는데, 과연 이 기능을 이용하는 사람이 얼마나 될까? 찜 목록이라고 하면 아직 사진 않지만 살 의향이 있다는 책들의 집합인 곳인데, 나중에 주문하기 목록 이라 해버리면 찜 목록 보다는 직관적으로 와 닿지가 않는다. 그것도 맨 하단에 배치해버리면 있는지도 모른다; 그래서 그 부분을 우측 상단에 배치하는 게 제일 중요하다는 판단이 들었다. 또한 로그인 없이 나중에 주문하기를 눌러버리면 상품들이 다 사라져버리는데; 심지어 나중에 주문하기 목록에 가지도 않는다; 이 경우 로그인 없이 이용한 유저들은 황당할 수밖에 없다. 따라서 그런 경우를 방지하기 위해 찜 목록을 사용하기 위해서는 로그인 서비스로 바로 이동할 수 있도록 수정해보았다.
이를 해결하기 위해 분야 카테고리를 눈에 띄게 배치하고 용어와 색상 변경을 했다. 또한 나중에 주문하기 대신 찜이라는 용어로 바꾸고 나중에 주문하기 목록을 찜 목록으로 우측 상단에 배치했으며 로그인 없이 찜 기능을 사용하려고 하면 로그인을 하도록 유도하는 창을 띄웠다.
3. 요구사항 정의
비즈니스모델을 분석하고 서비스 흐름도 파악하고 문제점을 다각도로 파악한 다음 해야 할 일은 요구사항정리다. 이 부분이 사실 책을 읽을 때 무슨 말인지 파악하기 어려웠는데 막상 그리 어려운 부분은 아니었다.
좀 재밌다고 생각한 부분이 요구정의의 가설을 정리하는 것이었다. 사실 평소에 "이렇게 되면 이러한 일이 발생하지 않을까?" 라는 지적 호기심이 많은 편이라 가설을 정리하고 실험에 보는 게 재밌었다. 물론 과제 단계에서는 내가 직접 지표(데이터)를 검증할 수 없었기 때문에 아쉬웠지만 그래도 이러한 기획을 정리하는 것만으로도 재밌었다. 그래도 확실히 이 부분은 공부를 더 하면서 객관적으로 생각하고 인사이트를 도출해 낼 수 있도록 노력해야겠다.
그리고 가설 부분이 확실히 논리적으로 정리되는 경우가 많은데 대학 때부터 몇 년 동안 논리학 공부를 했기 때문에 간만에 논리를 써서 좋았다ㅠㅠ
실행단계에서 어떻게 할 것인지 admin부분과 api를 적는 부분이 있는데 이 부분은 개발적인 지식이 없다면 정리하기 어렵겠다는 생각이 들었다. 그래도 틈틈히 IT책을 봐서 그런지 아예 모르진 않았고 용어가 이해가 안 되지도 않아서 다행이었다. 그러나 이 부분은 내가 조금 부족하다는 생각이 들었다. 정리하면서도 놓치는 부분이 있는 것 같아서 찜찜하기도 했고 개발자들을 만나거나 실무를 하게 되면 이 부분을 좀 더 보완할 수 있을 것 같다.
4. 스토리보드
스토리보드도 작성을 해보았는데 사실 와이어프레임을 사용하지만 이미 서비스가 이루어진 앱이라 그 부분을 캡쳐해서 이용해도 될 것 같다는 생각이 들어서 디스크립션과 함께 이 부분을 작성해보았다.
5. 피드백
피드백을 크게 두 가지를 받게 되었는데
요구사항1. 요구정의서에서 핵심지표가 제대로 쓰여졌는지/카테고리를 들어갈 또 다른 방법은 없는지
요구사항2. 찜 기능 자체에 대한 검토/ 카트에서 찜 기능에 대한 의문
내가 문제를 정의할 때
요구사항1. 하위분야를 잘 들어가기 위해서 하위분야라는 용어를 카테고리로 변경하고 좀 더 눈에 잘 띌 수 있도록 모양이나 색을 개선했었다. 이 때 핵심지표를 구매전환율로 잡았는데 내가 의도했던 바는 하위분야라는 버튼에 들어가서 책을 구매하게 한 비율을 올리는 것이었다.
이때 내가 잘못 생각한 포인트는, 클릭률과 구매전환율에 대핸 차이를 제대로 구분하지 못했던 것. 구매전환율이 단순히 이전 구매율과 이후 구매율을 비교해서 구매가 더 증가했다라고 생각했다. 기준 자체가 잘못된 것이었고 구매전환율이라는 건 결제까지 마무리된 비율이기 때문이다. 내가 용어를 변경하고 색, 모양을 바꿨다면 실질적으로 직접적인 핵심지표는 그 버튼의 클릭률을 봐야 제대로 결과를 측정할 수 있다. 이 부분에 대해 좀 더 정확히 알 수 있게 되었고 핵심지표를 최종적인 목표로 생각해서는 안 된다는 것. 정확히 따지면 클릭률이 증가함에 따라 결제율이 증가할 수는 있지만 이러한 간접적인 것을 핵심지표로 삼으면 안 됨!!!
두 번째는 기존의 용어 변경 말고 카테고리를 들어갈 방법이 없는지 고민해보라는 조언이셨다. 다른 앱들을 참고해 본 결과, 햄버거 메뉴를 통해서 카테고리를 다시 쉽게 들어갈 수 있게 해놓았다는 것을 깨닫고 이 부분을 수정했다. yes24의 경우 스크롤을 내릴 경우 네비게이션바가 움직이고 있어서 이 부분을 고정시켰다. 또한 이 바를 이용해서 전체 메뉴를 들어가도 카테고리가 크게 분류 되어 있어 세부적인 카테고리 내용을 이해하기 쉽게 한 분야의 아이콘을 활성해 놓았다. 그 이유는 한 아이콘을 활성화 시켜 놓으면 다른 분야도 클릭하면 세부적인 카테고리 내용을 볼 수 있다고 생각했기 때문이다. 리소스를 줄이면서도 문제를 해결하고자 했다.
요구사항2. yes24의 나중에 주문하기 클릭버튼을 좀 더 잘 이용할 수 있게 찜이라는 용어로 변경하고 목록의 위치를 바꾸는 것이었다. 피드백은 찜 기능 자체에 대한 검토인데 내가 중점을 둔 부분은 카트에서 yes24는 나중에 주문하기라는 버튼이 있어서 그 버튼을 찜용어로 바꾸고 찜이라는 것 자체가 나중에 구매한다는 의미라고 생각을 했다. 그런데 멘토님께서 찜기능을 사용하는 것은 처음에 카트 들어가기 전에 사용하는 것이 아니냐는 의문이었고 이 부분에 동의를 해서 그전에 찜 기능을 추가를 했다. 이 부분에서 찜이라는 용어를 변경하게 되면 찜 기능이 가지고 있는 뜻이 무엇인지를 고민해보고 자체 플로우가 검토될 수 있다는 부분을 알게 되었다. 조금 충격이었다(?) 용어 자체를 바꿈에도 전체 기능을 고민해야 하는 구나..!
또한 페이지마다 가지고 있는 의미가 있었다. 결제 페이지 같은 경우는 무언가를 추가하는 게 아니라 덜어내야 한다는 것도 앞으로 내가 주의깊게 봐야할 점이라는 것을 깨달았다. 멘토님 주장에 따르면 카트에서 찜 기능은 사실 사용할 것인지 의문이 든다는 것인데 카트라는 페이지가 덜어내는 페이지라는 말씀이었다. (그런데 내가 생각할 때는 만약 카트에 들어와서 찜기능이 없다면 책을 일단 카트에 넣어놓고 고민하다가 책을 빼거나 찜으로 넣는 사람이 있을 텐데, 찜으로 넣게 되면 재방문율을 올릴 수 있다고 생각했다. 반면 책을 빼게 되면 다시 들어올 확률이 낮게 되니까 카트에서도 그 기능이 필요하다고 생각이 들었다.) 이 과정에서 배운 생각은 각 페이지마다에도 목적이 있기 때문에 그 부분까지 고려해서 기능을 추가할지 빼야할지를 정해야 한다는 사고에 대해 배울 수 있어서 좋았다.
6. 배운 점
이번 과제를 하게 되면서 전반적인 서비스기획자가 어떻게 사고하고 어떻게 문서를 작성해야 하는지를 배웠다. 이를 통해 알 수 있었던 나의 장점은 고객 중심으로 보는 관점이 있는 것 같고 다양한 관점에서 문제를 파악하고 해결하려고 했다는 점이다. 반면 나의 단점은 아직 개발적인 부분에 대한 문서 정리 능력이 부족한 것 같고 가설에 대한 검증이 이뤄지지 않아서 지표에 대한 객관적인 분석과 결론을 내본적이 없어서 능력이 검증되지 않았고 부족할 수 있다는 것이다.
피드백을 통해 배웠던 것은 포트폴리오를 작성하는 입장에서 인사이트 측면을 정리해줄 필요가 있다는 점이다. 왜 이렇게 기획했는지 멘토님이 물어보셨는데 그러한 부분이 기획자의 기준이고 판단력이기 때문에 의사소통을 할 때 중요할 수 있겠다는 생각을 했다.
'IT planning' 카테고리의 다른 글
| IT기획 이론편 (Ref, 탈잉) (0) | 2021.11.04 |
|---|---|
| 기획자의 자세 (0) | 2021.11.04 |
| 역기획 도전 2 (0) | 2021.11.04 |
| 역기획 도전 실패 요인 (0) | 2021.11.04 |
| <비전공자를 위한 이해할 수 있는 IT지식> 후기 (0) | 2021.11.04 |