[세균무기기가말하는 서비스 기획의 모든 것] 책을 읽고
사용자의 대상이 웹페이지나 모바이 화면은 주니어 기획자들도 경쟁 서비스를 벤치마킹하면서 잘 기획한다. 그런데 백오피스 또는 어드민 사이트라고도 불리는 관리자 사이트는 벤치마킹을 하기도 어렵고 공개된 자료도 찾기 쉽지 않다보니 기획하기 힘들어한다. 대다수 메뉴 페이지에 동일하게 적용할 수 있는 하나의 UI구조를 제대로 설계하는 것이 중요한다.
대다수 관리자 웹 사이트로 제공된다. 따라서 모니터의 크기나 운영자의 사용 방법에 따라 관리자 화면의 크기가 유동적으로 바뀔 수 있다. 따라서 변경되는 화면의 높이와 너비에 관리자가 대응할 수 있도록 기획해야 한다. 결국 가로스크롤과 세로 스크롤이 생길 수 밖에 없다.
그런데 관리자는 무조건 편의성만 고려할 수 없다. 관리자의 특성으로 인해 의도적으로 불편한 사용성ㅇ르 갖도록 기획하게 된다. 이런 점이 사용자가 사용하는 클라이언트 기획과 운영자가 사용하는 관리자 기획의 차이라고 할 수 있다. 그래서 관리자 UI는 무조건 편해야 하지만 UX는 때로는 불편할 수 있다.
-> 백 오피스 디자인을 하면서 왜 기존의 백오피스 관련 서비스들이 안 이쁘고.... 이렇게 구식으로 계속 가고 있는걸까... 왜 업데이트를 안하는 걸까?? 궁금증만 가지고 있었다.
그런데, 백오피스 디자인 4개월차 ..... 왜 이렇게 밖에 할 수 밖에 없고, 다 비슷한 구조를 가져갈 수 밖에 없는 이유를 레퍼런스를 참고해보고 나 또한 기획해보고 디자인 설계를 하면서 많이 배우고 있다. 아..... 이렇게 할 수 밖에 없는 이유가 있구나....
관리자의 고객은 회원과 달리 바로 내 옆자리에 앉아 있는 동료다. 그래서 현장의 상황과 목소리를 반영하며 동료들이 편하고 쉽게 운영할 수 있도록 요구사항을 잘 정리하고 기획하는 것이 중요하다.
-> 실제 이 서비스를 사용하는 user는 우리 회사 동료들이다. 주로 업무와 물류쪽에 일하시는 분들을 위해... 그래서 그들이 주로 어떻게 사용할지, 무엇을 위주로 볼 지, 기존 서비스에서 불편했던 점들이 무엇이었고, 어떻게 일하고 계신지를 관찰하고 보고를 들어보는 게 가장 중요했다!
기획자가 서버의 구성이나 구조를 이해할 필요는 없지만, 기획이나 데이터 분석을 위해 서버의 DB아키텍처, DB 테이블, 데이터에 대한 이해는 필요하다 .
테스트 시나리오나 테스트 케이스의 작성도 전문적인 지식이 필요하다.
-> 백오피스를 하면서 내가 프로덕트 디자이너가 아닌 우선 UXUI디자이너로 입사하길 잘했다고 생각한 점이 이 데이터 구성과 구조를 아직 모르기 때문이다. 내가 생각하고 바라보고 있는 프로덕트 디자이너는 데이터도 볼 줄 알고 분석을 할 줄 알아야 하기 때문이다. 하지만...나는 아직은 미숙하다.
전에 토스 디자이너님이 강의 하신 걸 듣고 온 적이 있는데, 저 분은 왜이렇게 엑셀을 잘 하시고 이걸 분석하시지?? 나는 전혀 엑셀을 못하는데... 이런 정리는 도대체 어떻게 하는 걸까.... 막연하게 바라보기만 했는데... 내가 프로덕트디자이너로 들어오지 않고 UXUI디자이너로 입사한 게 큰 도움이었다고 생각한다. 같이 일하는 서비스 기획자를 보며 내가 프로덕트 디자이너로 성장하기에 부족한 자질이 무엇이고 무엇을 공부하면 될지, 인지할 수 있게 되었다.
그러나 실제 기획자의 업무는 매니저와 오너라기 보다는 프로덕트를 함께 만들어가는 디자이너, 개발자 등의 동료들이 업무에 집중하고 효율적으로 일하며 좋은 제품을 만들 수 있도록 돕는 역할에 가깝다 (->PM)
기획자는 프로덕트와 관련하며 의사결정을 하는 직군이라고 해도 틀린 이야기가 아닐 것이다.
-> 내가 고민하는 포인트가 여기다. 나는 좋은 제품을 만들고 이끌어보고 싶다. 그것이 PM이고 PM의 역할이 서비스기획자라면 나는 기획자가 되고 싶은것인가? 라는 생각이 드는 것이다. 근데, 디자인도 너무 좋다. 전 회사 PM님이(연세가 있으신...) "디자이너는 PM되기 어려워.... "-> 거의 하면 안된다는 식으로 말을 하셔서 기분이 좋지 않았다. 예전 디자이너의 역할의 제한된 범위에서만 아직 머물고 계시는구나... 나는 프로덕트 디자이너가 충분히 프로덕트 매니저의 역할도 할 수있다고 생각하기에 오기가 생기기도 했다. 그래서 UXUI디자이너에서 더 넓은 확장된 사고를 하는 프로덕트 디자이너로 성장하고 싶은게 목표 지점이 되었다.
-> UXUI 디자이너와 프로덕트 디자이너, 비슷하지만 난 확실히 기획의 범위, 매니징의 범위에서 차이가 있다고 생각한다. 그렇기에 나는 진정한 프로덕트 디자이너가 되고 싶고, 이 고민이 축적되고 쌓아가며 프로덕트 디자이너에 대한 책도 써내려가고 싶다. 가이드를 제시해주는 사람이 되고 싶어졌다. 나만 이렇게 심각하게 고민하지 않을텐데...?? 다들 고민할텐데...?? 왜 없을까? 왜 딱히 구분이 없다고 할까? 난 구분이 있다고 생각하는데....
바야흐로 데이터의 시대다! 기획자가 사용자의 요구사항을 이해하고 서비스를 개선하며 성장시키려면 데이터 주도적 기획(Data -Driven Planning)이나 서비스 분석이 중요하다는 이야기를 귀가 따갑도록 들어왔을 것이다.
그렇다면 기획자는 어떻게 데이터 주도적 기획을 하고 서비스 분석을 해야할까?
고민할 필요없다. 왜냐면 할 수 만 있다면 이 모든 것을 다 해야하기 때문이다. 고민이 필요하다면, 현재 상황과 리소스에서 할수 있는 것이 무엇인지 판단하며 우선순위를 정하는 것이다.
기획자는 화면 기획을 통해 서버에 쌓이는 로우 데이터를 정의한다.
가설을 수립하여 실험을 하는데 이 실험을 위해 퍼널 분석과 A/B테스트를 진행하게 된다. 이 과정을 그로스 해킹이라고 한다.
-> 이직을 준비하면서 약점이 데이터였다. 데이터드리븐 사고를 요구하는 회사가 많다는 거... 목표회사는 다 그렇다는 거...하지만 작은 스타트업은..... 오래된 중견기업은.... 데이터를 보나..?? 우리가 목표하는 데이터 사이언스가 있고, 테스틀 할 수 있는 데이터를 볼 수 있는 회사가 과연 얼마나 많을까?? 그러한 회사에 소속되어 있으면 참 좋겠지만.... 그렇지 못한 회사에 속해있는 디자이너들이 참 많다. 나 또한 그랬다. 아무리...포장을 해보려고 해도, 안하고 보는 사람도 없는데... 내가 무작정 GA를 독학하고 데이터를 보려고 강의도 보고 해도....실전이 없으면... 내 포폴은 미약해진다....
AI와 빅데이터 시대라고 이야기할 만큼 많은 면접관들이 Deep-Dive한 경험이 있냐고 묻는다. 고객의 요구사항을 파악하고 데이터 중심의 의사결정을 하겠다며 데이터를 분석하기 위해 분석 환경을 구축하고 지표를 생성하며 대시보드를 만든다. 아직 버그와오류 투성이의 VOC가 쏟아지고 있는데도 말이다. 데이터가 중요하다지만 Data -Driven과 Customer-Driven은 다른데 지인이나 얼리어답터 등의 소수 데이터를추출하고 지표를 만들면서 고객 중심적인 의사 결정과 운영을 하고 있다면 자랑한다.
데이터는의사결정을 위한 수단 중 하나라는 사실을 잊어서는 안된다. 'Data-Driven'과 'Customer-Driven'이 일치하지도 않으며, 데이터는 미래의 잠재 고객을 대변하지도 않는다.
-> 기획자도 이걸 요구 받는지 이 책을 보면서 느꼈고, 정말 프로덕트 디자이너랑 업무가 겹친다고 생각이 들었다. 그래서 데이터드리븐사고에 대한 고민이 많은 기획자나 디자이너가 많을 거라 생각이 들었다.
-> 그러던 중 위 문구가 상당히 와닿았다. 데이터도 중요하지만, Customer-Driven도 더 중요하다는 점! 데이터가 답은 아니다라는 말!!
-> 현재 내가 백오피스를 디자인 설계하면서 런칭을 준비하고 있는데, 알다시피 런칭은 데이터가 없다. 오랜기간 쌓여하고 내년에 출시하고 나면 회사 사람들의 의견을 충분히 듣고 고도화를 할 계획이다. 데이터 드리븐 사고도 중요하지만 VOC를 잘 듣고 고객(회사동료)중식적인 의사결정을 중요하게 해도 되겠구나 하는 희망이 생겼다!