2. 서비스 기획을 위해 알아야 할 것들
2-1.
아이디어 ≠ 서비스 기획
•
프로덕트는 프로젝트에 의해 만들어지는 산출물이다. 프로젝트는 프로덕트가 만들어지는 과정
•
프로덕트 한명의 이용자가 하나의 목표(또는 과업 Task)를 수행할 수 있도록 하는 기능의 묶음
•
서비스 기획에서의 서비스는 특정 목적을 가지고 있는 유저가 목적을 이룰 수 있도록 도와주는 프로덕트의 전체
•
서비스 기획자와 프로젝트 관리자의 차이점은 프로젝트를 서비스의 생애주기를 관리하기 위한 하나의 수단으로 진행함.
◦
도입-성장-성숙-쇠퇴 4가지 사이클을 이루며,
◦
적절한 시장 진입을 통해 빠르게 성장시키고 성숙기를 늘려 최대한의 이익 창출
◦
위 사이클의 단계에 맞춰 끊임없이 프로젝트를 진행
전략 기획과 서비스 기획 모두가 필요하다
•
전략 기획자는 방향성에 집중, 서비스 기획자는 구현에 집중
•
전략 기획은 경영전략 이론을 기반으로 4P 마케팅 믹스, 3C 분석, STP전략, SWOT분석 등을 바탕으로 어떻게 자사 역량을 극대화 하여 ‘지속가능한 경영’을 할 것인지를 목표로함
•
서비스 기획자는 전략 기획단에서 만들어진 수익 모델이 잘 작동할 수 있도록 구조로 설계하고 구현하는 사람 즉 말과 공식으로 되어있는 비즈니스 모델을 웹/앱 서비스 내에서 작동할 수 있는 시스템으로 설계하는 일을 기획함.
•
서비스 기획자와 전략 기획자의 생각이 정확하게 소통되고 컨센서스를 이루지 못한다면, 구현 과정에서 전략이 희석되기 쉽다.
◦
이런 문제를 최소화 하기 위해 전략 기획과 서비스 기획을 함께하는 방식으로 ‘디자인씽킹’, ‘사용자 중심설계UCD’가 있음.
◦
위 방법론은 전략이 아니라 고객의 Pain Point를 발견하는 것에서 출발하여 어떻게 가치를 전달할 것인가 구체적인 설계를 하는 프로세스 중심의 방법론.
◦
산출물 자체가 목업형태의 프로토타입으로 단기간에 아이디어를 보여줄 수 있어 기존의 전략기획 보다 서비스의 형태를 구체적으로 표현하기 때문에 아웃풋을 쉽게 예상할 수 있다.
서비스 성장을 고려한 서비스 기획
•
제대로 된 비즈니스 모델이 되기 위해서는 순환구조를 만들어 내야 함.
◦
과거 서비스는 대부분 공급자가 수요자에게 일방적으로 제공하는 파이프라인 형태로 이뤄졌다. 때문에 서비스가 좋고 마케팅 비용을 많이 투자하면 유입 트래픽이 증가, 서비스가 나쁘면 트래픽 감소
◦
웹 2.0이 보편화 되어 SNS를 통해 모든 서비스가 자신의 영역 밖에서 공유, 연결 되면서 서비스의 성장 공식도 바뀜
▪
SNS를 통해 재생산된 정보를 ‘네트워크 효과’ 라고 하며 이는 서비스의 성장을 가속시키기도 감소시키기도 한다.
▪
서비스의 품질만큼 관계성도 중요해지고 고객의 자연스러운 유입과 성장이 가능해졌으며 이런 서비스 구조를 ‘플랫폼’이라고 부른다.
•
플랫폼은 말 그대로 기차역과 같다. 가만히 있어도 사람이 오가며 기차를 이용하는 기차역처럼 플랫폼 서비스도 사용자들이 알아서 가치를 만들어 낸다. 사용자들이 만들어내는 가치가 커지면 플랫폼의 가치도 커지고 자연스럽게 규모의 성장이 일어남.
•
자생적으로 작동하고 성장하는 플랫폼 서비스를 만들려면 네트워크 구조를 고려해 이용 및 유입을 순환시키는 구조로 설계해야함.
•
대표적인 순환구조 제프 베조스가 그린 ‘아마존의 플라이휠’ 이 그림은 비즈니스 모델이 작용하면서 서비스가 성장하는것을 설명한다.
플라이 휠
•
비즈니스 모델이 작동하고 자연스럽게 성장하는 서비스를 설계하려면 비즈니스 모델과 선순환 구조가 자연스럽게 녹아 들어간 시스템을 기획해야 한다.
서비스는 고민의 깊이가 중요하다.
•
아이디어를 서비스로 만들기 위해, 서비스를 성장시키기 위해 디지털 환경을 이해하고 노력한다면 분명 같은 고민을 할 수 밖에 없다. 서비스를 성공으로 이끈 사람이 누구든 서비스 기획적 측면에서 고민을 깊게하고 노력했을 것이다.
2-2. 서비스는 프로젝트에서 탄생한다
•
프로덕트는 서비스로 나타나는 ‘산출물’ 자체
•
프로젝트는 그 프로덕트를 만들어내는 ‘과정’
•
프로덕트는 목표이자 결과가 되고 프로젝트는 그 목표를 이루기 위한 과정이 된다.
•
서비스를 고민하는 부분이 서비스 기획자의 역량과 자질이라면 프로젝트를 순조롭게 진행하는 것은 스킬의 영역이다. 프로젝트에 참여해 진행하는 방법을 모르면 원하는 서비스를 만들어낼 수 없다.
프로젝트의 정의
•
평소에 진행하는 일상적인 업무가 아닌 일정 기간 목표를 위해 추진하는 특수한 업무.
•
해당 책에서 다루는 프로젝트는 ‘기획-디자인-개발-테스트-오픈’의 단계를 ‘기획자, 디자이너, 개발자'라는 최소 세개의 직군이 함께하여 IT 시스템으로 서비스를 함께 만들어내는 협업 업무
워터폴 프로젝트 방법론과 애자일 사상
•
애자일 방법론의 핵심적인 골자는 기존 워터폴 방법론의 선형적인 프로세스가 빠르게 변화하는 IT 세상에는 적합하지 않기 때문에 대안적인 프로세스가 필요하다는 것
애자일 방법론
•
워터폴 프로젝트는 개발 방식이나 기술, 심지어 UI까지 기획자가 먼저 숙제처럼 고민해야 하지만, 애자일에서는 ‘User Story’라는 백로그만 작성한다.
•
유저스토리 - 전체 서비스가 갖춰야 할 고객의 목표와 핵심 결과를 사용자 목표에 따라 잘게 나눠 작성한 ‘요구사항 리스트’라고 할 수 있다.
기획자에게 방법론은 커뮤니케이션 수단일 뿐
•
기획자는 업무 문서 작성을 위해서든 협업자를 이해시키기 위해서든 서비스에 대한 고민을 프로젝트가 시작되기전 충분히 해야만하는 직무
•
어떤 방법론을 선택하느냐보다 머릿속에 뭉게뭉게 피어있는 기획을 팀원에게 구체적으로 전달할 수 있어야하고, 팀원 스스로 자신이 무엇을 만드는지, 무슨 일을 해야하는지 알 수 있게 해야한다.
•
기획자의 기획은 비즈니스 모델에 대한 이해를 바탕으로 해당 시스템 구조내에서 구현 가능한 IT 기술과 고객에게 의미있는 UX를 만들어주는 UI가 포함된 것이어야 함.
현업 부서에서 서비스 개선요청을 받았을때
서비스 운영 개발 요청서
현업과의 인터뷰 : 듣고 질문하고 이해하자
•
서비스 기획자의 역할은 ‘서비스 관리’이다. 서비스 관리는 전체 서비스의 방향성 비즈니스와 IT, UX 관점에서 일관되게 유지, 운영될 수 있게 하는 것이다.
◦
서비스 운영 개발 요청서가 들어오면, 해당 요청사항의 목표와 방법이 회사 서비스의 방향성에 부합하는지 제로 베이스에서 판단해야함.
•
현업부서와의 미팅에서 가장 중요한 질문은 방법적인 부분이 아니라 현업이 요청하게 된 ‘진짜 목표’를 파악하는 것이다.
•
서비스 기획자는 현업부서가 원하는 목표를 기반으로 전체 프로덕트의 방향성에 맞는 대안을 새로 고민할 수 있어야 한다.
서비스 기획자는 오퍼레이터가 아니다.
•
서비스를 운영하는 부서가 서비스 전반에 걸쳐 방향성과 품질에 대한 권한을 갖고 있다면, 현업의 모든 요청은 해당 서비스 관점에서 판단하는 것이 필요하다. 서비스가 커지고 조직이 세분화되면 각 조직의 핵심 성과지표(KPI)가 조금씩 달라지고 어떤 경우에는 서로 상충하기도 한다.
◦
예를 들어 제휴마케팅팀의 KPI가 제휴사를 통해 들어온 고객의 구매 전환율을 늘리는 것이라면, 다이렉트 마케팅팀의 KPI는 자사의 서비스에 다이렉트로 진입한 고객의 구매 전환율을 늘리는 것으로 두 가지 목표는 상충 될 수 있다.
◦
작게 보면 서비스에 인입하는 동선이 다르기 때문에 문제가 되어 보이지 않지만, 전체 비즈니스 측면에서 본다면 트래픽을 끌어온 만큼 수수료를 지불해야 하는 제휴 트래픽은 다이렉트로 구매가 일어나는 것 보다 이익이 크지 않아 상대적으로 건전하지 않은 트래픽이다. → 전체 서비스 측면에서는 단기적으로 제휴트래픽이 중요하지만 장기적으로는 다이렉트 트래픽이 중요하다.
•
만약 제휴 마케팅, 다이렉트 마케팅팀 양쪽에서 각각의 아이디어로 서비스 개선을 요청을 해온다면, 서로 조율 할 수 있도록 비즈니스, 시스템, 고객 UX를 고려하여 요청사항의 경중을 판단할 수 있는 객관적인 집단이 필요하다.
UX 분석을 하고 서비스 전략을 세우다
•
서비스를 운영하는 관점에서 서비스 기획은 단순한 오퍼레이터가 아니다. 현업부서의 요청 사항은 완벽한 대안이 아니며, 서비스의 중심을 잡고 만들어나가야 하는 전문가는 현업 실무자가 아니라 나 자신이다.
•
서비스 개발 기획은 언제나 시간이 부족하고, 일정에 쫓기다 보면 모르는 사이에 습관적인 UI를 기획하기 마련이다. 평범한 수준으로 개발이 가능하고 요청한 사람도 만족하는 수준. 하지만 그런 기획이 쌓이다 보면 근본적인 고민이 고개를 들기 시작한다. 서비스가 ‘내 자식' 같으로면 전체 프로덕트가 지향하는 방향 안에서 주어진 미션을 완결성 있는 서비스로 만들어야 한다. ‘서비스의 완결성’ 은 고민의 깊이와 넓이에 의해 결정된다.
•
이런 고민은 서비스 기획의 3요소인 자사의 IT 구조와 역량, 비즈니스적 이해, 고객의 UX에 대한 분석을 바탕으로 서비스 전략을 만들어 내는 과정을 뜻한다.
•
서비스 전략은 누군가 서비스에 대해 물어보면 툭 나올 정도로 체화된 고민의 결과여야 한다. 제대로 만들어놓지 않으면 시청자 의견에 휘둘리는 드라마처럼 지나가는 부장님 말에도 흔들리고, 쪽대본으로 찍는 드라마처럼 앞뒤가 맞지 않는 서비스가 기획되기 쉽다.
•
자신이 알쏭달쏭한 전략과 방향성을 가지고 있다면 디자인하는 사람도 개발하는 사람도 알쏭달쏭해지고 결국 서비스를 만드는 사람 모두의 생각이 달라서 완결성 있는 서비스가 나오기 힘들다. 업무의 속도도 중요하지만 그 속도 때문에 고민의 시간을 건너뛰어서는 안 되는 이유다.
기획자가 가장 먼저 해야 할 것은 UX 분석
정량회된 행동 데이터는 숫자로 나타내기 때문에 다중회기분석이나 상관계수 등 다양한 통계 방식으로 행동 분석을 해볼 수 있다. 물론 여기서는 귀납적으로 도출된 데이터를 보고 가설을 세울 수 있는 능력이 필요하다.
비즈니스와 시스템을 알아야 UX를 활용할 수 있다
•
UX를 분석하는 이유는 여러가지 방법을 통해 얻어낸 조사 결과를 이용해 고객을 이해하고 서비스가 나아가야 할 방법을 정하기 위함이다.
혼자서 서비스 기획을 배우는 법
•
툴을 이용해 UI 그리는 것을 익혔다고 해서 서비스 기획을 했다고 볼 수는 없다. 왜냐하면 UI는 UX와 IT 시스템, 비즈니스 정책과 전략이 한데 어우러져 나온 최종 산출물의 결과이기 때문이다. 시스템과 비즈니스 고객이 없는 상태에서의 UI 연습은 전혀 도움이 되지 않는다.
•
자신이 맡은 시스템 구조를 파악해서 확인 가능한 데이터 지표를 통해 서비스 생애주기와 전략을 체크하고 구현 가능한 서비스를 만들어나가야 한다.
독학으로 서비스 기획을 공부하는 방법 : 역기획 
역기획 - 기존에 만들어진 서비스 산출물을 살펴보면서 역으로 어떤 사고과정을 거쳐 서비스가 기획되었는지 정리하는 방식. 기획은 눈에 보이는 현상을 관찰하는 것에 더해 사고의 과정이 들어가야하며, 사고의 과정을 따라가야 역기획이 된다. 즉 UI를 그저 UI 자체로 바라보는 것이 아니라 그 안의 로직과 정책을 쓸 수 있을 만큼 분석할 수 있어야 한다는 말이다.
1.
비즈니스 모델 파악
2.
핵심로직 분석
3.
기업목표 분석
1.
비즈니스 모델 파악 : 서비스를 선택하고 구조와 수익구조 파악
a.
중요한 기준은 ‘데이터 가설’을 세울 수 있는지 - 온라인 서비스란 아무리 인터페이스가 화려해보여도 결국은 데이터(Row Data)를 입력하고 특정 과정을 통해 원하는 형태의 데이터를 출력하는 서비스이다.
대상 서비스 명 : 유튜브
주요 서비스 이용자와 프로세스 : 동영상을 올리는 프로세스, 동영상을 보는 프로세스, 광고와 동영상을
매칭시키는 로직
주요 수익원 : 광고 수익
수익 극대화 방법 : 동영상 별로 적절한 광고를 매칭시켜 광고를 흥미롭게 볼 수 있도록 하여 광고 효과 극대화
JavaScript
복사
2.
핵심 로직 분석 : 데이터 가설을 설정하고 서비스를 사용해보면서 검증
a.
어느 정도 서비스의 비즈니스 모델을 이해했다면 각 화면에서 수집하고 사용하는 데이터의 활용에 대해 가설을 세운다.
2.
기업의 목표 분석 : 기업의 목표와 전략을 조사 및 분석하여 의견을 덧붙인다
a.
서비스가 생각한 가설과 다르게 작동하거나 고객에게 도리어 불편한 경우도 있다. 그렇지만 누가 봐도 오류가 아니라 의도된 상황이라면 불편함을 주면서까지 의도한 목적이 무엇인지 찾아본다.
i.
예) 유튜브 광고를 처음부터 스킵할 수 있는 기능을 넣으면 유저는 훨씬 편할 것 하지만 광고를 본다는 보장이 없으면 광고주는 광고를 할 이유가 없음.
ii.
회사도 원할 것 같지 않고 고객도 원할 것 같지 않는 고객 경험을 제공하고 있다면, 그 다음 살펴야 할 부분은 법규이다. → 국가 산업에는 관련된 법규가 있음, 관련 기사를 찾아 읽다보면 요약된 것을 찾을 수 있다.
오퍼레이터와 기획자 그 사이에서
서비스 기획자 - 비즈니스 목표나 문제를 온라인 서비스를 통해 해결책을 제안하는 사람이며 고객의 사용자 경험과 자사 시스템과 기술에 대한 이해를 바탕으로 실제 구현가능한 해결책을 제안해야 한다.
•
서비스의 궁극적인 목표와 이에 해당하는 비즈니스 구조를 제대로 파악하여 나름 논리적이고 타당한 가설을 만드는 것으로 기획을 시작했어야 한다. → 오퍼레이터를 기획자로 바꿔주는 중요한 포인트
바쁘다는 핑계로 고민의 깊이를 습관적인 수준으로 하고 있지않은가? 아주 단순한 기획 건이라도 비즈니스 모델 내에서 하나의 역할을 하고 있을 것이다. 한 단계만 더 고민한다면 이런 역할을 더 잘 파악할 수 있다.
3. 프로젝트 실무에 돌입하다
데이터, 기능, 목표 - 어떤 데이터와 기능이 필요한지, 그 데이터와 기능으로 어떤 목표를 구현할 건지
네트워크를 활용한 모든 온라인 서비스는 결국 기능과 이 기능을 타고 움직이는 데이터로 움직인다.
1단계 : 필요한 기능과 데이터 정의
만들려고 하는 서비스에 어떤 데이터와 기능이 필요한지, 그 데이터와 기능으로 어떤 목표를 구현할지 ‘데이터, 기능, 목표' 세 가지로 구분
첫번째, 서비스의 재료가 되는 기능과 데이터를 생각해보자
•
내가 가지고 있는 데이터와,필요한 데이터를 목록화 해야함.
•
프로그래밍은 세 가지 차원에서 움직인다.
◦
첫째 이용자에 따라 바뀌는 변수인 데이터,
◦
둘째 그 변수를 받아서 특정한 목표에 맞춰 작동시켜주는 기능,
◦
셋째 기능이 연결되어 만들어지는 서비스이다.
1. 이용자에 따라 바뀌는 변수(Variables) → 데이터
2. 변수를 받아 특정 목표에 맞춰 작동시켜주는 → 기능
3. 기능이 연결되어 만들어지는 → 서비스
JavaScript
복사
메신저 예시
1.
입력되는 메세지는 글자로 이루어짐, 0과 1로 만들어진 데이터로 변경되어 DB에 저장되며 이용자에 따라 메세지 내용이 계속 변해서 입력되는 데이터는 ‘변수’라고 볼 수 있다.
2.
저장된 데이터는 다른 디바이스 앱에서 수신됨. 이런 프로세스 ‘기능’
a.
기능은 몇 가지로 쪼개짐
i.
메세지 수신을 알리는 기능
ii.
메신저를 열면 신규 메세지 숫자가 표시되는 기능
iii.
메세지를 누르면 새로 받은 메세지가 호출되는 기능 등등
3.
이러한 기능의 덩어리가 메신저를 주고받는 두 사람 사이에 있는 ‘서비스’
지금까지 아이디어와 전략은 서비스 단위에서 고민이 이루어졌다. 이를 진짜 구현하려면 서비스 영역에서 거꾸로 기능과 데이터 영역으로 내려가서 서비스를 쪼개봐야 한다.
두번째, 데이터를 활용하는 정책
서비스의 목표에 따라 필요한 기능과 데이터를 정리한 후 정책정리
•
정책 - 데이터 활용기준, 개발을 하는 사람이 알고리즘을 짤 때 핵심적으로 고려할 기준을 정리해주는 것
◦
정책의 난이도는 고민의 깊이에 따라 달라지며, 케이스에 따라 정책은 세분화 됨.
•
Default
◦
초기값 설정, 디폴트 설정은 중요한 정책 중 하나다. ‘그냥 반경 OO미터가 좋겠다.’ 가 아닌 논리적인 사유를 통해 정리해야한다.
▪
ex) ‘10분 내외로 걸을 수 있는 200m 정도로 잡는다.’ 와 같은 근거 기준이 필요하다.
◦
또한 리로드 해도 동일한 결과로 서비스를 이용할 수 있도록 하는 기준을 마련해야함. 결과 값이 나오는 순서에 대한 정책을 ‘가까운 순’ 으로 한다면 거리가 동일할 경우 어떻게 정리할 것인지 두번째 기준을 정해야 한다.
◦
조회 결과가 없는 케이스도 고려할 수 있다 → 결과를 하나라도 보여주기 위해 반경을 넓힐지, 보여주지 않을지 등
서비스의 완성도를 위해서는 정책을 세세히 정의해야 한다.
세번째, 서비스 운영과 관련된 제약사항을 떠올리자
•
개인정보를 활용한다면 개인정보보호법에 대한 부분 고려
•
특정 회사와 계약해서 진해오디는 서비스라면 계약 조건에 대한 부분 검토
•
미리 파악이 불가능 하다면 합리적인 의문점들은 마인드맵에 체크한 후 프로젝트를 진행하면서라도 검토할 수 있게 준비되어야함.
2단계 내부와 외부 사용자별 플로우를 정리
2단계 : 플로우 정리
서비스가 굴러갈 수 있는 업무 프로세스 설계해야 함. ‘굴러간다’ 선후 관계를 의미하는데 기존에 정리했던 필요 데이터를 기준으로 입력과 출력의 순서를 구분하는 것.
서비스 운영자와 이용자가 명확히 구분되는 파이프라인 서비스의 경우 운영자는 어드민 페이지에서 필요한 데이터를 등록하고 이용자는 프론트 페이지에서 출력된 데이터를 활용한다.
서비스에 필요한 데이터 정리 → 데이터 확보(내부의 누군가 수기입력, 제휴사 데이터) →
데이터 입력과 출력의 선후 관계가 파악되었다면 그 다음 파악할 것은 ‘사용자’다. 내부 사용자와 외부 사용자에도 구분은 있다. UX방법론 중 퍼소나가 필요한 시점
어드민 페이지를 이용하는 사용자는 서비스를 관리하는 내부 마케터가 될 수도 있고, 만약 오픈 플랫폼 이라면 미용실을 운영하는 개인업자나 알바생이 될 수도 있다.
사용자를 파악하는 것은 문화인류학적 정보인 연령이나 가족관계가 아니라 사용자가 서비스에서 이루려는 목적이나 상황을 인지하여 적절한 프로세스를 설계해주는 것이다.
정보구조(IA) 작성
유저플로우와 플로우차트는 개념이 다르다. 플로우차트는 사용자별 입력과 출력 데이터, 로직의 흐름, 눈에 보이지 않는 데이터 저장 방식이나 연동 방식의 개념도 포함될 수 있다.
반면 유저 플로우는 같은 페이지 내에서도 이용 순서에 따라 화면이 어떻게 바뀌는지 정의한다.
프로세스 설계에서 자주하는 실수들
1. 범위 설정
•
범위는 프로젝트에 포함되는 범주를 의미한다. 현재 운영 중인 서비스에서 새로운 서비스를 만드는 일은 이미 다 만들어진 시스템에서 기능의 일부를 바꾸거나 추가하는 것이므로 서비스 운영 중에 진행되는 개선 프로젝트는 개발해야하는 양을 정하는 것이 굉장히 중요하다.
•
‘있으면 좋을 것 같은 기능’을 추가하는 경우를 추가하게 되면 프로젝트가 완료된 후 우리가 세운 전략이 효과적이었는지 측정할 수 없게 되는 문제가 발생함
•
연구 가설이 옳았는지 보려면 전략적으로 바꾸려는 부분 외에 나머지 부분은 모든 조건이 동일해야함.
•
가벼운 마음으로 추가한 기능 하나에 필요한 정책이나 정의할 케이스가 많아질 수 있고, 메이커가 감당해야 할 프로젝트 기간과 업무량이 늘어날 뿐 아니라, 촘촘하게 연결된 서비스 내에서 영향을 받는 다른 서비스들이 예상보다 많이 나올 수도 있다. 그러므로 목표한 바를 위해 딱 필요한 만큼 수정할 기능을 Compact하게 정의하는 연습이 필요하다.
2. 한 가지 케이스만 고려
어떤 데이터가 들어오더라도 동일한 기준으로 화면과 기능을 제공하는 것을 의미한다. 서비스 기획에서 중요한 것은 들어올 가능성이 있는 모든 데이터에 대해 케이스별로 적절한 처리 방식을 예상해주는 것이며 예상하지 못한 데이터가 들어오더라도 서비스가 문제되지 않게끔 미리 해결하는 것이다.
개발자와의 첫 커뮤니케이션
•
요구사항 정의서
◦
소프트웨어에 포함될 기능과 데이터 등 완성될 서비스의 완성 조건을 정의하는 것을 의미.
◦
양식이 중요한게 아니다. 요청사항을 하루 빨리 전달해 협업자들이 할 일의 중요성이나 방향성, 스펙에 대한 감을 잡고 파악할 수 있도록 하는 것이 중요함.
•
비즈니스 전략 기획의 산출물이 서비스 기획이라면 개발자의 역할은 이 서비스 기획을 실제로 구현되게 만드는 것이다.
•
기획하는 서비스의 기능이 완벽히 준비되지 않았다는 이유로 묵히고 개발부서와 공유하지 않는다면, 그 기획은 ‘똥’이 되고 있을지도 모른다.
•
IT서비스와 관련된 무언가를 진행하고 있다면, 비공식적으로라도 오픈하고 개발 부서에 수시로 물어보는 것도 중요하다.
•
기획은 여전히 초안이기 때문에 ‘이렇게 하고 싶다’라고 해야지 ‘이렇게 정했다’ 라고 해서는 안된다. 이 작은 차이가 협업하는 태도와 분위기를 결정 짓는다.
◦
기획한 바를 설명하되 개발 가능성에 대해서는 개발 담당자가 더 고민하고 찾아볼 수 있도록 여지를 주는것이 필요하다.
•
요구사항 정의서를 리뷰할 때는 원하는 기능뿐만 아니라 프로젝트의 방향과 목표, 히스토리 등을 폭넓게 설명해서 공감대와 관계를 형성하도록 하자.
•
오류 없이 서비스를 유지하려면 어떻게 해야 할까? 오류가 일어날지 모르는 불확실성을 줄여야함.
•
개발부서와 미팅에서 불만족했더라도 개발자의 질문을 듣는 것만으로도 추가적으로 기획해야 하는 것이 무엇인지 알게 되었다면 의미가 있다.
인사이트
•
개발자와 수시로 커뮤니케이션 하는 것이 중요하다.
◦
수시로 커뮤니케이션 함으로써 개발자들도 범위나 중요한 것들을 선제적으로 파악할 수 있고, 개발자와 커뮤니케이션 하면서 기획적으로 부족한 부분을 채울 수 있다.
•
기획이 초안이더라도 자신감을 갖고 개발자와 커뮤니케이션 하면서 완성해가야 한다.
UI설계
•
UI를 먼저 그리게 되면, 생각의 틀이 굳어져 더 이상 서비스의 정책과 본질에 집중하기 어렵다. 그려놓은 그림에 사로잡혀 중요하지 않은 내용으로 생각이 흘러가게 된다.
•
활용할 데이터가 무엇인지, 데이터가 어떻게 움직일지, 사용자에게 중요한 이용목적은 무엇인지 봐야하는 순간에 디자인 범주에 대한 고민으로 치환된다.
스케치
•
지금까지 서비스의 전략과 구조, 시스템을 고민하면서 어렴풋이 정리된 구성요소들을 배치
기획자 산출물 : 화면설계서와 유저스토리
유저스토리 - 유저스토리는 요구사항 정의서와 비슷해 보이지만 본질적으로 다르다. 사용자에 대한 페르소나 개념이 포함되고, 서비스의 목표(Goal)가 그 사용자의 과업이 되며, 마지막으로 비즈니스 모델에서 목표나 중요성이 ㅎ포함된다. 주의할 점은 어떤 로직으로 그렇게 만들것인지 UI적인 부분을 고정하여 작성하지 않아야 한다는 것이다.
기존 서비스 시스템을 파악해야 할 때
새로운 서비스를 기획하여 추가하기에 앞서 현행 시스템 정책과 서비스 상태를 파악해야 한다.
데이터의 흐름과 용도를 생각하는 기획
의미있는 데이터 분석을 하려면
목적에 맞는 데이터가 필요하다.
•
데이터 활용을 위해 가장 중요한 일은 기준을 마련하는 것이다.
•
같은 이름의 데이터라도 내가 생각한 가설과 다른 데이터라면 목적에 맞춰 활용할 수가 없다. 즉 데이터는 생성되기 전부터 목적이 분명해야 한다.
•
이것이 바로 ‘빅데이터’에 활용 가능한 ‘스몰 데이터’의 개념이다.
쓸 만한 데이터를 뽑아내려면 가설이 있어야 한다.
•
쓸 만한 데이터를 뽑기 위해서는 가장 먼저 데이터에 대한 가설이 있어야 한다.
•
데이터를 중구난방으로 뽑는 것도 어렵지만, 의미 있는 데이터는 대개 1차 데이터가 아니라 가공된 2차 데이터에 있었다.
•
딥러닝 하는 AI도 아닌 우리가 데이터를 다 꺼내놓고 규칙을 찾는 것은 아주 비효율적이다. 비즈니스에 대한 이해를 바탕으로 가설 검증을 반복하는 것이 효율적이다.
•
깊게 고민해본다면 데이터를 뽑는 시기도 고민 대상이된다. 명절이나 연휴 같은 변수에 의해서도 사용자의 서비스 이용 목적이 영향을 받는다. 이에 따른 데이터 가설이 달라져야함은 물론이다.
위시리스트를 통해 일어난 주문 완료건수 - 취소된 주문건수 / 주문하기 버튼 클릭수
가설 없는 데이터에는 맹점이 있다.
•
아무조건 없이 남이 만들어놓은 데이터를 믿는다면 어이없는 결과를 도출할 수 있다.
◦
예시) 구매 전환율 (회원당 구매 전환율을 보기위한 거시적 목적의 데이터로 세팅 데이터가 있다고 가정했을때)
1.
한달을 기준으로 100번 와서 1번 구매한 사용자
2.
우연히 1번 와서 구매한 사람을 동질로 여기는 데이터였다.
분석용 데이터 또한 기획 과정부터 고민해야 한다
•
화면을 만드는 시점부터 보이는 영역뿐 아니라 데이터에 대해서도 가설을 세우고 고민한다면 필요한 지점에 적절한 데이터를 얻을 수 있다.
데이터의 확장성까지 생각하는 기획자
•
기획자에게 중요한 데이터는 두 가지이다.
1.
분석을 위해 별도로 쌓은 데이터와
2.
기능이 작동되기 위한 필수적인 데이터
•
예를 들어 이미 봤던 상품을 보여주는 영역이 있다고 해보자, 단순히 화면 기획만 한다면 개발자가 이 데이터를 쿠키로 쌓든, DB에 쌓든 기획자는 데이터가 쌓이는 위치를 모를 것이다. 상품코드로 쌓든, 상품명 자체를 복사해서 저장하든 개발자는 오로지 개발 효율과 시스템 여건을 고려하여 선택할 것이다.
하지만 애초에 이 데이터를 기준으로 개인화 페이지를 확장한다든가, 모든 디바이스에서 동일하게 보여야 한다는 기준을 제시한다면 어떨까? 개발자도 그 목적과 의도에 맞게 데이터를 코드화 시키고 저장 방식도 고려할 것이다. 다시 말해 기획자가 화면만 기획하는 것이 아니라 데이터의 확장성까지 고민한다면, 개발부서와 함께 데이터를 다루는 청사진을 그리며 설계할 수 있다.
나의 상식으로 UX를 설계하면 안 되는 이유
상식을 믿지 말고, 데이터 검증부터 하기
•
서비스의 UX를 개선하려는 눈빛으로만 본다면 우리는 절대 사용자의 눈을 가질 수가 없다. 사용자는 서비스를 경험할 대는 서비스의 화면 구성과 같은 디테일에 무심하다. 그저 서비스를 목적 달성을 위한 도구로 이용한다. 그리고 이는 오직 사용자일 때만 느낄 수 있다.
•
상식과 경험이 아예 쓸모없는 것은 아니다 우리의 ‘상식’은 사용자 일때의 사고관으로 만든 ‘가설’ 일때 의미가 있다.
데이터에도 함정은 있다.
•
통계의 역설 - 너무 낮은 수치의 모수를 가졌거나, 치명적인 외부 요인으로 인해 이용자의 행동 자체가 생각과 다를 수 있다.
◦
예를들어 특정 상품이 압도적으로 싼 ‘뽐뿌’ 같은 사이트에 올라갔거나, 아주 낮은 효율을 보이는 영역이지만 그날 하루의 데이터만 본다면
•
데이터에 대한 가설을 세우고 검증하려면 서비스에 대한 이해가 다방면으로 이루어져야 한다. 단지 화면만 볼것이 아니라 사용하는 사람의 표정이나 목표, 그날의 특이점에 대해서도 분석해야 한다. 이런 것을 기반으로 가장 ‘합리적인 예상’을 내리고 이를 검증하는 것이 중요하다.
4. 프로젝트는 여럿이 함께
4-1. 화면 설계에 장인정신은 필요 없다.
화면설계서의 디스크립션을 잘 쓰는 방법
•
화면설계의 디스크립션 - 와이어프레임의 인터렉션이나 케이스별 형태에 따른 개발 로직, 서비스에서 정한 정책등을 적는 영역
•
화면설계서의 디스크립션은 정밀하고 순서를 확실하게 해야한다. 동작도 쓰고 로직도 써야한다. 목표도 쓰고 정책도 쓰고 예외조항도 적어줘야 한다. 그래야 개발하는 사람이 정확하게 코딩할 수 있다.
1. 협업자에게 리뷰하여 질문 받기
•
디스크립션의 수준을 높이는 방법은 바로 ‘협업’이다.
•
디자이너와 개발자에게 리뷰를 하는 순간 질문이 쏟아질 것이다. 그리고 이 질문들은 디스크립션을 고도화 시킬 수 있는 보석같은 것들이다.
•
기획자가 모든 질문을 예상할 수 있다면 좋겠지만, 모르겠다면 빨리 리뷰를 진행해서 질문을 받아내고 답을 찾는 것이 더 명확하게 기획할 수 있는 길이다. 기획자가 생각한 로직이 구현 불가능한 수준이라면 개발자가 다시 이슈를 제기할 것이고, 그때서야 비로소 커뮤니케이션을 통해 더 나은 서비스를 만들 기회와 빠르게 성장할 수 있는 기회도 찾아온다.
•
잘 물어보는 사람이 더 빨리 배운다.
2. 디스크립션의 완성도를 더욱 올리는 방법
•
화면설계서를 작성할 때 예외처리, 분기처리, 정합성 체크를 고려하면 완성도를 높일 수 있다. 초안을 작성할 때 단번에 작성하지 못하더라도 개발의 과정, 테스트 과정에서 이러한 부분이 추가될 수 있다.
1.
예외처리 - 정상적이지 않은 예외적인 상황에 대해서 대응할 수 있도록 처리하는 것을 예외처리라고 함 (기본적인 설계 조건에서 벗어나는 경우에 대해서 기획하는 것을 예외처리라고 한다.)
•
ex) 주문서에서 배송지 영역은 회원정보에 등록된 배송지 정보를 불러와서 보여주는 것으로 화면을 설계했는데 특정 회원의 경우 배송지가 입력되지 않은 상황에 대한 처리
2.
분기처리 - 분기처리는 애초에 유형이 여러가지가 있어서 한 개의 페이지가 유형에 따라 다르게 나와야 하는 경우를 의미함.
3.
정합성 체크 - 데이터 처리에서 규칙에 맞는지 보는 것을 의미함.
4-2. 서비스 기획자는 개발을 얼마나 알아야 할까
•
코딩 책 들여다보지 말고 내 옆의 개발자에게 묻자
•
자사 시스템에 어떤 데이터가 들어있고 어떤 로직으로 움직이는지 알 수록 더 좋은 기획이 나온다. 그래서 기존 서비스를 이용해보고, 화면설계서도 보고, 정책문서도 보며 애쓰는 것이다.
•
시중에 나온 코딩 책이나 학원에서는 회사 각각의 시스템에 대해 가르쳐주지 못한다. 이것이 지금 하고 있는 업무를 회사 내 사람들에게 물어봐야하는 이유다.
코딩 책 들여다보지 말고 내 옆의 개발자에게 묻자
•
자사 시스템에 어떤 데이터가 들어있고 어떤 로직으로 움직이는지 알수록 더 좋은 기획이 나온다.
•
시중에 나온 코딩 책이나 학원에서는 회사 각각의 시스템에 대해 가르쳐주지 못한다. 이것이 지금 하고 있는 업무를 회사 내 사람들에게 물어봐야하는 이유이다.
배우자 하는 태도가 최고의 역량
•
실전에서 쓰는 용어들을 그때그때 정리해두면 일을 해나가는데 있어 도움이 된다. 현장에서 쓰는 개발 용어를 접할 때마다 정리하다 보면 자사에 가장 적합한 용어집을 만들 수 있다.
•
‘공부의존증’ 이라는 말이 있다. 모르는 것이 있을 때 스스로 알아보려 하기보다 학원이나 자격증부터 찾아서 준비하려는 현상이다.
•
용어 아닌 활용을 이해해 나가다 보면 충분히 개발자와 소통이 가능한 기획자가 될 수 있다.
•
기획자에게 필요한 역량은 ‘이슈 상황을 이해하고 해결책을 고민하는 방법을 아는 것’이다. 그걸 누군가는 ‘문제 해결력’이라고 하고 누군가는 ‘일 센스가 있다’고 한다. 개발 기술보다 기획자 본연의 근본적 질문에 더 많은 고민의 시간을 갖는 것이 기획자로서 성장에 더 도움이 되는 것이다.
개발자에 대한 이해 높이기
•
APP개발(iOS/안드로이드)
◦
웹을 많이 사용하는 하이브리드앱의 경우에도 동일한 웹 화면을 쓰더라도 각 앱의 웹 뷰어가 다르기 때문에 결과값이 다소 다를 수 있으므로 앱개발자와 프론트 개발이 협업이 될 수 있도록 함께 리뷰하는 것이 좋다.
4-3. 기획은 재밌는데 테스트는 재미없다
•
서비스 기획자로서 개발자에게 오류를 해결토록 하려면 두가지 절차가 필요하다.
1.
오류가 발생하는 케이스가 재현될 수 있도록 정확하게 개발자에게 공유
2.
오류 상황에 대한 원인을 함께 이해하고 적절한 산출물을 정의하거나 한계가 있다면 대안을 빠르게 제공
•
위 두가지 중 두번째에 더 많은 신경을 써야한다. 개발을 해보니 구조적으로 불가능한 부분이나 예상했던 것 보다 불편한점, 혹은 생각조차 못해본 케이스의 출현 등등 갑자기 등장하는 예측 불가능 했던 사건들에 대해 기획을 추가하거나 제외하면서 서비스의 완성도를 높여야 하는 것 이다.
테스트로 키워지는 기획력
•
기획력은 단연코 ‘고민하며 테스트 할 때’ 향상된다.
•
초창기 웹 기획 관련 서적에 기획자의 중요한 역할 두가지가 나온다.
1.
확장성에 대한 고려
2.
대부분 케이스에 대한 고려
•
위 두가지는 기존 시스템이나 새로 만들 시스템에 대한 이해가 제일 중요하다. 시스템은 정책 문서로만 이해하기 어렵다. 시스템을 파악하려면 많이 사용해 볼 수 밖에 없다.
•
기획을 잘 하는 가장 좋은 학습 방법은 스토리보드 연습이 아니라 테스트를 하나하나 해보고 이해하는 것이다. 모든 테스트를 신경써서 집중한다면 어떤 교육보다 빠르게 배울 수 있다.
아무리 테스트를 잘해도 빠지는 부분은 있다.
•
일정 시점을 정하여 필수적으로 처리해야 하는 것을 필터링 한 후 오픈해야 한다.
서비스의 탄생
결과에 쿨해지자
•
서비스가 오픈하면 끝인것 같지만 기획 관점에서 시작에 가깝다. 우리가 적용한 가설이 맞는지 검토하고 새로운 교훈을 얻어야 한다. 즉 ‘성찰’이 필요하다. 이를 위해 애초 기획 시점에서 과업목표 KPI를 명확히 설정하는 것이 중요하다.
•
정말 필요한 데이터는 1차 데이터가 아니라 특정한 생각을 가지고 추론하여 만들어진 2차, 3차 가공 데이터 이다. 그런 데이터를 얻으려면 일정기간 동안 동일한 기준의 데이터를 수집해두는 것이 필요하다. 그래야 오픈 전후의 차이를 확인하는 등 여러 방면으로 활용할 수 있다.
•
이런 성찰 과정은 서비스의 방향성을 판단하는 데도 중요하고 앞으로의 서비스 개선을 위해서도 중요하다.
•
린 UX는 서비스 기획 관점에서 무엇이 옳고 그른지 알 수 없을 때 서비스의 핵심을 담아 빠르게 생산에 시장에 테스트해본 후 더 나은 쪽으로 학습하고 방향성을 설정하는 피봇팅 Pivoting을 강조한다.
•
린 UX에서 강조하는 개념을 잘 받아들이려면 자신의 가설이 틀릴 수 있음을 항상 마음에 담아두어야 한다.
Data Setting
1.
현재 진행중인 학습과 이전 학습에서 질문했던 사항들이 이어질 것이므로 질문 리스트가 필요하다.
a.
Material 내의 질문목록 버튼 클릭 이벤트
2.
모바일 사용 유저가 증가한만큼 헬프센터가 오픈되면 모바일로 질문하는 비중이 늘어날 것이다.
a.
질문하기 탭내의 질문하기 버튼 클릭 이벤트
b.
Material 내의 질문하기 버튼 클릭 이벤트
3.
모바일의 푸시기능이 제공되는 만큼 모바일을 통해 질문을 확인하는 비중이 늘어날 것이다.
a.
Push Notification을 통해 유입되는 비중 확인
•
Material 타입별 체류시간을 체크할 수 있는지?
•
모바일은 신규 기능개발 및 개선시 Onboarding을 무조건 해주자
