당신은 주제를 찾고 있습니까 “서비스 기획 프로세스 – 서비스기획 프로세스 알아보기 l UX“? 다음 카테고리의 웹사이트 https://you.charoenmotorcycles.com 에서 귀하의 모든 질문에 답변해 드립니다: https://you.charoenmotorcycles.com/blog/. 바로 아래에서 답을 찾을 수 있습니다. 작성자 기획자 J 이(가) 작성한 기사에는 조회수 3,992회 및 좋아요 76개 개의 좋아요가 있습니다.
서비스 기획 프로세스 주제에 대한 동영상 보기
여기에서 이 주제에 대한 비디오를 시청하십시오. 주의 깊게 살펴보고 읽고 있는 내용에 대한 피드백을 제공하세요!
d여기에서 서비스기획 프로세스 알아보기 l UX – 서비스 기획 프로세스 주제에 대한 세부정보를 참조하세요
안녕하세요! 새해 복 많이 받으세요!
정말 오래간만의 업데이트네요.
이번 영상은 서비스 기획에 대한 전반적인 프로세스를 소개해 드리려고 찾아왔어요. 궁금하신 부분이 있으시다면 언제든지 연락주세요.
기획자 J 채널은 현업 기획자가 어떤 업무를 하고
어떻게 기획서를 쓰고 자료를 찾는지 일상 에피소드를 다루는 채널입니다.
서비스 기획에 대해 같이 고민하고 성장해 나갔으면 좋겠습니다.
기획자 J E-maiil
[email protected]
서비스 기획 프로세스 주제에 대한 자세한 내용은 여기를 참조하세요.
앱&웹 서비스 기획 프로세스 – 브런치
웹 혹은 앱 서비스 기획 과정은 총 10가지로 나누어집니다. 1. 아이디어 도출. 2. 최소안. 3. 유저 시나리오. 4. 기능 도출. 5. 서비스 흐름도.
Source: brunch.co.kr
Date Published: 7/24/2022
View: 2466
10년 차 기획자가 말해주는 쉽게 서비스 기획하는 방법
1. 서비스 기획의 분야 8가지 · 2. 기획 프로세스 12단계 · 3. 인공지능 스피커를 제작하고 서비스한다면? · 1. 플랫폼 기획 · 2. 콘텐츠 기획 · 3. 검색 기획
Source: m.blog.naver.com
Date Published: 6/20/2022
View: 3115
서비스 기획의 역할과 실무 프로세스 정리 – 듀의 자료저장소
서비스를 기획하고 방향을 설계할 때. 기업의 아이덴티티를 생각해야 한다. 실제 업무프로세스는. UI 기획서로 콘텐츠를 배치하고,.
Source: dewworld27.tistory.com
Date Published: 10/10/2021
View: 6809
웹서비스, 앱 서비스 기획 과정 프로세스 정리
서비스 기획은 앱 또는 웹 이용자의 경험을 설계하는 것입니다. 그래서 같은 쇼핑앱, 게임, 금융 앱이라도 사용자는 다르다고 느끼게 됩니다.
Source: applefish03.tistory.com
Date Published: 2/11/2022
View: 6363
한눈에 정리하는 서비스 기획
서비스 프로세스는 서비스 사용자가 경험할 서비스 가치를 나타내면서, 개발자에게는 무엇을 개발해야 하는지와 어떻게 개발할지에 대한 설계 기반이 …
Source: applefish.tistory.com
Date Published: 5/29/2021
View: 6650
[평범한 스타트업 일상] 서비스 기획 살펴보기 – 모비인사이드
서비스 기획은 쉽게 말하면 우리가 가지고 있는 아이디어를 하나의 … 이러한 공통 사항은 서비스의 기본적인 프로세스나 비즈니스 모델과 연관돼 …
Source: www.mobiinside.co.kr
Date Published: 9/22/2021
View: 5378
서비스 기획 방법론과 업무 용어 정리 – 헤엄치는 먼지
챕터 01 – 서비스 기획이란 무엇이고 – 서비스 기획의 프로세스는 어떻게 되는지 – 서비스 기획 방법론 – 그리고 서비스 기획자가 기본적으로 업무를 …
Source: nimo0222.tistory.com
Date Published: 10/26/2022
View: 9658
혼자 서비스 기획을 공부하는 방법 | ㅍㅍㅅㅅ
101개의 비즈니스 모델이라고 되어 있는데, 101개의 스타트업과 서비스의 프로세스와 수익구조를 정리해서 보여주고 있다. 프로세스도 간단하게 정리하고 …
Source: ppss.kr
Date Published: 10/13/2022
View: 8996
한 번에 끝내는 서비스 기획의 모든 것 초격차 패키지 Online.
Pain Point | 취업도 어렵고 사수도 없는데 실무 노하우는 어디서 얻지? How | 가상 PM이 되어 실제 업무 미션을 수행해 봅니다. Goal | 오피스 경험 없이 실무 프로세스를 …
Source: fastcampus.co.kr
Date Published: 6/29/2022
View: 287
주제와 관련된 이미지 서비스 기획 프로세스
주제와 관련된 더 많은 사진을 참조하십시오 서비스기획 프로세스 알아보기 l UX. 댓글에서 더 많은 관련 이미지를 보거나 필요한 경우 더 많은 관련 기사를 볼 수 있습니다.
주제에 대한 기사 평가 서비스 기획 프로세스
- Author: 기획자 J
- Views: 조회수 3,992회
- Likes: 좋아요 76개
- Date Published: 2021. 1. 10.
- Video Url link: https://www.youtube.com/watch?v=UL9U2aLA9uM
서비스 기획[1]- 앱&웹 서비스 기획 프로세스
안녕하세요. 트라이브즈입니다. 현재 온라인 서비스 기획을 준비하며 기획을 진행하고 있습니다.
개인적인 경험으로는 서비스 기획에 대한 내용이 접하기 힘든 부분도 있고, 기획방법이 기업마다 사람마다 도구마다 틀려서 전체적인 방향을 잡기가 쉽지 않았습니다. 과정을 정리해 두는 것이 의미가 있는 작업이라 생각이 들었습니다.
요즘 트라이브즈는 서비스 기획 컨설팅을 받고 있습니다. 서비스 기획자인 ‘노노니’님에게 받고 있는데요. 수강한 내용을 트라이브즈에 적용해봤습니다. 우선 기획 부분에 초점을 두고 개발 전까지의 프로세스를 시리즈로 하여 상세하게 다루고 트라이브즈의 작업을 함께 나눠 보려 합니다
하나의 앱이나 웹의 서비스가 만들어진다는 것은 사실 큰 영역을 가지고 있습니다. 사업기획에서 아이디어 도출 서비스 기획 그리고 디자인, 퍼블리싱, 개발 그리고 지속적인 관리 거기에서 서비스 기획이라는 것은 초기 세팅 작업으로 전체 영역의 20%~30%를 차지하고 있습니다.
하지만 서비스라는 것은 초기의 시작이 중요하고 점진적으로 고도화시켜 나가는 것이 매우 중요하기에 범위에서는 20% 일지라도 중요성은 80%라 하여도 과언은 아닙니다.
웹 혹은 앱 서비스 기획 과정은 총 10가지로 나누어집니다.
1. 아이디어 도출
2. 최소안
3. 유저 시나리오
4. 기능 도출
5. 서비스 흐름도
6. 메뉴 구성
7. 정보마인드맵
8. 페이지 흐름도
9. 화면 설계
10. 스토리보드 (문서화)
하나하나 간단히 살펴보면서 알아가 보도록 하겠습니다.
웹&앱 서비스 기획 프로세스
1. 아이디어 도출 – 가능한 아이디어 브레인스토밍 작업
처음의 사업을 시작하며 무엇을 하고자 하는지 아이디어를 정리해야 합니다. 이때 많은 아이디어가 나오게 됩니다. 가능한 것도 있지만 가능하지 않은 것도 있습니다. 이때 모든 아이디어를 끄집어내어 취합해 내는 것이 중요합니다. 아이디어를 내는 방법에는 다양한 방법론들이 있습니다.
그중에서도 가장 효과적인 방법이 브레인스토밍으로 팀이나 관련된 사람들이 모여 아이디어를 끄집어내는 것입니다.
2. 최소안 도출 – 모든 아이디어 중에서 핵심이 되는 아이디어 도출
초기의 아이디어는 보통 거대하고 방대합니다. 저도 처음 웹을 기획하기로 하였을 때 서비스들이 너무도 다양하여서 정리하는데 무척이나 힘이 들었습니다.
고객의 관점에서 무엇이 가장 필요로 하고 문제를 해결해 주는지를 중심으로 가장 기초적인 서비스를 설계합니다. 이것을 최소안이라고 합니다.
예를 들면 카카오톡의 경우 여러 가지 기능들이 있습니다. 현재는 더 방대해졌습니다. 그러나 처음부터 그렇게 시작한 것이 아니라 처음에는 친구끼리 이야기를 보내는 톡 대화 기능으로 시작하였습니다. 이렇게 핵심 기능이 정해진 상태에서는 개발이 더 수월해지고 방향이 잘 잡히게 됩니다.
3. 유저 시나리오
최소 안이 완성되었다면 이것을 가지고 유저가 어떻게 서비스를 사용할 것인지를 처음부터 마지막까지 시나리오를 그려봅니다. 가장 중요한 기능이라고 생각하는 것들만 작성하고 더 상세한 부분은 기능 정의서에서 정의해 나가면 됩니다.
예를 들어 스타벅스의 경우 유저의 시나리오는 이렇게 구성됩니다.
이런 시나리오를 그릴 수가 있겠죠.
▶ 손님이 들어온다
▶ 메뉴를 선택한다.
▶ 결제를 진행한다.
▶ 대기표를 받는다.
▶ 음료를 알림 받는다.
▶ 음료를 받는다.
▶ 나간다.
▶ 혹은 자리에서 마신다.
이런 것처럼 서비스도 고객이 어떻게 사용할 것인지 핵심적인 덩어리 부분을 그려 줍니다.
저희의 서비스의 경우 워크 시트지를 선택하고 작성한 뒤 출력하고 배송해 줍니다. 그리고 미션이 저장되고 원하는 사람은 공유를 하는 것이 유저의 시나리오입니다. 이러한 것들을 공부하기 좋은 것은 자신이 좋아하는 앱이나 벤치마킹을 하고자 하는 서비스를 모델로 해서 연습으로 자주 그려 보는 것입니다.
4. 기능 정의 – 서비스에 필요한 기능의 정의
유저 시나리오에 따라 필요한 기능들이 있습니다. 주문이 있으면 결제 기능이 있어야 하고요. 회원가입 등 공통적으로 필요한 기능들도 있습니다. 이러한 기능들을 정의하는데 이러한 것들은 기능 정의서에 입력하여 줍니다.
기능 정의서는 상세한 설명과 더 구체적으로 배워야 하는 부분이기에 나중에 따로 정리를 하겠습니다. 서비스 기획자에게 필수적인 역할 중의 하나가 바로 기능 정의서입니다.
5. 서비스 흐름도 – 서비스가 어떻게 흘러가는지를 그려내는 것
서비스 흐름도는 각 서비스들이 어떤 순서를 따라 움직이는지 로직을 그려 보는 것입니다. 흐름도 역시 사람들이 처음부터 마지막까지 어떻게 서비스를 활용할지를 그려보면 도움이 됩니다.
6. 메뉴 구성 – 사용자 페이지와 관리자 페이지의 메뉴를 구성하는 것
메뉴는 GNB 메뉴를 구성하는 것인데 두 가지 관점이 필요합니다. 하나는 고객들이 보는 페이지에서의 메뉴 구성이고 다른 하나는 관리자 입장에서 메뉴 구성입니다. 개인적으로 서비스 기획을 처음 접하시는 분들이 공통적으로 어려워하는 부분이 바로 관리자 페이지입니다.
7. 정보마인드맵 – 각 정보에 관련된 내용을 카테고리별로 구성
다음은 정보에 관련된 내용들을 정리해 보는 과정이 필요합니다. 정보 마인드 맵의 경우 각 카테고리별로 무엇이 필요한지를 정보를 정리해 나가는 과정입니다. 이러한 분류를 통해 개발자들이 정보의 관계를 확인할 수 있습니다. 아래는 심플한 정보마인드 맵입니다. 실무에 들어가는 정보는 마인드맵 도구를 통해 훨씬 더 복잡해집니다.
서비스 페이지에서는 상당한 분량의 정보들이 구성되어 있는데 이러한 관계들이 정리가 되어 있지 않으면 개발 시 혼란을 겪을 수 있습니다. 보통 도구로는 싱크 와이즈와 마인드맵 도구를 활용하기도 합니다.
8. 페이지 흐름도(플로우 차트) – 각 페이지별로 어떻게 연결되어야 하는지 흐름을 구조화
앱이나 웹 서비스는 페이지간의 이동이 있습니다. 이러한 페이지 이동에 흐름을 아래와 같이 그려 주는 것이 필요합니다.
각 페이지 옆의 번호는 나중에 화면 설계서를 그릴 때 번호를 맞춰 개발자와 퍼블리셔들이 함께 확인하며 작업을 하게 됩니다.
일반적으로 각 도형들은 의미를 가지고 있는데 네모 박스는 일반적인 화명 이동이고 다이아몬드 박스의 경우는 서비스 사용자가 의사결정을 하는 페이지를 나타냅니다. [N] 은 No [Y]는 YES를 했을 때 다음으로 이동한다.라는 의미를 가지고 있습니다.
9. 화면 스케치 – 페이지 흐름도에 따른 화면 스케치
플로우 차트가 그려지면 화면 스케치를 합니다. 보통 손으로 작업을 많이 합니다. 이 작업을 바로 스토리보드 작업으로 들어가는 분들도 계신데 경험이 많으신 분들은 일반적으로 손으로 스케치를 하고 들어가신다 고 하세요.
아무래도 화면에서 바로 스토리보드 작업보다 구조나 기능을 손으로 그려보고 작업을 하면 더 작업을 효율적으로 할 수 있다고 합니다.
10. 스토리보드 – 도구를 활용하여 스토리 보드를 만들어 내는 것
이제 마지막 단계 스토리보드입니다. 화면 설계서라고도 하는데 이것을 통해 클라이언트, 기획자, 퍼블리셔, 개발자 가 소통을 하게 됩니다. 화면 설계서를 작성하는 것은 파워포인트의 목업 외에도 다양한 프로그램이 있습니다. 요즘은 미국에서 확산되고 있는 프로그램이 피그마라고 있는데 이것을 한번 활용해 볼까 합니다.
이것은 전체적인 서비스 기획의 순서를 나타낸 것이에요. 각 부분마다 이제 실무를 이해해 가야 합니다. 일주일에 하나씩 내용을 정리해 보도록 하겠습니다.
10년 차 기획자가 말해주는 쉽게 서비스 기획하는 방법
그렇다면 서비스는 어떤 과정으로 기획될까요?
1단계. 요구사항 분석
먼저 요구 사항에 대한 사업성 평가 후 진행 여부를 결정합니다. 마켓 사이즈와 성장 가능성, 독점기업, 법의 제약 등을 고려하고 종속된 산업의 환경과 트렌드 분석을 합니다.
2단계. 요구사항 정의
분석해보니, 이 프로젝트는 해볼 만해! 라면 요구사항에 대해 상세한 정의가 필요합니다. 프로젝트의 추진배경/목적/목표(단계별 목표)/구현 서비스 FLOW와 USER FLOW(Activity 중심으로)/마일스톤(단계별 성과 측정과 ROI를 위한 단계별 접근)를 말합니다.
3단계. 사업성 평가 후 진행 여부 결정
• 신규 기능일 경우
-시장이 크고, 서비스 지표 유지 전략이라면 제안 기능은 구현 진행하고
-시장이 작고, 서비스 지표 유지 전략이라면 제안 기능은 진행하지 않습니다.
• 신규 사업 일 경우
-제안 단계부터 참여한 모든 멤버가 모여 결정합니다. (또는 경영진의 결정)
4단계. 커뮤니케이션을 위한 UI 초안 리뷰
결정이 되면 다른 작업자들과 커뮤니케이션하기 위한 UI 초안을 그립니다. 배경도/다이어그램/Wire-frame/ERD…스킬이 허락되는 것들을 모두 이용하여 개발자/디자이너에게 0.9 이하 버전으로 Kick-Off 리뷰를 진행합니다. 이때 반드시 서비스 또는 기능의 콘셉트 메시지가 전달 되어야 한다. 그렇지 않으면, 프로젝트 진행 중에 외길 작업을 하는 멤버를 발견하게 됩니다. 리뷰 후 의견을 받아보는 것도 잊지 않아야 하죠.
5단계. 오픈 전략 수립
오픈하고 알리지 않으면, 오픈 한 달 만에 종료 프로세스를 밟아야 할 수도 있습니다.
• SEED 유저 모객
유저의 바이럴만으로 오가닉 성장을 보여주는 서비스들 역시, SEED 유저를 모으는 계획이 있었을 것입니다. 가장 쉬운 모객방법은 CBT입니다. 데스크탑 온라인 서비스는, 프로덕트의 완벽함을 위해 CBT를 진행합니다. 설치/삭제가 편리한 모바일 온라인 서비스는 기대감을 심어주고 SEED 유저를 모으기 위해 CBT를 진행하는 게 일반적입니다. 또는 셀럽을 활용하기도 합니다. 또는 한명 한명 영입하기도 합니다.
• 오픈 프로모션
소문난 잔치에 먹을게 없다는 말도 있지만, 일단 “소문난 잔치”가 되어야 합니다. 이벤트에 집중하는데, 이벤트보다는 어떤 플랫폼/어떤 타겟에 알려야 할지에 대해 집중해야 합니다. 단발성 오픈 프로모션이 아니라, 최소 6개월짜리 프로모션 계획을 세워두는 것이 후회 없는 프로모션을 했다고 볼 수 있습니다.
6단계. UI 기획안 1.0, 오픈전략 리뷰
오픈전략 배포 공유를 하는데, 프로모션 페이지가 있다면 반드시 사전에 개발/디자인 리소스를 요청합니다.
7단계. 디자인 시안 검토
디자인 시안이 공유되면, 기획자는 화면 단위로 UI 기획안과 크로스 체크 화면 단위별로 목표 달성이 되는지 확인합니다.
8단계. QA 시트 작성
QA(quality assurance) 시트를 작성합니다. 본래의 QA는 서비스 기획 단계부터, 출시 후 고객 의견까지 반영하는 걸 뜻하지만, 일반적으로는 서비스 기획자는 테스트 매니저 수준의 역할을 하게 됩니다. 디자인/개발에 피드백도 요청해야 합니다.
9단계. 테스트 진행
디바이스별 중요도에 따라 테스트 리소스를 분배하고, 이슈 리포트 및 담당자 어싸인을 받습니다.
10단계. 서비스 배포, 롤백 시나리오 협의
서비스 배포일 협의합니다. 되도록이면 금요일은 제외하세요. 배포 후 이상 증상 발견 시 롤백 시나리오를 협의해야 합니다.
11단계. 오픈 후 모니터링, 버그 픽스
12단계. 오픈 후 성과 보고 평가, 운영 방향 제시
서비스 기획의 역할과 실무 프로세스 정리
반응형
인프런
서비스 기획자는 웹에 대한 UI/UX기획을 해야 한다.
[필요 역량]-아이데이션 (아이디어 기획):
어떤 아이디어를 가지느냐에 따라서,
서비스의 방향과 컨셉이 정해지기
때문에 중요하다.
-내비게이션과 정보설계/구조에
대한 깊이 있는 이해가 필요하다.
서비스 기획이란
웹에서 어떤 비즈니스를 만들어서
그 비즈니스를 성공시키기 위해 서비스를
만드는 것이다.
그래서 기획자는 벤치마킹을 하고,
시장의 흐름을 이해하고,
아이디어와 현재 트렌드를 이해해서
이 모든걸 종합,
▶ 방향성을 구축할 줄 알아야 한다.
이 과정 속에서 커뮤니케이션을 많이 해서,
끊임없이 의견을 개선할 줄도 알아야 한다.
*
① 비즈니스를 하는데 있어서
웹을 도구로 하는 기획
▶ 그 앱을 사용하는 사용자를
이해하는 것이 중요하다!
[카카오톡]*문자메시지도 무료, 카톡도 무료인데
굳이 카톡을 쓰는 이유?
→익명의 사람들과 대화 가능
→이모티콘도 자유롭게 쓸 수 있다.
→ 프로필 사진도 지정할 수 있다.
ⓐ 유료인데 이모티콘을 굳이 사는 이유는?
ⓑ 이모테콘 정액제를 만든 이유는 뭘까?
기획자는 위 물음을 끊임없이
질문해봐야한다.
이런 것들을 쓰는 사용자를 이해해서
만들어진 서비스기 때문!
② 웹의 구조로 표현해야 함
③ 웹의 언어로 표현해야 함
[싸이월드]모바일 웹의 구조로 출시하지 못해서
잊혀져 간 플랫폼 서비스
→ 왜 모바일화되지 못했는가?
웹 비즈니스의 새로운 영역을 만들고
구축을 하려면
-마케팅 전략에 대해서도 충분히
분석을 하고 고려를 해야 한다.
-사용자 편의성을 고려해야,
원하는 방향대로 유저를 이끌어나갈 수 있다.
UX를 고려하는 이유는 사용자가
편의성에 대해 신뢰도를 가져야 하고,
이들이 이탈하지 않도록
끊임없이 신경을 써야 한다.
-카카오톡하면 노란색을 떠올리듯이,
서비스를 기획하고 방향을 설계할 때
기업의 아이덴티티를 생각해야 한다.
실제 업무프로세스는
UI 기획서로 콘텐츠를 배치하고,
와이어프레임을 그려서
완성된 기획서를 담당자에게
프레젠테이션 하는 것이다.
반응형
웹서비스, 앱 서비스 기획 과정 프로세스 정리
서비스 기획은 앱 또는 웹 이용자의 경험을 설계하는 것입니다. 그래서 같은 쇼핑앱, 게임, 금융 앱이라도 사용자는 다르다고 느끼게 됩니다. 좋은 웹/앱 서비스는 버그도 없어야 하지만 사용자 경험이 있어야 합니다. 이 서비스 기획의 과정을 정리해 봅니다.
서비스 기획 과정
먼저 서비스 기획을 진행하는 일반적 과정에 대하여 전체적으로 적어보겠습니다. 그 이후 서비스 기획 관련 중요한 이슈에 대한 것을 골라 기술하려 합니다. 이 글의 서비스 기획은 마케팅 서비스 상품론과 웹/앱 개발 현장에서 기획 경험을 바탕으로 된 것이므로 주관적일 수 있다는 점을 먼저 알려드립니다.
서비스 상품이 특징은 소비자가 구매를 하면서 생산이 이루어지고 동시에 소비가 이루어집니다. 서비스는 소비가 끝나면 사라집니다. 다른 잠재 소비자들은 서비스를 기 사용자의 리뷰/후기를 통해 알 수 있습니다.
서비스를 구성하는 요소는 다양합니다. 오프라인 서비스의 경우 서비스 제공 장소의 위치와 인테리어, 가격도 서비스의 구성 요소입니다. 특히 명성이 상당히 중요합니다. 스마트폰, 컴퓨터와 같은 물리적 제품처럼 사전에 확인할 수 없기 때문입니다. 또 다른 서비스 중요한 구성요소 중 하나는 소비자의 취향입니다. 갤럭시, 아이폰과 같은 브랜드처럼 서비스에 대한 평가는 상당히 주관적일 수 있는 이유입니다.
웹/앱 서비스에서 제공되는 기능이나 화면, 버튼 디자인은 이런 관점에서 웹/앱 서비스를 구성합니다. 그러나 버그가 없다면 더 중요한 것은 명성, 여기서는 사용 평가나 이용자 수, 언론이나 투자자 등이 더 중요합니다. 초기 서비스의 경우는 분명한 타깃 소비자에 맞추는 것 또한 매우 중요합니다. 초반 타깃 소비자를 맞추는 것이 명성을 형성하는 기초가 되기 때문입니다.
웹 기획자, 앱 기획자의 서비스 기획 첫 단계 목표 사용자 파악
서비스의 이런 특성으로 인해 웹/앱 서비스 기획은 서비스가 될 소비자의 니즈와 욕구를 파악하고 이 니즈와 욕구가 충족되는 과정에 대한 규정에서 시작되어야 합니다. 웹/앱 서비스 기획은 가장 기본이 되는 서비스 프로세스를 잡는 것이 성공의 핵심입니다.
[서비스 기획 과정 프로세스 정리]서비스 시장의 니즈와 욕구 파악 서비스 목표 소비자 설정 및 가치 구체화 목표 소비자 니즈와 욕구 달성을 위한 기능 도출 기능이 제공하는 기본 서비스 프로세스 정의 가치 전달의 위한 디자인, 화면 구조, 카테고리 정의 서버 등 물리 시스템, 개발 프레임워크 결정 사용자 프로세스 기획, ERD, 시퀀스 다이어그램 등 개발 기획, 서비스 디자인 기획 사용 프로그램(라이브러리, 오픈소스 등), 와이어프레임 설계 스토리보드, 화면 도출 후 디자인 가이드 작성 , 스토리보드에 따른 개발 프로그램 세부 내역 코딩, 서비스 화면 세부 디자인
서비스 기획 과정의 분류
서비스 기획 과정은 크게 두 부분으로 구분하여 볼 수 있습니다. 이 두 부분은 진행되는 작업과 요구되는 역량이 확연히 차이가 납니다. 때로는 어떤 한 부분의 기획자는 다른 부분을 기획자가 하는 일이 아니라고 생각하기 조차 합니다.
위의 서비스 기획 과정 프로세스 정리 내용 중 1~5까지 와 6~10까지 두 부분은 기획의 업무가 확연히 차이가 납니다. 서비스 기획의 후반부 6~10은 실제 웹/앱 개발을 위한 과정으로 SI나 웹에이전시에 외주를 주기도 합니다. SI나 웹에이전시 기획자인 경우 1~5까지 기획 내용은 잘 모르는 경우가 많습니다. RFP나 요구사항으로 전달되어 파악하는 정도입니다.
프로젝트 경험이 많은 SI나 웹에이전시 인력에 대하여 요즘 인기 있고 연동도 많은 IT 스타트업이 꺼려하는 이유 중 하나가 바로 1~5까지 경험이 없기 때문입니다. 그러면 결정된 일의 작업은 잘 하지만 차별화를 주어야 하는 창의적인 작업은 잘 못하게 됩니다. 한마디로 기획자든, 개발자든, 디자이너든 기획력이 없기 때문입니다. 기획은 다른 말로 설계라 할 수 있습니다. 설계를 못하는 개발자는 코더에 가깝기에 자체 서비스의 아이덴티티를 만들어야 하는 웹/앱 스타트업이나 서비스 기업 입장에서는 SI나 웹에이전시 인력의 프로젝트 경험의 의미가 없다고 평가하는 것입니다.
서비스 기획 초기 필요 인력
서비스 기획 초기에 해당하는 1~5까지 필요한 기본적 인력으로는 리더급 디자이너, 개발자, 기획자입니다. 물론 온전한 웹/압 서비스 개발을 위해 다른 역량의 인력이 필요하기도 하지만 개발 회사의 상황에 따라 다를 수 있고 반드시 필요한 인력의 위 세 종류 인력이라 할 수 있습니다.
디자이너는 서비스의 디자인 아이덴티티와 목표 소비자 니즈와 욕구에 대한 디자인적 감을 잡기 위해 반드시 필요합니다. UI 전문 웹디자이너 보다 UX 공부를 한 디자인 리더이면 더 좋습니다. 여기서 UX는 웹에이전시가 광고/홍보 구호로의 UI/UX가 아닌 인지심리학 역량이 있는 진짜 UX 디자이너를 의미합니다.
비슷하게 보이는 웹/앱 서비스라도 개발 환경과 프로그램은 다 다를 수 있습니다. 그러므로 리더급 개발자가 초기 기획 단계에서부터 작업을 해야 향후 개발 작업이 늘어날 때 적절하게 개발자를 충원할 수 있게 됩니다. 리더급 개발자가 없는 개발 현장에는 당장 필요 없는 개발자들이 놀고 있는 것을 자주 보게 됩니다. 또한 개발 기획이 없다면 코드가 늘어나고 새로운 기능이 생길수록 버그 가능성과 시스템 저하의 가능성이 커집니다.
리더급 기획자는 스토리보드를 그리는 기획자가 아닙니다. 많은 SI나 웹에이전시 개발 현장에서 기획자를 스토리보드 그리는 사람으로 보는 경향이 있습니다. 이 말은 개발자는 코딩을 하는 사람이라고 하는 것과 같습니다. 기획에서 스토리보드는 개발에서 코딩 작업과 비슷합니다. 수십억, 수백억 SI와 웹에이전시 프로젝트에서 실패가 많은 이유 중 하나가 기획 없이 고객의 요구사항에 따라 스토리보드 작업 후 개발하기 때문입니다. 롯데온이 2여 년이나 개발했음에도 론칭 후 문제가 많았던 이유도 이것 때문입니다. 개발 규모가 클수록 스토리보드에 앞서 기획의 필요성은 더 커집니다. 3~4명이 개발하는 스타트업 MVP의 경우는 스토리보드만으로 가능할 수 있습니다. 개발의 복잡성이 높을수록 스토리보드 이상의 기획 작업이 반드시 필요한 것입니다.
리더급 기획자를 구체적으로 언급하면 웹/앱 서비스 비즈니스 기획자, 마케터 중 마케팅 4P 중 제품 마케터로 웹/앱 제품 개발 마케팅을 잘 아는 기획자가 될 것입니다. 현재 시장에서 웹/앱 전문 기획자는 웹/앱 기획 경험이 많은 기획자를 지칭할 뿐 학문적으로나 학위적으로 높은 수준의 기획자를 의미하는 것은 아닙니다. 그리고 마케팅 기획, 디자인 기획, 개발 기획 등의 의미에서 처럼 기획이 독립된 의미를 가지는 것은 아닙니다. 기획의 단어적 의미는 계획, 설계에 가깝기 때문입니다.
앞으로 글에서 ‘서비스 기획 과정 프로세스 정리’의 세부 내용을 좀 더 살펴보기로 하겠습니다. 이에 앞서 SI나 웹에이전시 기획자가 쿠팡, 카카오, 배민, 토스 등 자체 웹/앱 서비스를 하는 기업의 기획자와 어떻게 다른지 설명하겠습니다. 저의 SI, 웹에이전시 경험의 시작이 SI 기업과 웹에이전시에서 자체 서비스를 진행하고 싶다고 해서 연락이 왔기 때문입니다. 그 SI 기업과 웹에이전시에 기획자가 있었는데 말입니다.
한눈에 정리하는 서비스 기획
10년이 넘게 마케팅과 신사업 기획, 플랫폼 기획, 광고 기획 등을 진행하면서 경험한 서비스 관련 경험 사례를 통해 서비스 기획을 정리하려 합니다. 우선 전체 서비스 기획 그림이 한눈에 들어올 수 있도록 정리한 후 세부 내용은 다른 글에서 자세히 작성하겠습니다.
서비스라는 용어의 정의는 기업 또는 업종에 따라 조금 다르게 사용하기도 합니다. 여기서는 서비스를 웹 또는 앱으로 제공되는 기능의 집합체로써 사용자가 느끼는 차별적이고 가치 있는 경험이라고 정의하겠습니다.
서비스-아이디어
웹 또는 앱에서 기능을 제공하더라도 단순히 앱으로 식당을 검색하고 주문하는 기능이 아니라 배달의 민족, 쿠팡 이츠처럼 각 앱의 배달 경험이 차별적이고 사용 유저가 돈을 낼 만한 가치의 경험을 제공하는 것을 서비스라 하겠습니다. 전자는 앱 개발로 서비스 이루어질 수 있는 공간과 기능을 만드는 것으로 구분합니다.
서비스 기획의 시작 – 비즈니스(사업) 기획
서비스 기획을 위해서는 서비스 대상과 목표를 구체화할 비즈니스 기획이 있어야 합니다. 흔히 비즈니스 기획 문서는 무엇을 해서 돈을 벌 것인가에 대한 실행 문서를 의미합니다.
비즈니스 문서에는 비용과 수익 항목으로 크게 구분이 됩니다. 비용은 서비스 제공을 위한 것이고 수익은 서비스 제공에 하면서 발생하는 사용 유저들의 구매를 통해 생깁니다.
비즈니스-모델-캔버스
이 과정을 가치를 생산하는 과정과 교환하는 과정으로 구분하여 볼 수 있으며, 이를 도식화한 것을 비즈니스 모델 캔버스라고 합니다. 서비스 기획은 가치를 생산하는 과정에 대한 기획 문서라고 할 수 있습니다.
어떤 서비스를 제공할 것인가?
비즈니스 기획이 완료되었다면 이에 따라 어떤 서비스를 제공할지에 대한 기획을 진행합니다. 이 단계에서부터 본격적인 서비스 기획이 시작된다고 보아도 맞을 것입니다.
서비스 기획은 크게 다음 세 가지 질문을 통해 그림을 잡아가기 시작합니다.
누구 에게 제공할 서비스인가?
에게 제공할 서비스인가? 무엇 을 제공할 서비스인가?
을 제공할 서비스인가? 어떻게 제공할 서비스인가?
누구는 핵심이 되는 목표 사용 유저를 의미합니다. 누구에게 제공할 것인가를 통해 핵심 기능과 서비스 프로세스가 결정될 수 있습니다.
무엇은 배달 서비스인지, 쇼핑 서비스인지 등 서비스 범위를 규정하는 질문이 됩니다.
누구와 무엇이 결합되면 서비스가 진행될 시장이 결정되고 그러면 경쟁해야 할 다른 서비스도 구체적으로 규정할 수 있게 됩니다. 더하여 핵심 기능과 프로세스, 경쟁 우위를 위해 여기에 추가해야 하는 기능과 프로세스 등이 구체적으로 도출될 수 있게 됩니다.
어떻게는 서비스 개발 방법에 대한 것이자 비용에 관한 질문입니다. 서비스 구현을 위한 기업 내 자원 상황을 파악하여 시장 내 경쟁 서비스보다 나은 가치를 제공할 서비스 개발 방법을 선택합니다.
MVP와 핵심 기능
스타트업이 되었던, 대기업이 되었던 서비스 기획의 시작은 가치를 구현할 핵심 기능이 무엇인가에서 시작되어야 합니다. 많은 대기업 서비스 개발 프로젝트가 수 십억 때로는 백억 원이 넘는 개발 비용을 투자하고도 실패하는 것은 처음부터 너무 많은 기능과 화면들을 개발하려고 하기 때문입니다.
프리랜서로 개발 프로젝트에 참여해 보면 3~4명의 스타트업도 만들 수 있는 정도의 개발 결과물을 수십 명이 만들고 있는 것을 보게 됩니다. 어떤 기능은 개발에 참여한 어느 누구도 왜 개발해야 하는지도 모르는 경우도 있습니다. 한 번은 상황 파악을 위해 고객 TF팀과 미팅을 하는데 고객도 지금 왜 해당 기능을 개발하고 있는지 모르겠다고 이야기하는 프로젝트도 있었습니다.
이런 개발 프로젝트는 대부분 벤치마킹 대상이 되는 유명 서비스가 존재합니다. 벤치마킹 해당 기업이 수년을 고민하고 사용자 데이터를 분석해 가면서 만들어 낸 서비스를 앱만 둘러보고 1년에 만들려고 하기 때문에 문제가 되는 것입니다.
대부분의 서비스는 처음부터 복잡하지는 않습니다. 처음에 간단하던 서비스가 사용자가 늘어나고, 많아진 사용자만큼 충분히 경제성 있는 요구가 발생하면서 제공하는 서비스 종류가 늘어나게 됩니다. 이렇게 시간이 흐르면 전체 서비스는 복잡해지는 것입니다.
그런데 복잡도는 문제를 일으킵니다. 실제 서비스를 운영해 보면 문제는 복잡도의 제곱 이상으로 발생하게 됩니다. 서비스 기능이 2배 늘면 문제는 4배 늘어나는 것입니다. 그래서 서비스가 커지면 개발자는 그 이상 늘어나는 것이 보통입니다.
그러므로 성공적인 서비스 기획을 위해서는 최대한 간단히 시작해야 합니다. 그리고 기획자는 항상 서비스의 핵심이 무엇인지를 파악하고 기획을 해야 합니다. 서비스 핵심에서 벗어난 기능은 아무리 요즘 인기 있는 기능이라도 과감히 빼야 합니다.
대기업에서 진행하는 대부분의 개발 프로젝트는 서비스 핵심부터 시작하지 않습니다. 대기업 가오가 있기 때문에 일단 화려하고 복잡하게 시작하려고 합니다. 여기서 문제를 가지고 시작하는 것입니다.
물론 서비스 기획의 시작은 MVP인 최소 기능 제품 또는 핵심 기능에서 시작해야 하지만 외주 개발이 되는 순간 고객 담당자와 외주 개발사의 니즈에 의해 그렇게 되지는 않게 되기는 합니다.
서비스 프로세스의 중요성
서비스의 핵심과 서비스를 통해 제공될 사용 유저의 가치를 서비스가 개발되어 운영되기 전에 알 수 있는 방법은 프로세스를 통해서 밖에 없습니다.
서비스 프로세스는 서비스 사용자가 경험할 서비스 가치를 나타내면서, 개발자에게는 무엇을 개발해야 하는지와 어떻게 개발할지에 대한 설계 기반이 되기도 합니다. 또한 서비스 프로세스가 있어야 기능과 기능의 연결과 데이터 이동에 대해서도 파악이 용이해집니다.
서비스-프로세스-예시
결국 서비스 기획은 서비스 프로세스에 의해 구체화된다고 해도 틀린 말이 아닐 정도로 서비스 프로세스는 중요합니다. 그렇다고 정해진 규칙이나 방법이 있는 것은 아닙니다. 비즈니스 목적이나 개발에 적합하게 설계되면 그것으로 족합니다.
그러므로 반드시 비즈니스 기획자와 개발자와 논의는 필요합니다.
디자인, 화면 구조 정의
사용자의 서비스 가치를 제공하는데 디자인, 화면 구조 또한 개발 이상 중요한 역할을 합니다. 그러므로 서비스 기획 문서에는 서비스 디자인 기획 관련 내용이 포함되어 있어야 합니다.
이는 디자이너가 작업하는 내용을 말하는 것이 아닌 디자인 작업 시 룩앤필의 방향성, 반드시 지켜야 하는 서비스 아이덴티티 관련 내용 등을 의미합니다.
또한 사용 유저의 서비스 경험 측면에서 준수해야 할 화면 구조가 있다면 이를 표시해야 합니다.
화면-구성-예시
앞의 내용들이 주로 개발자를 위한 서비스 기획 내용이었다면 이번의 내용은 디자이너를 위한 서비스 기획 내용이라고도 할 수 있습니다. 문서는 이 기준으로 작성되면 충분하고 반드시 지켜야 할 양식이 있는 것은 아닙니다. 만약 기업에 따라 특정 양식이 있다면 그대로 진행하면 됩니다.
서비스 카테고리 정의
IA(Information Architecture)라고 하는 정보 구조 작업으로 간단히 하면 사이트맵으로도 이해될 수 있습니다. 서비스 기획 시 작업되는 정보 구조는 핵심 서비스 프로세스에 기반합니다.
데이터 구조는 ERD 작업을 통해 개발자가 진행함으로 기획자가 작업하는 IA 작업은 서비스 카테고리를 구체화하는 작업에 가까울 것 같습니다. 이 관점에서 본다면 사이트맵이라고 해도 크게 틀린 말은 아닐 듯 생각합니다.
서비스 카테고리 작업은 제공되는 기능을 특성에 따라 묶는 작업에서, 화면을 구성하는 작업, 사용 유저의 이동 경로를 설정하는 작업 관점에서 진행할 수 있습니다.
서비스-카테고리-예시
각 관점에서 진행한 서비스 카테고리 작업의 결과는 같은 모습 같지만 관점의 차이로 세부적 내용에는 차이가 생기게 됩니다. 그렇다고 무엇이 맞다는 것은 없으므로 서비스 기획 상황에 따라 선택하여 진행해도 큰 문제는 없습니다.
서비스 카테고리 작업은 전문 프로그램을 활용하거나, PPT로도 작업할 수 있고, 엑셀로도 작업할 수 있습니다. 엑셀 작업의 경우 개발 시 앞으로 진행할 요구사항 상세화 작업 후 디자인 작업 화면을 도출하는데 활용되기도 합니다.
어떻게 개발할 것인가?
넓은 시각으로 보면 서비스 기획과 개발 기획의 차이는 없지만 좁은 시각으로 본다면 서비스 기획과 개발 기획은 다른 기획 작업으로 구분됩니다. 일종의 서비스 프러덕트 매니저의 업무와 제품 OEM 기업의 개발/생산 관리자 정도의 차이라 할 수도 있을 것입니다.
보통 온라인 서비스 개발이 외주로 진행될 때 서비스 기획은 고객이 하며 개발 기획은 SI에서 진행하기도 합니다. 그래서 서비스 기획자는 개발 목적물을 표현하기 위해, 개발 기획자는 서비스 기획자(또는 고객)의 의도를 파악하기 위해 요구사항 명세서를 작성하기도 합니다.
이때 서비스 기획 시 작업한 문서인 핵심 기능 정의서, 서비스 프로세스, 화면 정의서, 서비스 카테고리 정의, 디자인 아이덴티티 문서가 있으면 개발되어야 할 서비스를 파악하는 것이 용이해집니다.
주의 사항 – 서비스 보안
서비스 기획과 개발 기획의 차이는 문서의 보안 레벨에 있습니다. 서비스 기획의 상당 부분은 높은 보안을 요하는 것입니다. 그러나 개발 기획의 상당 부분은 서비스가 공개되면 누구나 알게 되는 부분으로 높은 보안 사항은 아닙니다.
유저가 서비스를 사용하면서 경험하는 차별적 가치가 단지 기능이나 디자인으로만 이루어지지 않는다는 사실에서 서비스 기획의 보안은 매우 중요한 것입니다. 이는 넷플릭스에서 추천 기능을 적용하여 공개하는 것과 이 추천 기능이 어떻게 작동하는지 알고리즘을 공개하는 것의 차이라 할 수 있습니다.
그러므로 외주 개발사에 전달하는 서비스 기획 문서와 내부적으로 진행하는 서비스 기획 문서는 달라야 합니다. 또한 보안 유지 각서도 반드시 필요합니다. 그래서 외주 개발 시에는 직접적인 서비스 기획 문서보다는 주로 요구사항 명세서로 개발 의뢰를 합니다.
기본적으로 서비스 핵심 알고리즘이나 데이터 관리 시스템은 외주 개발을 하는 것은 추천하지 않습니다.
많은 경우 SI 개발 프로젝트를 참여해 보면 전체를 외주 개발하는 경우가 대부분입니다. 그러기에 대부분의 외주 개발이 시작은 창대하고 마지막은 초라한 경우가 많은 것입니다.
괜히 개발자 연봉이 오르고 있는 것이 아닙니다. 바로 핵심 개발 부분을 개발하고 관리하는 것에서 온라인 서비스의 경우 사용자 경험이 달라지기 때문에 개발자에게 높은 연봉과 스톡옵션을 주는 것입니다.
솔직히 이런 핵심 개발 부분은 외주 개발로 흉내를 내는 정도이지 개발이 불가능하다고 보아도 틀리지 않을 것입니다. SI 개발자가 핵심 기능 개발을 할 수 있는 수준이라면 아마 쿠팡, 배민, 토스, 야놀자 같은 국내 기업이면 연봉 1억 이상에 스톡옵션, 구글이나 페이스북 등의 경우는 연봉 3~4억 원에 스톡옵션까지 제공하면서 모셔갈 것입니다.
요구사항 명세서와 개발 기능 정의, 서비스 정책 파악
특히 외주 개발 시 요구사항 명세서는 개발 목표 서비스를 한정하고 무엇을 최종 결과물로 해야 하는지를 알려주는 기준 자료입니다.
그러나 대부분 서비스 개발 관련 전문가가 아닌 개발 의뢰 고객의 관점에서 작성된 요구사항 명세서는 개발 목적물을 모호하게 표현하는 경우가 대부분입니다. 그러므로 개발 기획자는 요구사항 명세서 상세화를 통해 정확한 고객의 개발 목적물을 파악할 필요가 있습니다. 그리고 고객의 개발 의도에 대한 명확한 규정이 개발 완료 시 발생할 분쟁을 피할 수 있는 길이기도 합니다.
요구사항 명세서는 주로 개발 프로젝트 PM과 기획 PL이 진행하지만, 때로는 PM와 기획 PL이 실제 개발이 아닌 관리 목적으로 투입되는 경우도 있어 참여 기획자는 관심을 두고 있어야 합니다.
내부 개발의 경우 서비스 기획 문서를 통해 개발을 진행하고, 서비스 기획자가 개발 기획자이기도 하는 경우가 대부분이므로 요구사항 명세서가 필요하지는 않습니다.
요구사항 명세서 상세화 작업을 통해 도출되는 결과물은 크게 3종류가 있습니다.
서비스 정책
개발할 서비스 기능
최종 화면
서비스 정책은 전반적인 기능과 화면 개발 시 반영되어야 하는 것이므로 정확히 파악되어야 합니다. 기능과 화면은 백엔드 개발과 프런트엔드 개발의 범위와 규모에 직접적인 영향을 미치므로 또한 정확히 파악되어야 합니다.
요구사항 명세서 상세화는 한 번에 끝나는 것이 아닌 여러 번 협의와 수정을 거칠 수 있으므로 버전 관리가 중요합니다. 상세화 작업 버전 관리가 안되어 있는 경우 처음 요구사항과 최종 요구사항 차이의 근거가 부족하게 되어 분쟁의 소지가 되기도 합니다.
보통 요구사항 명세서는 엑셀로 관리합니다.
기능 프로세스 정의
요구사항 명세서에서 확정된 개발 기능의 프로세스를 정의하는 작업입니다. 위의 서비스 프로세스가 사용 유저의 경험 극대화를 위한 프로세스였다면, 여기서 진행할 프로세스는 개발 기능의 프로세스로 차이가 있습니다.
서비스 경험 프로세스 – 가치 형성을 중심으로 기획
기능 개발 프로세스 – 유저가 사용할 기능의 작동 과정과 그 기능과 연관되는 기능들의 관계를 중심으로 기획
기능 프로세스는 단순히 그 기능을 사용하는 유저의 과정을 구체화하는 것이 아닙니다. 이 과정에서 기능의 작동과 데이터의 형성, 조회, 변경, 저장 그리고 다른 기능과 연동 사항까지 꼼꼼히 작업합니다.
IA(Information Architecture)
제가 작업했던 외주 개발 프로젝트에서는 IA 작업을 사이트맵 정도이거나 최종 개발할 화면을 확정하는 관점에서 작업 정도 었습니다. 그래서 요구사항 명세서 상세화 작업만 잘해놓아도 어느 정도 IA는 작업이 되었습니다.
문제는 기획 PL 요구사항 명세서 상세화 작업을 하지 않거나, 요구사항 명세서를 고객이 아니라 기획 PL 의도대로 작성하는데에서 발생했습니다.
개인적으로 개발 작업했던 것 중 IA가 복잡하고 상세했던 것은 주로 자체 개발 시였습니다. 이때는 IA를 고민할 때 유저 경험 형성과 추천 및 취향 분석에 영향이 있을지, 정보 구조에 따라 발생 데이터가 어떤 차이가 있을지를 고민해 가면서 작업을 했었습니다.
디자인 기획, 와이어프레임
디자인과 디자인 기획은 다릅니다. 한때 이름을 대면 누구나 알만한 대기업에서 마케터를 하면서 특정 부분 디자인 기획을 총괄했던 적이 있습니다. 이때 경쟁 대기업 디자이너가 우리 기업 디자인이 좋다고 벤치마킹 차원에서 미팅을 요청했던 적이 있었습니다. 이때 저는 디자인 자체를 할 수 없어 대화가 곤욕스러웠던 적이 있습니다.
디자인 기획은 디자이너가 디자인을 잘할 수 있도록 콘셉트, 톤 앤 매너 등 방향성을 알려주고, 디자인 과정 중 불필요한 요인으로 영향받지 않게 관리해 주는 것이 주 업무입니다.
서비스 개발 시에도 이는 같습니다. 서비스 아이덴티티와 서비스 운영 기업의 CI, BI에 맞게 디자인 작업을 할 수 있게 기준과 방향을 제시해 주는 것이 디자인 기획의 핵심이 되어야 합니다. 안 그러면 디자인이 개인의 취향이나 유행에 흔들리게 됩니다.
화면 디자인과 화면이 기능 프로세스에서 어떻게 보이는지를 명확히 하기 위해 때로는 와이어프레임 작업을 진행하는 것이 좋습니다. 와이어프레임은 위의 화면 구성처럼 해도 되고 PPT로 주요 화면의 구조만 표시하는 형태, 이를 유저의 기능 사용 프로세스에 맞추어 표시하는 형태, 엑셀로 간단히 구조만 정리하는 형태 등 프로젝트 상황에 따라 다양하게 만들어 사용할 수 있습니다.
스토리보드
개발 기획의 최종 결과물은 바로 스토리보드일 것입니다. 위에서 작업한 모든 내용이 스토리보드에 들어있어야 합니다. 개발자나 디자이너는 때로는 스토리보드만으로 작업할 정도로 개발 기획의 최종 결과물입니다.
그렇다고 스토리보드 작업이 난이도가 매우 높다는 것은 아닙니다. 보통의 경우 스토리보드는 어느 정도 경력 있는 초급 기획자도 할 수 있는 작업입니다. 스토리보드 작업이 어려워지는 것은 스토리보드 이전에 완료되어야 하는 위의 기획 작업이 안 되어 있기 때문이 대부분입니다.
스토리보드 유형을 크게 나누면 2가지로 구분할 수 있습니다.
디자인을 위한 스토리보드
기능 개발을 위한 스토리보드
이 두 스토리보드의 성격은 완전히 다르므로 작성에 주의를 해야 할 필요가 있습니다. 디자인을 위한 스토리보드로는 기능 개발이 어렵고, 기능 개발을 위한 스토리보드로는 디자이너가 작업할 화면을 다 표시하는데 한계가 있을 수 있습니다.
작은 규모의 프로젝트에서는 하나의 스토리보드로 작업할 수 있지만 규모가 큰 프로젝트에서는 하나의 스토리보드로 디자인과 개발을 작업하는 게 어려운 경우가 생기게 됩니다.
그러므로 위에서 앞서 언급한 요구사항 명세서, 정책 정의, 기능 정의서, 화면 정의서, 기능 프로세스, IA, 디자인 기획, 와이어프레임 등의 문서가 중요한 것입니다.
이렇게 스토리보드 작업까지 완료되었으면 이를 개발자와 디자이너에 전달하고 기획자는 이들과 함께 개발을 진행합니다. 이제 본격적인 개발이 진행되는 것입니다.
[평범한 스타트업 일상] 서비스 기획 살펴보기
서비스 기획, 뭘 하는 걸까?
서비스 기획은 쉽게 말하면 우리가 가지고 있는 아이디어를 하나의 서비스, 제품으로 만들어가는 과정을 말한다. 서비스 기획은 무언가를 만들어내기 위해 고민하는 행위를 수반하는데, 무언가를 만들어낸다는 것은 사용자가 겪고 있거나 겪게 될 문제를 찾아내고, 문제를 해결하기 위한 방법을 고민해서 해결 방법을 만들어내는 과정이다. 즉, 다시 말해 서비스 기획은 사용자의 문제를 해결하기 위해 어떤 제품이 필요하고, 그 제품으로 무엇을 할 수 있으며, 제품과 서비스가 왜 필요한지 고민하는 과정을 수반하며 제품과 서비스가 어떻게 사용자에게 보이고 어떻게 사용자가 사용할 수 있을지도 고민하는 것을 말한다.
이 과정을 한 문장으로 압축하자면, 서비스 기획이란 어떤 제품이나 서비스의 생성과 소멸까지의 모든 과정을 고민하는 것이라고 볼 수 있다.
이번 글은 서비스 기획에 대해서 전체적인 과정과 각 과정에 대한 짧은 설명을 쓴 글이다. 글의 순서는 아래와 같다.
1. 문제 정의 2. 요구사항 정의 3. 기획 정책 수립 4. 기능 정의 5. IA / 순서도 작성 6. 와이어프레임 작성 7. 화면설계서 작성 8. 서비스 운영 정책서/매뉴얼 수립
1. 문제 정의
어떤 기획의 과정이든 문제를 정의하고 분석하는 과정은 필요하다. 서비스에 녹여낼 기능은 결국 어떤 문제를 해결하기 위한 것이다. 어떤 문제든 결국 서비스나 기능은 무언가를 해결하는 역할을 해야 사용자의 선택을 받고 수익을 창출할 수 있다. 그렇지 않다면 시장에서 외면받는 제품이 될 가능성이 매우 높다.
그래서 기획의 출발점은 언제나 문제를 분석하고 정의하는 것이다. 만약 아직 아무것도 만들어진 것이 없고, 이제 막 시작하는 단계라면 설문조사나 인터뷰를 통해 문제를 발굴해야 한다. 그리고 정말 문제가 맞는지를 검증하는 과정도 거쳐야 한다. 이때는 시간과 비용이라는 리소스가 다소 발생할 수 있다.
만약 이미 만들어진 것이 있고, 사용자도 있다면 사용자의 목소리를 듣기가 상대적으로 수월하다. 플레이스토어나 앱스토어에 올라온 리뷰를 통해서든 고객센터를 통해서든 수많은 사용자의 목소리를 들을 수 있다. 거기서 공통적으로 문제를 제기하는 부분이 있다면 시급성이 높은 문제로 선정해서 기획을 진행할 수 있다.
2. 요구사항 정의
해결할 문제를 정의했다면 문제를 해결하기 위한 요구사항을 정리해야 한다. 요구사항을 정의하는 것은 문제 해결을 위한 솔루션의 윤곽을 그려보는 일이다. 어떤 기능이 있어야 문제를 해결할 수 있을지를 고민하고, 해당 기능이 어떻게 문제를 해결할 수 있을지를 정리한다.
이렇게 정의한 요구사항을 토대로 개발자와 디자이너와 리뷰를 진행한다. 개발자와 해당 요구사항이 우리의 기술력으로 구현 가능한 것인지, 가능하다면 기간이나 비용이 얼마나 발생할지 논의한다. 디자이너와 해당 요구사항이 어떤 모습으로 사용자에게 전달되면 좋을지, 어떤 사용자 가치를 제공할 수 있을지를 논의한다.
3. 기획 정책 수립
서비스 정책을 수립하는 일은 일반적으로는 앞서 요구사항부터 매뉴얼 수립까지의 전 과정을 지칭하기도 한다. 그래서 구분하고자 기획 정책이라는 용어를 사용했다.
이 단계에서는 주로 용어 정의와 공통 정책을 수립한다. 물론 구체적으로 개발되거나 디자인돼 있지 않은 상태이기 때문에 실제 개발 과정에서 수정되거나 추가되기도 한다. 이 단계를 먼저 진행하는 이유는 추후 개발 과정을 원활하게 하기 위해서다.
용어 정의: 어떤 기능에 어떤 명칭을 사용할 것인가?
제품을 만들어가는 팀이 공통적으로 사용할 용어를 정리하는 과정이다. 이를 통해 제품을 개발할 때 발생하는 다양한 커뮤니케이션 상황에서 잘못 이해하는 문제를 미리 방지할 수 있다.
가령 ‘안내 문구’와 ‘확인’, ‘취소’ 버튼이 포함된 메시지 창에 대해 각각 ‘컨펌창’, ‘모달’, ‘팝업’이라고 다르게 표현한다면 실제로 만들어진 제품과 디자인은 기획자가 의도했던 것과 다를 수 있다. 이러한 문제는 용어를 정의하면서 해결할 수 있다.
공통 정책 정의: 서비스의 기본 골격은 어떻게 되는가?
서비스에 공통적으로 적용되는 사항이 있을 수 있다. 가령 회원에 대한 정의나, 상품 판매, 결제 및 환불에 관한 규정과 같은 것들이다. 이러한 공통 사항은 서비스의 기본적인 프로세스나 비즈니스 모델과 연관돼 있기 때문에 기능이 세부적으로 정의되지 않았다 하더라도 사전에 정리할 수 있다.
공통 정책을 정리하면 개발팀에서는 DB 설계나 관련 기술 검토 등을 선제적으로 진행할 수 있다. 그러면 최종 기획안이 나와 본격적인 개발에 착수해서 제품을 개발하는 과정에서 발생하는 시간을 상당 부분 줄일 수 있다.
4. 기능 정의
요구사항 리뷰를 통해 개발이 가능한 요건을 정리했다면 이제 해당 요구사항을 세부적으로 정의해야 한다. 세부적으로 정의한다는 것은 각 기능의 구성요소를 정리하고, 구성요소가 어떻게 동작해야 하는지, 어떤 데이터를 입력하는지, 입력한 데이터 값에 따라 어떤 결과를 노출해야 하는지와 같은 로직을 정리하는 것을 말한다.
5. IA / 순서도 작성
기능 정의가 각 기능을 하나하나 개별적으로 파악하기 위한 것이라면 IA(Information Architecture, 정보구조도)나 순서도(flowchart)는 전체 구조를 파악하기 위해 작성하는 문서다. 이를 통해 개발자나 디자이너가 작업하기에 앞서 서비스와 서비스의 구조를 이해하기 쉽게 도와준다.
IA는 정보구조도라고 하는데, 트리 형태로 웹사이트의 메뉴 구조를 표현한 것이다. 엑셀로 작업하는 경우가 대부분이며, 사이트 화면이나 메뉴를 기준으로 그룹화하고, 각 화면이나 메뉴를 깊이(Depth) 단위로 분류해서 설계한 문서다.
순서도는 화면 흐름도라고도 하는데 기능이나 작업이 처리되는 과정을 기호나 도형으로 도식화한 문서다. 화면이나 기능 단위로 표현하고, 사용자의 제품 사용 동선을 기준으로 제품 프로세스를 도식화한다.
6. 와이어프레임 작성
와이어프레임(WireFrame)은 점과 선 등을 활용해 화면을 간략하게 표현한 것을 말한다. 정의된 각 기능이 화면에 어떠한 모습으로 그려져야 하는지, 어떻게 표현돼야 하는지를 와이어프레임을 통해 구현한다. 예전에는 PPT를 활용해서 작성하는 경우가 많았으나, 최근에는 Adobe XD, Sketch, Figma 같은 디자인 툴을 활용해 작성하는 경우가 많다. 사용법과 기능을 습득하기 어렵지 않으며, 와이어프레임 작성을 위한 여러 플러그인을 제공해서 쉽고 빠르게 그려낼 수 있기 때문이다.
기획자가 작성한 와이어프레임을 토대로 디자이너는 디자인 작업을 진행한다. 다만 최근에는 디자이너가 와이어프레임을 그리는 경우가 많아지고 있다. 기획자가 그려놓은 와이어프레임을 토대로 디자인 작업에 들어가는 경우 기획자가 만들어놓은 프레임에 갇혀 디자이너의 창의성이나 전문성이 드러나지 못하는 경우가 많다. 화면을 그리는 부분은 아무래도 기획자보다는 디자이너가 전문가이기 때문에 와이어프레임 역시 디자이너가 작업하는 경우가 늘고 있다.
7. 화면설계서 작성
화면설계서는 제품을 개발하기 위한 최종적인 기획 산출물이라고 볼 수 있다. 화면과 화면설명 영역(Description)으로 구성돼 있다. 이제까지 작성했던 기획 산출물로 보자면 와이어프레임(또는 디자이너가 작업한 디자인 화면)과 기능 정의가 합쳐진 형태라고 생각하면 된다. 개발자는 화면설계서를 통해 한 화면에서 어떠한 기능이 존재해야 하는지, 어떻게 동작해야 하는지를 확인할 수 있다.
8. 서비스 운영 정책서/매뉴얼 수립
서비스 운영 정책서 및 매뉴얼은 서비스를 운영해야 하는 내부 직원을 위해 작성하는 문서다. 서비스 운영을 담당하는 내부 직원의 경우 제품 개발 과정에 참여하지 않기 때문에 실제로 개발이 완료된 제품과 제품의 각 기능의 세부적인 내용이나 프로세스에 대해서는 모르는 경우가 발생한다.
제품의 프로세스에 대해 명확하게 파악하고 있지 않은 경우에는 제품을 운영하기 위한 내부 툴이나 기능을 사용하기 어렵고, 고객의 불평이나 문의에 빠르고 정확한 답변을 주기 어려워 고객의 만족도를 떨어뜨리게 된다.
서비스 운영 정책서는 전문 용어를 쓰거나 복잡하게 작성하지 말고 누구나 이해할 수 있도록 쉽고 명확하게 써야 한다. 또한 반드시 목차가 있어야 한다. 읽는 대상이 제품 개발에 대한 전문적인 지식이 부족한 경우가 대부분이고, 고객의 불평이나 문의에 빠르게 답변하기 위해서는 목차를 통해 적절한 답변 및 대응방식을 빠르게 찾아내야 하기 때문이다.
결론
오늘은 전체적인 서비스 기획 플로우에 대해서 설명해보았다. 지금까지 설명한 일련의 과정들이 하나의 제품 또는 기능을 구현할 때 필요한 서비스 기획의 큰 흐름이라고 볼 수 있다. 이 일련의 과정을 통해 하나의 제품이나 기능이 만들어지고 사용자에게 전달되어 사용된다. 다만 이 글에 적힌 일련의 과정이, 그리고 여기서 표현한 용어들이 정답은 아니다. 서비스 기획의 방식은 회사마다 다르고, 업무를 진행하는 사람마다 다를 수 있기 때문이다. 다만 전체적인 큰 흐름은 대부분 이 글에서 적은 과정과 비슷할 것이다. 이번 글을 통해 서비스 기획에 대한 전체적인 흐름을 바라보는데 참고가 될 수 있기를 바란다.
June님의 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
서비스 기획 방법론과 업무 용어 정리
챕터 01
– 서비스 기획이란 무엇이고
– 서비스 기획의 프로세스는 어떻게 되는지
– 서비스 기획 방법론
– 그리고 서비스 기획자가 기본적으로 업무를 진행할 때 알아야 할 용어들
챕터를 찢을 생각은 없었으나, 생각보다 너무 긴 강의 시간 때문에 정리가 어려워서 2개로 나눈 포스팅…
서비스 기획에 대한 전체적인 강의내용 정리는 앞 포스팅에 정리해 두었다.
https://nimo0222.tistory.com/entry/서비스-기획이란-서비스-기획의-프로세스
자, 그럼 이번 포스팅에서 다룰 주제는 바로
[ 서비스 기획 방법론 (애자일, 린, 워터폴의 차이) & 기본 용어에 대한 정리 ] 이다.애자일 vs 워터폴
– 워터폴 (Waterfall): 개발의 흐름이 마치 폭포수처럼 지속적으로 위에서 아래로 향하는 것처럼 보이기 때문에 ‘워터폴 방법론’이라고 부르고 있다. 다만 ‘애자일이 워터폴보다 뛰어나다’고 할 순 없으며, 각 상황과 조건에 맞는 방법론을 적용해야 하는 게 맞다.
<장점>
– 대규모 팀의 합의점 도출이 용이함
– 개발주기가 정해져있어 일정관리가 안정적으로 가능함
– 요구사항이 픽스되어 목표변경에 따른 혼란이 방지됨
<단점>
– 개발속도가 상대적으로 느림
– 개발 방향성에 대한 유연성이 부족함
– 처음 방향성 설정이 잘못된 프로젝트라면 프로젝트 자체가 엎어질 수 있다는 위험이 있음
<적합한 조직>
– 커뮤니케이션 비용이 높은 대규모 팀
– 순차적 프로젝트 타임라인 수립이 필요한 팀
– 애자일 (Agile): 최신 개발 방법론이자 현업에서 가장 많이 회자되는 방법론. 일정한 주기를 가지고 계속해서 프로토 타입을 만들어 내어 그때그때 필요한 요구사항들을 바탕으로 개선해 나가면서 점진적으로 소프트웨어 개발을 완료해 나가는 형태. 즉, 여러 번의 프로세스를 통해 개선하고 발전시켜 나가는 방법론이다. 시장 변화가 빠른 요즘 가장 각광받고 있다.
<장점>
– 개발과정이 유연하고 빠름
– 소규모 팀이 병렬적으로 과제를 할당받아 진행이 가능함
– 테스트 및 리뷰에 따른 빠른 의사결정이 가능함
<단점>
– 변경내역이 너무 잦을 경우 목표에 혼란이 올 가능성
– 짧은 프로젝트 반복주기에 따른 높은 업무 집중도
<적합한 조직>
– 고품질의 결과물과 지속적 개선에 초점이 맞춰진 팀
– 사업 타당성이 완벽히 검증되지 않은 소규모 팀
서비스 기획 업무를 진행하면서 필수적으로 알아야 할 기본 용어들!
– FE (Front-End): 사용자에게 클라이언트를 통해 다양한 콘텐츠를 제공하고, 사용자의 인풋에 반응하여 동작하는 영역
– BE (Back-End): DB(Data Base)를 저장하고 관리하며, 클라이언트의 요청에 따라 정보를 내려주는 역할을 하는 영역
– 벤치마킹: 경쟁사나 특정 분야에서 좋은 성과를 보이는 상대를 표적으로 현황 및 성과 차이를 비교하는 분석 (꼭 좋은 성과를 내는 상대가 아니더라도 참고할 만한 상대를 조사하는 모든 행위를 벤치마킹이라고 할 수 있음)
– FGI (Focus Group Interview): 정성조사의 한 가지 방법으로 조사 진행자가 소수의 조사 대상자들을 한 장소에 모아 인터뷰를 진행함 (외부 리서치에서 많이 사용, 서비스나 제품의 개선을 위해 각자의 타겟 고객층을 대상으로 그룹 인터뷰를 진행하는 것을 말함)
– 로그: 서비스 내에 발생하는 모든 동작과 이벤트에 따른 정보를 시간에 따라 남기는 데이터, 이를 분석하는 걸 ‘로그 분석’이라고 한다.
– 대시보드: 서비스 내 혹은 서비스간 다양한 데이터를 동시에 비교할 수 있게 해주는 여러 뷰의 모음
– 데이터 트래킹: DB에 저장된 데이터를 다양한 툴을 활용해 추출하는 업무
– 페르소나: 어떤 제품이나 서비스를 사용할 만한 목표 연구 집단 안에 있는 다양한 사용자 유형을 대표하는 가상의 인물 (‘빵집에 자주가는 20대 남성’, ‘빵집에 자주 가는데 크림빵만 사는 20대 키 175cm 이상의 남성’과 같이 몽타주를 딸 때처럼 서술이 상세할 수록 페르소나 설정에 도움이 됨)
– KPI (Key Performance Indicator): 목표를 성공적으로 달성하기 위해 핵심적으로 관리해야 하는 요소들에 대한 성과지표 (매출, 사용자 지표, 클릭율, 방문율 등 서비스 현황과 목표에 따라 KPI 설정이 달라질 수 있음)
– 로드맵: 구체적인 이행 목표를 세운 뒤 목표 달성을 위해 작성된 가이드라인 (정해진 목표 달성을 위한 ‘마일스톤’을 모두 모아놓은 것)
– 마일스톤: 프로젝트 진행 과정에서 특정할 만한 건이나 표를 뜻하며, 주로 진행상황 체크를 위해 설정
– 리소스: 프로젝트 달성을 위해 필요한 자원을 뜻하며, 주로 프로젝트 참여 인원의 참여 가능 범위를 지칭하는 용도로 사용
– 리뷰: 완성된 기획서, IA 등 문서가 완성되었을 때 프로젝트 참여인원에게 공유하는 자리 (기획의 산출물이 나왔을 때 유관부서 인원들에게 이를 공유)
– 회고: 프로젝트가 마무리된 이후 참여인원들과 프로젝트 진행에 대한 의견을 교환하는 자리
-IA (Information Architecture): 정보구조도, 주로 서비스 전체 아웃라인을 조망하기 위하여 사용 (IA라는 큰 그림을 기준으로 이해 관계자들과 다양한 논의를 하게 된다고 보면 된다!)
– 와이어프레임: 서비스의 레이아웃을 구상하는 초안 단계에서 주로 서비스 플로우를 집중적으로 확인하기 위해 작성하는 화면 (어떤 버튼을 눌렀을 때 어떤 반응이 나와야 하는지에 대해 그리는 도면)
– 상세기획서: 스토리보드를 중심으로 페이지 구성과 기능, 정책 등 서비스와 관련된 모든 내용을 담은 최종 산출물인 기획서
– 플로우차트: 특정 기능 혹은 서비스 플로우의 흐름을 특정한 순서도 기호를 사용하여 도식적으로 표현한 다이어그램
– 어드민: 서비스 운영을 위한 관리자 페이지이며, 운영에 필요한 권한관리, 통계 등의 기능에 제공되는 페이지 (내부 인원들만 볼 수 있는 페이지이며, 어드민 페이지를 어떻게 설계하느냐에 따라서 서비스 운영의 요소가 달라질 정도로 중요함)
– 칸반보드: ‘칸반’은 소프트웨어 개발팀에서 많이 사용하는 방식으로, 팀의 작업 수용량에 따라 수행해야 할 업무를 시각화한다. 열과 카드를 활용하여 워크 플로우를 계획할 수 있는 시각적 프로젝트 관리 형태 중 하나이다.
728×90
혼자 서비스 기획을 공부하는 방법
기획을 배우려면 기획을 해봐야 한다
지금 강의하는 곳에서도 그렇고, 내 글의 모든 곳에서 가장 강조하는 것은 바로 기획 경험이다. 기획에 대한 흔한 착각이 ‘무에서 유’로 아예 세상의 없던 것을 창조해야한다는 생각이다.
사실 기획은 ‘창조가 아니라 구현을 위한 정리’라고 봐야한다. 이 세상에 특별히 새로운 것도 거의 없고, 사람의 생각은 사실 거기서 거기다. 좋은 서비스는 아주 간발의 차이로 발생하는데, 온라인의 서비스 프로덕트라면 더더욱 온라인의 생리를 이해하는 것이 중요하다.
그렇다면 온라인 서비스의 기획이란 무엇을 공부해야하는가?
기획자가 예쁘게 툴을 사용하는 것을 익힌다고 해서 기획을 잘하게 되지 않는다. 왜냐하면 UI는 고객 UX와 IT 시스템, 그리고 정책과 전략이 한데 어우러져서 나온 최종 산출물이기 때문이다. 전제조건이 없는 상태에서의 기획은 디테일과 케이스 구분이 쉽지 않기 때문에 기획 난이도가 쉬울 수밖에 없고, 크게 공부가 되지 않는다는 단점이 있다.
다시 한번 강조하지만, 기획 직무의 시작도 끝도 시스템에 속한 데이터와 디지털 산출물에 있다. 자신이 맡은 시스템의 구조를 파악해서 확인가능한 데이터 판단 지표를 통해 프로덕트의 생애주기와 전략을 체크하고, 구현 가능한 시스템을 기획하고 만들어 나가야한다. 물론 이런 전략의 핵심에 End User의 이용에 대한 경험관리를 통해 User를 계속 늘리고 수익을 최대화 할 수 있는 것은 기본중의 기본이다. 법적인 문제가 없는지에 대한 분석도 당연히 필요하다.
그렇다면 회사에 속하지 않는 상태에서 기획공부는 불가능한 것일까? 시스템도 없고 데이터도 없는 상태에서 기획공부를 할 수 없을까? 그냥 상상속의 새로운 서비스의 UI를 그려보고 만족하는 것으로 끝나서는 안된다고 해도 기획을 생각하는 방식 자체는 일정 부분 연습이 가능하다. 오늘은 회사가 없는 기획자 꿈나무들을 위해 혼자서 서비스 기획 연습을 하는 방법을 준비해봤다.
기획을 공부하는 방법 : 역기획
혼자서 서비스 기획을 연습하는 방법 중에 하나는 역기획이다. 역기획이란 이미 기존에 만들어져 있는 서비스를 보면서 역 으로 어떻게 기획되었는지 정리하는 방식을 말한다. 특별할 것 하나도 없다는 생각이 들지 모르겠지만, 역기획을 한다는 사람들의 산출물을 보면 실망스러울 때가 많다. 본인이 이용자로서 본 UI를 다시 와이어프레임으로 그려놓고 인터렉션만 냅다 분석해서 디스크립션을 써보는 연습이 많다. 이건 화면설계서(SB) 연습이라고 해도 의미가 없다. 관찰은 현상일 뿐이고, 기획은 사고의 과정이기 때문이다. 사고의 과정을 따라해야 역기획이 된다.
그렇다면 제대로 된 역기획은 어떤 방식이어야 할까? 정말 제대로 된 화면설계서의 디스크립션에는 서비스내에서 분류되는 케이스별 형태와 시스템의 피드백 그리고 데이터와 어드민 백오피스에 따라서 정의되어야 하는 수많은 로직을 포함하고 있다. 즉, UI를 UI 자체로 바라보는 것이 아니라 디스크립션을 쓸 수 있을 만큼의 전제조건과 가설을 생각해봐야 한다. 결국은, 데이터와 로직을 주어진 조건내에서 파악하는 것이 역기획의 핵심이 된다.
게임기획의 경우에는 다른 서비스기획에 비하여 데이터 중심의 역기획이 보편화되어 있다. 이 글에는 게임의 밸런싱을 역기획해서 공부하는 방법이 나와 있는데, 역기획의 핵심적인 방식에 대한 힌트를 얻을 수 있다.
자, 이제 본격적으로 역기획을 해보자
STEP1. 서비스를 선택하고 서비스 구조와 수익구조를 파악한다.(비즈니스모델 파악)
일단 여기서부터 막힐 수도 있다. 대체 어떤 서비스를 선택해야 이런 것들을 조사하기 쉬울까? 여기서 가장 중요한 기준은 ‘데이터 가설’을 세울 수 있느냐는 점이다. 온라인 서비스란 아무리 인터페이스가 화려해보여도 결국 데이터를 입력하고, 특정한 과정을 통해서 다른 형태로 데이터를 출력하는 서비스다. 화면 단위로 보지 말고 서비스 전체로 본다면 이 데이터의 큰 흐름이 눈에 보인다.
유튜브와 같은 플랫폼이라고 가정해보자. 화면단위로 본다면, 메인/동영상검색/상세 이런 식으로 리스트를 잡겠지만 서비스의 관점에서는 커다란 구조의 프로세스를 찾을 수 있다. 동영상을 등록하는 사람과 동영상을 보는 사람, 그리고 여기에 광고와 동영상 리스트를 매칭하는 추천 기술 세가지가 핵심적인 구조다.
여기에 비즈니스 수익구조도 파악해야한다. 유튜브는 돈을 누구에게서 벌까? 사용을 하면서 눈치챈다면 좋겠지만 어려울 경우에는 관련 자료를 통해서 파악해볼 수 있다. 해당 서비스에 관련된 기사에서 힌트를 얻는 것은 가장 좋은 방법 중 하나다.
물론 여기서 다루는 정보가 100% 맞는 것일 수는 없다. 하지만 어느정도 명확하게 스스로 이해할 틀을 마련하는 것이 중요하다. 유튜브는 두말할 것도 없이 동영상에 들어간 광고모델이다.
만약 알고 싶은 서비스 선정부터 어려움이 있다면, 아래의 책에서 선택해보는 것도 추천한다. 101개의 비즈니스 모델이라고 되어 있는데, 101개의 스타트업과 서비스의 프로세스와 수익구조를 정리해서 보여주고 있다. 프로세스도 간단하게 정리하고 있어서 서비스에 대한 분석을 할 때 참고하기 용이하다. 단, 국외의 서비스를 대상으로 해놓은 것도 많아서 잘 선별하여 본인이 접근가능한 서비스를 선택할 필요는 있다.
STEP2. 데이터 가설을 설정하고 서비스를 써보면서 검증한다
어느 정도 서비스 자체의 비즈니스 모델에 대해서 분석했으면 이제 데이터 가설을 세울 차례다. 유튜브를 기준으로 했을 때, 핵심 기술은 ‘매칭’이다. 비즈니스 모델에서 가장 핵심적으로 보이는 부분에 대해서 집중해보는 것이다.
동영상을 보는 사람에게 어떤 기준으로 추천을 해주는가? 동영상에는 어떤 광고를 매칭시키는가?
반면에 메루카리 같은 중고게시판이라면 서비스 프로세스 단위로 기능을 확인하면서 확인해볼 수도 있다.
이러한 두가지 매칭에 대한 가설을 세우기 위해 서비스를 이용해보기 시작해야한다. 이러한 가설을 세우기 위해서는 어떤 데이터를 가지고 있는지부터 판단해야 한다. 화면상에서 동영상 등록하는 시점에 획득하는 데이터(입력 내용)은 무엇이며, 동영상을 보는 사람에게서 획득하는 데이터에는 어떤 것들이 있을 수 있는지 스스로 각 프로세스의 일부가 되어서 직접 입력하거나 자동으로 수집 가능한 데이터들을 확인해야한다.
어떤 데이터들이 모여있는지 각자의 방식으로 세부 컨텐츠의 카테고리를 구분하고, 키워드에 따라서 광고가 나오는 것과 동영상을 클릭하고 볼 때마다 추천되는 동영상 리스트가 어떻게 바뀌는지를 살펴보면서 로직에 대한 가설을 세워야 한다. 이 가설을 100% 맞다고 확인해 줄 수 있는 방법은 없지만 이것이 로직과 알고리즘적으로 구현이 가능한지에 대해서 생각해보는 것이 중요하다.
완벽하게 모든 요소요소와 케이스의 파악은 어렵지만, 전체적인 그림을 비즈니스 모델에 맞춰서 판단하고 그 서비스에 서 보여주는 프로세스와 플로우를 찾아내는 것이다.
이 부분을 하다보면, 나중에 실제 기획업무를 하면서 기획을 하는 것도 오류를 찾는 것도 다 비슷한 사고방식을 통해서 진행된다는 것을 깨닫게 된다. 케이스를 구분하고 동작의 가설을 세우고 실제와 비교를 한다. 그리고 생각과 다르다면 그 이유를 찾아내는 것이다. 그리고 이유에 대해서는 STEP3에서 추가 정리가 필요하다.
STEP3. 회사의 목표와 전략, 특징에 대해서 조사하고 분석하여 코멘트를 단다.
생각한 가설과 다른 경우, 고객에게 도리어 불편한 경우가 있다. 일반적인 UX를 하는 사람들은 이런 부분에 대해서 화를 낸다. 그치만 누 가봐도 오류가 아니고 기획자라면, 그 불편함이 의도된 것은 아닌지 확인해봐야한다.
계속 예를 들고 있는 유튜브에서 광고를 처음부터 스킵할 수 있는 기능을 넣는다면 고객에게는 더 편하다. 하지만 광고를 본다는 보장이 되지 않는다면 광고주는 광고를 삽입할 이유가 없다. 유튜브는 광고를 처음부터 보고 싶지 않으면 광고수익을 보전할만한 유료 멤버십인 ‘유튜브 프리미엄’에 가입할 것을 권유한다. 그런 이유로 일정 부분이상 광고를 스킵하면 다음에는 ‘유튜브 레드’의 홍보가 나오게 되는 것이다.
각 화면속에는 회사가 원하는 것과 어쩔 수 없는 것이 숨어있다. 회사도 원할 것같지 않고 고객도 원할 것 같지 않는 고객 경험을 제공하고 있다면, 다음에 살펴봐야할 부분은 법령이다. 각 국가의 산업에는 관련 법령이 있고, 거기서 규제하는 것들이 무엇이 있는지 찾아봐야 한다. 법전을 뒤질 필요 없다. 대부분 관련 기사에 효과적으로 요약되어 있기 마련이다.
최종적으로 전체 서비스 프로세스를 도식화하고 각 데이터항목의 흐름과 알고리즘을 이해한대로 작성해보자. 배운 것들은 코멘트도 달아보자.
STEP4. 경쟁사와 동일한 전략에 대한 이슈해결 방식을 비교하라
언뜻 보기에 비슷해 보이는 사업들이 사실 조사를 하다보면 기반이 굉장히 다른 경우가 있다. 똑같이 고객에게 물건을 파는 쇼핑몰로 보이지만 중개형 쇼핑몰과 스스로 판매자인 제조사몰의 운영방식이나 수익구조는 다르다. 수익구조와 전략이 다르면 당연히 동일한 UI도 다르게 처리하게 된다.
중개형 쇼핑몰인 G마켓과 물건을 가져와서 판매하는 방식의 SSG닷컴의 주문서를 비교해보자. G마켓은 상품상세에서 쿠폰을 적용하고 주문서에서 변경이 불가능하고, SSG닷컴은 주문서에서 선택된 쿠폰외에 다른 쿠폰이 있다면 얼마든지 변경할 수 있다. 이 차이는 쿠폰의 사용 후 비용 처리를 누가 담당하느냐에서 비롯된 것이다. 당연히 스텝이 분리가 되면 데이터도 분리가 가능하다.
더 쉽게 말하면 오픈 마켓은 상품쿠폰의 금액이 주문서에서 여러가지 상품을 구매할 때 금액이 섞이지 않아야 나중에 입점사에 청구할 수 있따는 말이 된다. 즉, 고객에게 쿠폰을 준다는 것을 동일하지만 비즈니스의 구조와 전략에 따라 UI형태는 달라질 수 있다는 것이다. 역시나 정답이 아니어도 좋다. 이해한 지식을 자신의 어휘로 다시 정리해두면 된다.
마무리
위의 예만 봐서는 어려울 수 있다. 하지만 수준이 높지 않아도 좋다. 수준도 계속 해보면서 성장하는 것이다. 맞냐 틀리냐 따질 필요도 전혀 없다. 이런 비슷한 방식으로 공부해나간다면 단순히 UI를 답습하는 것이 아니라 자신만의 디지털 프로덕트의 구성과 비즈니스에 대한 이해의 틀을 만들어 나갈 수 있을 것이다.
일하면서 계속 접하는 벤치마킹과 서비스조사는 계속 이러한 분석이 동반된다. 알고보면 기획자들이 가장 많이 머리 굴리는 일들이 바로 이런 일이고 연차가 쌓이면 이 부분에 더 많은 자료가 수집되어 있다.
제일 중요한 것은 지금 당장이라도 조금씩 해보는 것인 것 같다. 문서를 만들지 않더라도 생각의 방식을 한번 순서대로 분석해보는 연습이 필요하다.
원문: 도그냥의브런치
도그냥식 서비스 기획자의 역기획 프로젝트 스터디 모임 (a.k.a 기획달리기)
‘서비스를 기획할 때’ 이런 고민은 없던가요?
🙄사수에게 배운 적 없어서 확인받고 싶어요.
마케팅, 개발, 디자인 등은 많은 강의와 책에서 ‘이렇게 해라’ 하는 가이드가 많잖아요? 하지만 서비스 기획은 그런 이정표를 제시하는 곳이 없어요. 배운 거라곤 와이어 프레임 잡는 방법밖에 알지 못하는데, 어디서 어떻게 배워야 할지 막막해요!
😦힙한 ‘UI’를 열심히 만들다가 ‘현타’가 왔어요.
요즘 ‘다크모드’ 힙한 것 같아서 가져오고, 예쁜 배색을 열심히 찾아서 끼워맞춰보면서 보기에도 좋은 웹 서비스를 만들고 있어요! 그런데 막상 고객들에게 반응이 오지 않아요. 이렇게나 이쁜데 왜 그렇죠?
🤔혼자 연습해보고 싶은데, 어디서부터 시작해야할 지 모르겠어요.
혼자서 공부하려니 확인 가능한 데이터 지표도 없고, 시스템도, 고객도 없어요. 동료들과 협업하는 직무이다 보니 얻을 수 있는 정보가 너무 적어요. 도대체 어디서부터 시작해야할지 막막하네요 TT
이제는 10년 동안 서비스 기획부터 PO까지 경험해본 이미준 님이 사수가 되어줄게요. 5주 동안 같이 ‘역기획 스터디’로 달려볼까요?
한 번에 끝내는 서비스 기획의 모든 것 초격차 패키지 Online.
학습규정 * 본 상품은 동영상 형태의 강의를 수강하는 상품입니다.
* 상황에 따라 사전 공지 없이 할인이 조기 마감되거나 연장될 수 있습니다.
* 해당 강의는 사전 예약 상품으로, 강의 영상이 공개 일정에 따라 순차적으로 제작되어 오픈됩니다.
총 학습기간:
– 정상 수강기간(유료 수강기간) 최초 2개월( 60일 ), 무료 수강 기간은 61 일차 이후로 무제한이며, 유료 수강기간과 무료 수강기간 모두 동일하게 시청 가능합니다.
– 본 패키지는 약 59 시간 분량으로, 일 1시간 내외의 학습 시간을 통해 정상 수강 기간(=유료 수강 기간) 내에 모두 수강이 가능합니다.
– 수강시작일: 수강 시작일은 결제일로부터 기간이 산정되며, 결제를 완료하시면 마이페이지를 통해 바로 수강이 가능합니다. (사전 예약 강의는 1차 강의 오픈일)
– 패스트캠퍼스의 사정으로 수강시작이 늦어진 경우에는 해당 일정 만큼 수강 시작일이 연기됩니다.
– 일부 강의는 아직 모든 영상이 공개되지 않았습니다. 각 상세페이지 하단에 공개 일정이 안내되어 있습니다.
주의사항 – 상황에 따라 사전 공지 없이 할인이 조기 마감되거나 연장될 수 있습니다.
– 천재지변, 폐업 등 서비스 중단이 불가피한 상황에는 서비스가 종료될 수 있습니다.
– 본 상품은 기수강생 할인, VIP CLUB 제도 (구 프리미엄 멤버십), 기타 할인 이벤트 적용이 불가할 수 있습니다.
– 커리큘럼은 제작 과정에서 일부 추가, 삭제 및 변경될 수 있습니다.
– 쿠폰 적용이나 프로모션 등으로 인해 5만원 이하의 금액으로 강의를 결제할 경우, 할부가 적용되지 않습니다.
환불규정 – 환불금액은 정가가 아닌 실제 결제금액을 기준으로 계산됩니다.
– 쿠폰을 사용하여 강의를 결제하신 후 취소/환불 시 쿠폰은 복구되지 않습니다.
– 수강시작 후 7일 이내, 5강 미만 수강 시에는 100% 환불 가능합니다.
– 수강시작 후 7일 초과, 5강 이상 수강 시 정상 수강기간(유료 수강기간) 대비 잔여일에 대해 다음과 같이 환불 가능합니다.
환불요청일 시 기준
: 수강시작 후 1/3 경과 전, 실 결제금액의 2/3에 해당하는 금액 환불
: 수강시작 후 1/2 경과 전, 실 결제금액의 1/2에 해당하는 금액 환불
: 수강시작 후 1/2 경과 후, 환불 금액 없음
* 보다 자세한 환불 규정은 홈페이지 취소/환불 정책에서 확인 가능합니다.
키워드에 대한 정보 서비스 기획 프로세스
다음은 Bing에서 서비스 기획 프로세스 주제에 대한 검색 결과입니다. 필요한 경우 더 읽을 수 있습니다.
이 기사는 인터넷의 다양한 출처에서 편집되었습니다. 이 기사가 유용했기를 바랍니다. 이 기사가 유용하다고 생각되면 공유하십시오. 매우 감사합니다!
사람들이 주제에 대해 자주 검색하는 키워드 서비스기획 프로세스 알아보기 l UX
- 서비스기획
- ux
- 서비스기획프로세스
- 기획과정
- ux과정
서비스기획 #프로세스 #알아보기 #l #UX
YouTube에서 서비스 기획 프로세스 주제의 다른 동영상 보기
주제에 대한 기사를 시청해 주셔서 감사합니다 서비스기획 프로세스 알아보기 l UX | 서비스 기획 프로세스, 이 기사가 유용하다고 생각되면 공유하십시오, 매우 감사합니다.
