이를 위해서는 기획자가 담당한 도메인 관련 지식 + 회사의 정책을 다각도로 바라보는 시각이 필요하다고 생각된다.
예를 들어, 사용자가 기차표 정보를 OCR로 스캔해 출장정산서로 넘기는 프로세스가 있다고 하자.
이때 OCR로 스캔된 탑승정보와 공공API의 탑승정보를 비교해 검증하는 기능을 추가하자라는 이야기가 나왔을 때, 우리는 어떤 점을 생각해볼 수 있을까?
검증의 목적이 무엇인가?
검증하고자 하는 목적. 즉 이유가무엇인가? 를 생각해볼 필요가 있다.
사용자의 부정지출을 방지하기 위한 *컴플라이언스 기능인가?
부정지출을 발견한다면 이후 프로세스까지 고려되었는가?
단순 사용자의 탑승여부를 판단하는 기능인가?
직원의 출장관리를 위해 회사는 직책별 상이한 일급을 제공하는데, 그 돈을 덜 쓰면 그대로 직원의 돈이 되는 정책을 가진 회사도 있다. 그렇다면 직원들은 기차값에 해당하는 돈을 받고 돈을 아끼기 위해 버스를 타고 가는 이슈가 발생한다. 이러한 경우까지 출장관리 서비스에서 단속할 것인가?
아니면, 회사가 직원을 믿고 단순히 기차를 탔는지, 안탔는지만 검증할 것인가?
*컴플라이언스 기능 : 이슈를예방하기 위해 만든 기능
우리 서비스에서 관여할 수 있는 범위는 어디까지인지, 그 범위 내에서 만들 수 있는 기능인지, 그 기능이 사용자가 정말 필요로 하는 기능인건지 등등.. 아직까지는 배우고 부딪혀야 할 부분이 많다..🥲
기획자의 의도에 개발부서가 공감한다면, 분명 서비스 기획에 도움이 되는 조언을 들을 수 있다. 개발자가 기존 시스템의 숨겨진 기능을 이용해 개발 기간을 단축할 방법을 찾아줄 수도 있고 추가 개발 없이 목표를 달성하는 방법을 제안할 수도 있다. 하다못해 우리가 알 수 없었던 타사 서비스의 시스템 구조와 힌트를 들을지도 모른다. 서비스 기획자가 생각할 수 있는 범주와 개발자가 생각하는 범주가 다르기에 협업은 필수적이다.
*마이크로 UX : 사용자가 움직이는 동선이라고 하면 대개는 페이지 단위 이동만을 생각하는데 페이지 내에서도 많은 작은 단위의 행위와 이에 따른 변화가 생긴다. 예를 들어 회원가입을 할 때, ID를 입력하고 존재 여부를 검색할 때, 이미 존재하는 ID인지 아니면 등록 가능한 ID인지 그도 아니면 ID 등록 규정에 따르지 않는 것인지에 따라서 피드백이 모두 다르게 나온다. 이처럼 케이스별로 UI가 다르게 관리되어 사용자가 편리하게 사용할 수 있도록 유도하는 설계를 마이크로 UX라고 한다. 가능하면 기획 단계에서 마이크로 UX에 대처할 상황 케이스를 최대한 많이 구분해줄 수록 디자인과 개발의 디테일에 많은 영향을 준다.
개발자와 커뮤니케이션을 하려면 요구사항 정의서를 작성해야 한다. 소프트웨어에 포함되어야 할 기능과 데이터 등 완성될 서비스의 완성 조건을 정의하는 것을 의미한다. 요구사항 정의서를 리뷰하고 나면, 개발 담당자는 가능한 것과 가능하지 않은 것, 추가적으로 검토해봐야 할 것 등을 파악하게 된다. 어느 정도의 개발 인력과 시간이 투자되어야 하는지도 가늠한다. 그러므로 요구사항 정의서를 리뷰할 때는 원하는 기능뿐만이 아니라 프로젝트의 방향과 목표, 히스토리 등을 폭 넓게 설명해서 공감대와 관계를 형성하도록 하자.
요구사항 정의서 주요 작성 항목
1. 시스템 구분 : Front / Adminstrator / 기타(API, BATCH 등)
서비스 목표와 이에 필요한 기능과 데이터를 차례로 정리했으면, 이제 '정책'을 정리할 차례다. 정책은 '데이터 활용 기준'이라고 생각하면 된다. 개발을 하는 사람이 알고리즘을 짤 때 핵심적으로 고려할 기준을 정리해주는 것이다.
STEP 2. 내부와 외부 사용자별 플로우를 정리한다.
보통 자료에서 보는 플로우 차트는 고객이 보는 프론트 화면의 순서를 나타낸다. 하지만 그런 화면만으로는 디자인도 개발도 진행하기 어렵다. 다양한 정책이 가져오는 여러 가지 케이스에 대해 모두 확인해볼 수 있는 플로우 차트가 필요하다. 현업 실무자에게는 '비즈니스에 맞는 플로우 차트'가 필요하다. 그러므로 내부와 외부의 모든 사용자를 정의하고 서비스가 굴러갈 수 있는 업무 프로세스를 설계해야 한다.
STEP 3. 정보구조(IA) 작성하기
마지막으로 필요한 것은 프로젝트에 포함될 화면 목록을 정리하는 것이다. 시각적으로 보이는 화면 목록을 정의한 것을 보통 IA(Information Architecture)라고 부르는데, 트리 방식으로 정리되는 '정보 구조 체계'를 의미한다.
모바일 환경에서는 IA 문서보다 유저플로우나 아트보드처럼 UI 조작에 따른 환경 변화에 주목하여 설계한 문서들이 주목받는다.
IA는 어드민을 포함하여 고객이 이용하는 화면까지 업무 프로세스 설계를 큼직하게 정리하기에 적합하다. 유저플로우만큼 화면 UI를 세세하게 정리하기 전에 프로세스 단위로 화면을 몇 개로 작업할지 확인해서 작업량을 산출하는 기준을 마련할 수 있다.
*플로우차트 : 사용자별 입출력 데이터, 로직의 흐름, 눈에 보이지 않는 데이터 저장 방식이나 연동 방식의 개념도 포함한다.
*유저플로우 : 같은 페이지 내에서도 이용 순서에 따라 화면이 어떻게 바뀌는지 정의한다. 프로세스 설계보다는 화면 UI를 작업하는 과정에서 좀 더 편리하고 자연스러운 사용성을 개선하는 시점에서 더 필요로 한다.
*API (Application Programming Interface) : 응용 프로그램 개발자들이 앱을 만들 때 운영체제에서 동작하는 프로그램을 쉽게 만들 수 있도록 화면 구성이나 프로그램 동작에 필요한 각종 함수를 모아놓은 것을 말한다. 즉 다른 개발자들이 이 프로그램을 응용해서 다른 프로그램을 만들려면 '최소한 이런 기능들은 필수로 들어가겠지'라는 생각으로 미리 필요한 함수들을 만들어서 모아놓은 도서관과 같다.
STEP 1. 비즈니스 모델 파악 : 서비스를 선택하고 서비스 구조와 수익 구조를 파악한다.
어떤 서비스를 선택하느냐에 대한 기준은 '데이터 가설'을 세울 수 있느냐는 점이다.
온라인 서비스란 아무리 인터페이스가 화려해 보여도 결국은 데이터를 입력하고 특정한 과정을 통해서 원하는 형태의 데이터를 출력하는 서비스다.
STEP 2. 핵심 로직 분석 : 데이터 가설을 설정하고 서비스를 사용해보면서 검증한다.
어느 정도 서비스의 비즈니스 모델을 이해했다면 각 화면에서 수집하고 사용하는 데이터의 활용에 대해 가설을 세운다.
비즈니스 모델에서 핵심적으로 보이는 부분에 집중해보는 것. 가설을 세우려면 서비스를 이용해보아야 한다.
그리고 서비스가 어떤 데이터를 수집하고 있는지부터 파악해야 한다.
ex. 유튜브 동영상을 보는 사람에게 어떤 기준으로 추천을 해주는가? 동영상에는 어떤 광고를 매칭시키는가?
STEP 3. 기업의 목표 분석 : 기업의 목표와 전략을 조사 및 분석하여 의견을 덧붙인다.
서비스가 생각한 가설과 다르게 작동하거나 고객에게 도리어 불편한 경우도 있다.
그렇지만 누가 봐도 오류가 아니라 의도된 상황이라면 불편함을 주면서까지 의도한 목적이 무엇인지 찾아본다.
각 화면 속에는 회사가 원하는 것과 어쩔 수 없는 것이 숨겨져 있다. 회사도 원할 것 같지 않고 고객도 원할 것 같지 않는 고객 경험을 제공하고 있다면, 그 다음 살펴야 할 부분은 법규이다. 국가 산업에는 관련 법규가 있고, 각 법규가 규제하는 것이 무엇인지 찾아봐야 한다.
ex. 유튜브에서 광고를 처음부터 스킵할 수 있는 기능을 넣느나면 고객에게는 훨씬 더 편할 것. 하지만 광고를 본다는 보장이 없으면 광고주는 광고를 할 이유가 없음. 유튜브는 광고를 처음부터 보고 싶지 않다면 '유튜브 프리미엄'에 가입할 것을 권유. 이는 광고수익을 보전할 수 있는 구조.
서비스 기획자는 비즈니스, UX, 기술 영역을 망라하여 프로덕트(서비스)를 구현하기 위해 기획하고 관리하는 사람을 말한다.
쉽게 말하면 비즈니스 모델상의 수익 구조, 고객과의 접점, 지향점 등을 종합하여 서비스를 만들고 성장하도록 관리한다는 의미다.
또한 서비스 기획자는 현업부서가 원하는 진짜 목표를 기반으로 전체 프로덕트의 방향성에 맞는 대안을 새로 고민할 수 있어야 한다.
그러자면 핵심 질문을 던지는 것이 중요하다
* 프로덕트 vs 프로젝트
: 프로덕트는 서비스로 나타나는 '산출물' 자체를 의미하며, 프로젝트는 그 목표를 이루기 위한 과정
서비스 기획자가 마케터, 전략 기획자와 다른 점은?
온라인 서비스 영역으로 들어오면서부터는 기획자와 마케터는 분명한 차이가 생긴다. 모바일 앱을 포함한 온라인 네트워크를 바탕으로 소프트웨어를 이용하는 서비스를 다루는 서비스 기획자는 '현재 시점에서 무엇을 하고 싶다'는 전략을 세우는 것만으로는 업무가 끝나지 않는다. 서비스 기획자는 전략에서부터 끊임없이 되묻는다. "그걸 어떻게 할 건데?" 서비스 기획자의 진짜 일은 '상상을 실제로 어떻게 얼마만큼 구현하도록 만들 것이냐'에 초점이 맞추어져 있다. 기술은 없지만 기술을 가진 이들과 협업하고 이끌어야한다. 온라인 네트워크를 사용하여 만든 서비스라면 구현 속도와 기술적 환경, 시시각각 변하는 사용자 경험에 맞추어 계속해서 방향과 속도를 조정해야 한다. 전략도 상황에 맞게 수정시켜야 하고 원하는 산출물이 나올 때까지 현실적인 구현에 훨씬 초점을 맞추어야 한다. 서비스 기획은 사용자 반응을 보며 게속해서 이 모델을 정교화시키는 피봇을 빠르게 실행하여 시스템 속에서 작동시킨다. 서비스 기획자는 '시스템적으로' 구체적 고민을 해야 한다. 서비스 기획의 핵심은 '어떻게 구현할 것인가'
새로운 서비스를 도입하기 위한 초기 단계에서는 전략 기획과 서비스 기획 모두가 필요하다. 다만 전략 기획자가 '방향성'에 집중한다면, 서비스 기획자는 '구현'에 집중한다. 전략 기획과 서비스 기획을 함께하는 방식으로 이른바 '디자인씽킹', '사용자 중심 설계'가 있다. 고객의 현재 불편한 점이나 평소 느끼지 못한 페인포인트를 발견하는 것에서 출발하여 어떻게 고객에게 가치를 전달할 것인가를 구체적으로 설계해내는 프로세스 중심의 방법론.
서비스 기획안 자체를 볼 때 옳고 그른 것은 없다. 하지만 서비스의 논리적 지향점을 기준으로 한다면 그때는 맞고 지금은 틀린 지점은 있을 수 있다. 서비스 기획자가 서비스 개선을 기획할 때는 자신의 경험이나 고객 불만을 근거로 해서는 안된다. 자신의 경험이 시작점이 될 수는 있지만 궁극적인 서비스 개선은 비즈니스 모델에 대한 전략과 방향에 대한 다각도의 이해를 바탕으로 이루어져야 한다.
서비스 기획자가 하는 일
1. UX와 비즈니스 모델까지 생각한다.
ex. 네이버 메인 화면이 구글처럼 검색창만 배치하는 것으로 바뀐 것은, 광고 플랫폼에서 초록 버튼을 통한 검색과 AI 추천을 강화한 광고 플랫폼으로 비즈니스 모델을 변화시키려는 전략이 있었기에 가능한 변화였다.
2. 개발 환경과 비용까지 생각한다.
ex. 임시저장 기능 - 완성된 글 데이터와 임시저장 데이터를 어떻게 구분할 것인가 & 임시저장으로 인해 증가할 쓰레기 데이터의 처리와 비용은 어떻게 할 것인가 & 임시저장 기능을 넣는다면, 데이터 영역과 고객에게 보이는 영역, 그리고 관리자 툴(administrator kit)까지 임시저장 글과 완성된 글이 구분될 수 있도록 수정해야 함.
-> 무언가 새로운 기능을 넣고자 할 때도 서비스 기획자는 단순히 기능적인 목표만을 생각해서는 안된다. 서비스 개선 방향이 프로덕트 전체에 미치는 영향과 비용까지 생각해야 한다.
3. 서비스 전체의 선순환을 생각한다.
* 선순환 구조 : 데이터의 입력과 순환을 통해 서비스 전체의 기반을 찾아가는 것
-> 어떤 서비스든 사용하다 보면 불만이 쌓이고 바뀌었으면 하는 부분이 생긴다. 하지만 서비스 기획자의 관점은 단지 '불편'에 머물러서는 안된다. 눈에 보이는 페인포인트는 굉장히 쉽게 접근할 수 있다. 하지만 서비스 기획자는 비즈니스 모델과 전략, 개발 환경과 비용, 그리고 서비스 전체의 순환 구조까지 고려하는 폭넓은 시각을 가지고 있어야 한다.
서비스가 '내 자식' 같으려면 전체 프로덕트가 지향하는 방향 안에서 주어진 미션을 완결성 있는 서비스로 만들어야 한다.
여기서 '서비스의 완결성'은 고민의 깊이와 넓이에 의해 결정된다. 그리고 이러한 고민이란 서비스 기획의 3요소인 자사의 IT 구조와 역량, 비즈니스적 이해, 고객의 UX에 대한 분석을 바탕으로 서비스 전략을 만들어내는 과정을 뜻한다.
기획자가 가장 먼저 해야할 것은 UX 분석
방법론이란 그저 방법론일 뿐. 복잡한 사고과정의 기준을 잘 잡기 위한 방법론 자체가 목적이 될 수는 없다.
궁극적으로 UX 방법론은 고객 경험을 통해 서비스의 개선 방향에 대한 인사이트를 얻기 위한 것이어야 한다.
UX를 분석하는 이유는 여러 가지 방법을 통해 얻어낸 조사 결과를 이용해 고객을 이해하고 서비스가 나아가야 할 방법을 정하기 위함이다.
중요한 건 협업부서의 요청사항을 있는 그대로 받아들일 것이 아니라, 회사 내외적인 상황을 여러 측면에서 바라보고 고민하는 습관이다.
그러려면 평소 판단의 근거가 될 만한 여러가지 정보를 취합하고 자신의 새각을 일관되게 만들 필요가 있다. 누가 툭 쳐도 항상 의견이 나올 수 있을 만큼 생각의 반복이 필요하다.
기획자의 생각이 굳건하다면 어떤 때는 논쟁하고 어떤 때는 수용하더라도 그것이 바로 서비스 전략이라 할 수 있다.
ex. 제휴 트래픽에 대한 의존도가 높을수록 제휴 스스로도 올라간다. 비즈니스를 영속하기 위해서는 제휴보다는 다이렉트로 사이트에 진입하는 고객을 많이 만드는 것이 더 중요할 수 있다. 제휴로 들어온 트래픽에서 구매가 올라간다면 제휴 마케팅팀의 과업 목표는 충족되겠지만, 회사 전체의 비즈니스로 보면 비용이 늘어나기 때문이다. 따라서 제휴 수수료도 내지 않고 제휴 마케팅팀의 kpi도 맞출 수 있는 방법을 대안으로 제시할 수 있다면 그것이 베스트일 수 있다.
사례로 보는 서비스 전략 기획서
<서비스 운영 개발 요청서> 제목 : 제휴 인입 주문의 주문 완료 페이지 내 개인화 영역 추가 요청자 : 제휴 마케팅팀 김나나 대리 요청 내용 - 가격 비교 사이트를 통해서 들어온 고객이 주문을 완료할 때, 개인화된 관심이 될 상품과 기획전을 추가 노출하여 추가 구매를 유도 - 개인화된 상품 혹은 기획전을 노출 - 행사 기간에는 동일한 영역에 제휴 인입 채널별로 시간대를 조정하여 홍보 배너를 등록할 수 있도록 어드민(Adminstrator)으로 관리 기능 추가 - 행사배너 등록은 승인 절차를 통해 우리 팀에서만 운영 등록할 수 있도록 구성 (1월 중 오픈 필수, 2월 행사 시즌에 활용할 예정)
UX 분석
가격비교 제휴를 통해 인입된 고객은 최저가를 중요시하므로 직접적인 금전적 혜택이 중요하다
만약 최저가 상품으로 인입된 것이 아니라면 이미 우리 쇼핑몰에 대해서 포인트나 간편페이 등 구매 요소를 가지고 있는 사람이다.
평균 구매 분석 결과 한 달에 한 번꼴로 구매가 일어난다. 정말 필요한 물건이 아니라면 구매 직후 바로 구매로 이어지지 않는다.
주문 완료 페이지는 체류 시간이 매우 짧다. 주문 완료 페이지 배너들은 인입 대비 클릭 수가 높지 않다.
비즈니스 분석
가격비교 제휴 사이트로 인입한 경우 수수료를 지불하게 되어있다. 이미 많은 트래픽이 가격비교를 통해서 인입되고 있지만, 다이렉트로 사이트에 인입되는 횟수가 많아야 장기적으로 브랜딩과 수익에 도움이 될 것이다.
IT 시스템 분석
로그인 후 구매를 한 상태이기 때문에 현재 구매정보와 개인정보를 활용하여 개인화가 가능하다.
서비스 전략
주문 완료 시 이탈하는 고객에게 개인화 팝업에서 추천 상품과 앱사용 쿠폰 다운로드 링크를 노출해 주목도를 높이고, 앱으로 이동 시 제휴 마케팅팀의 KPI를 산출할 수 있도록 설정한 딥링크(앱 내 특정 페이지로 이동시키는 링크)를 실행시켜 할인수단을 제공한다.
이를 통해 다음 번에 앱에서 구매할 수 있도록 유도한다. 앞서 구매한 상품군을 기반으로 추천 카테고리의 상품을 한 달 내에 다이렉트로 앱 접속 시에만 사용할 수 있는 할인수단을 제공한다.
