[2편] 서비스 기획의 A-Z란 뭘까?
[처음 만나는 서비스 기획] 2편
신입 기획자 교육용으로 만들었던 자료입니다.
기획이 처음인 분들에게 도움이 되길 바랍니다.
총 3편으로 구성되어 있습니다. (중)
1편 : https://brunch.co.kr/@supernova9/204
4. 솔루션 디자인
주요 사항
1. 이해관계자를 설득하세요.
2. 단계별로 나눠보세요.
1. 이해 관계자를 설득하세요.
앞 단계에서 만든 프로토타입은
말 그대로 프로토(선행)타입(제품)입니다.
실제 제품(프로덕트)을 만드는 것은 좀 더 복잡합니다.
모형 전투기를 만들기는 쉽지만
실제 전투기를 만드는 것은 다른 것처럼요
전투기가 엔진, 동체, 레이더, 무기 등
다양한 분야의 전문가들이 힘을 합쳐야 만들어지듯이
앱도 이해관계자들의 도움을 얻어야 만들 수 있습니다.
(실제로 UX 디자이너들의
포트폴리오 사이트만 들어가 봐도
2030년쯤에나 나올 것 같은
예쁜 앱 화면들은 쉽게 찾을 수 있습니다.)
레드커넥트도 '혈액 검사로 건강 리포트를 제공하자!'
라는 프로토타입을 실제 서비스로 만들기 위해
이해 관계자들을 설득해야 했습니다.
의사 선생님, 검사센터, 복지부, 심평원, 건보공단 등
수많은 사람들의 도움이 필요했는데요.
힘을 합쳐서 - 출처 : 어벤저스-Tannerfrizzell우선 1. 혈액관리본부를 찾아가
혈액 검사 결과를 다르게 보여주자고 제안합니다.
관련된 임직원 분들을 만나 예상되는 문제를 듣고
보안, 법률 등을 세심하게 확인합니다.
2. 두번째로 혈액검사 결과를 분석하는 데 필요한
국민 건강검진 데이터를 받아옵니다.
때문에 심평원, 건강보험공단을 찾아가
프로젝트의 취지를 설명하고 안전성을 확인한 뒤
익명화된 데이터를 확보하는 과정도 필요했습니다.
데이터 협업 구조 - 출처 : 레드커넥트이런 설득의 과정은 아주 어렵고,
하루하루 일을 그만두고 싶을 만큼 힘이 듭니다.
전화할 때마다 잡상인 취급을 받는 것은 기본에
실제로 만나러 가서도 냉대받는 경우가 허다하니까요.
한 번은 '정부 기관에서는 팀장이 나왔는데
그쪽은 이렇게 어린애가 혼자 오시면 어떡하냐'고
타박을 받고 쫓겨나듯이 나온 적도 있었습니다.
그렇지만 오래도록 설득하다보면
서로의 요구사항을 맞출 수 있고,
취지에 공감하며 선뜻 도움을 주는 분들도 생깁니다.
타협, 협상, 양보를 통해 이해관계자들이
가진 것과 가져야할 것을 조정합니다.
기획자는 서비스에 들어가는 모든 기능마다
끈질기게 달라붙어 비슷한 과정을 진행합니다.
2. 단계 별로 나누어 보세요.
솔루션을 만들다 보면 현실적인 이유로
'이건 꼭 해야 하는 일이지만 지금은 절대 못하겠다.'
싶은 경우가 있습니다.
예산, 법규, 데이터, 이해관계자 문제로
처음부터 완벽하게 만들 수 없는 케이스죠.
이럴 때 '나의 근성과 끈기를 보여주겠다'며
루피나 나루토가 수련하듯이
죽자 사자 버티는 것이 절대 능사가 아닙니다.
고집만 부리면 실제로는 세상에 나와야 할
서비스가 빛도 못 보고 사라집니다.
기획자는 적절한 선을 찾아
지금 출시 가능한 제품을 만들고
2단계, 3단계에서 못다 한 서비스를
업데이트해야 합니다.
예를 들어 이건 최근 무섭게 성장하고 있는
'쿠팡이츠'의 사례를 생각해볼까요?
쿠팡이츠도 처음 출시할 때부터 배민이나 요기요처럼
전국 단위 서비스를 하고 싶었을 겁니다.
하지만 서울 도심 → 서울 전체 → 수도권 인근으로
서비스를 점점 확대하는 방식을 취했습니다.
쿠팡이츠는 품질이 낮은 전국단위 서비스보다
다른 기능의 품질을 우선시했고,
서비스 지역이라는 요소는
단계를 나누어 차근차근 접근했던 것이죠.
쿠팡이츠 서비스 지역 확장 - 출처 : 쿠팡이츠레드커넥트도 개발 초창기에는
내가 헌혈한 피가 환자의 몸에 들어가는 순간
앱 푸시를 통해 알림을 주는 것을 계획했었습니다.
이타적인 마음으로 헌혈하는 사람들에게
빌딩에서 떨어지는 시민을 낚아채는
스파이더맨의 기분을
느끼게 해주고 싶었거든요.
하지만 이런 서비스를
단박에 구현하는 것은 굉장히 어려운 일입니다.
우리나라에서 헌혈된 피는 환자에게 전달되기까지
1. 헌혈의 집
2. 지역 혈액원
3. (혈액원과 동시에) 검사센터
4. 상급 의료기관 (혈액은행) or 혈장제제 제조사
5. 환자 or 약물
의 순서를 거치는데요.
각 단계마다 연결해야 할 시스템이 매우 복잡하고,
법적, 정치적 이슈가 와글와글했습니다.
때문에 출시 당시에는 '헌혈검사센터 검사 완료'까지만
체크하고 2번째 단계부터 의료기관 출고, 사용 알림을
도입하는 것으로 계획을 세웠습니다.
기획자 입장에서는 아쉬운 일이었지만
정말 안 되는 영역에서는 어느 정도 타협을 해야
서비스를 만들 수 있습니다.
레드커넥트 개발 1단계와 2단계 - 출처 : 저자5. 프로덕트 빌딩
주요 사항
1. 프로젝트 범위를 정의하세요.
2. IA / UID를 꼼꼼히 작성하세요.
3. 모르면 물어보세요.
1. 프로젝트 범위를 정의하세요.
솔루션을 확정했다면 이제 개발입니다.
프로젝트의 계획(범위와 기간)을 세워야 하죠.
우리가 어렸을 때 구몬이나 빨간펜을 풀 때도
'하루에 5장씩은 풀어야 일주일 뒤에 선생님이 와도
드러눕지 않을 수 있겠다' 계획을 세우는 것처럼
앱 개발 프로젝트도 똑같습니다.
지금은 도저히 엄두가 나지 않을 것 같은 개발도
1. 전체적으로 필요한 일들이 무엇인지 문서화하고
2. 단계를 작게 쪼개서 달력에 뿌리면
목표일까지 일단 완성시킬 수 있습니다.
(그 과정에서 많은 희생이 있겠지만..)
1. 전체적으로 필요한 일이 무엇인지 문서화:
기획자는 우선 요구 사항 명세서를 씁니다.
이때 요구사항으로는 장비, 기능, 성능, 인터페이스,
데이터, 테스트, 보안, 품질 등 다양한데요.
외부의 개발업체와 작업하는 경우,
앞서 말한 모든 사항을 기획자가
RFP(Request for Proposal),
제안요청서에 담아 전달합니다.
그러면 업체들이 이 RFP를 보고
제안서를 보내는 구조입니다.
RFP는 딱 이거다!라고 정해진 양식은 없습니다.
한 페이지짜리 공고문(?)부터
100페이지가 넘는 문서까지 다양합니다.
(기업에서 임원이 시켜서 부실하게 기획하면 1페이지,
정부에서 책임을 피하고 싶어 꼼꼼히 쓰면 100페이지
이런 식입니다.)
구글에 '나라장터' 같은 사이트를
검색해서 몇 건만 읽어보아도
'아-대충 이런 식으로 쓰는 거구나'
감을 잡을 수 있습니다.
RFP예시 : 모바일 보건소 사업의 RFP입니다. - 출처 : 한국건강증진개발원내부의 개발자들과 일하더라도 정도의 차이가 있을 뿐
요구사항은 문서로 명확하게 정리되어야 합니다.
(보통 업무협업 툴, Wiki에 정리합니다.)
다만 '장비, 보안, 품질, 유지보수'와 관련된 부분은
보통 개발 PM분이 직접 처리하는 경우가 많기 때문에
기획자는 1. 데이터, 2. 기능, 3. 인터페이스에
집중해서 문서를 작성하면 됩니다.
요구사항 명세 작성이 끝나면
개발자들과 각 기능 및 시스템에 대해
1. 더할 것은 더하고 뺄 것은 뺀 뒤
2. 시스템 구축에 필요한 점까지 확인하여
'우리가 할 일은 무엇이다!'를 확정합니다.
2. 단계를 작게 쪼개 달력에 뿌리기:
수행해야 할 업무가 나오면 이것을 잘게 쪼갭니다.
예를 들어 '헌혈 예약하기'라는 큰 기능은
1. 헌혈의 집 검색하기 (검색 엔진)
2. 헌혈의 집 위치 표시 (Map API 연동)
3. 헌혈의 집 운영시간 연동 (DB 연동)
4. 헌혈 기기 별 예약 현황 반영 (DB 연동)
5. 예약 변경/취소 (세부 기능 조정)
등 작은 기능으로 쪼갤 수 있습니다.
각 업무는 짧게는 1일 길게는 5일 안에
처리할 수 있는 분량입니다.
결과적으로 '와 이걸 언제 다해'가 아니라
'이렇게 작은 일 10개를 다하면
커다란 1개가 완성된다는 거지?' 하는 상태로 만듭니다.
쪼갠 업무는 WBS라 부르는 달력에 뿌립니다.
기획자와 개발 PM은 WBS를 바탕으로
주차 별로 해야 할 일을 정리하고
업무와 일정을 조정하면서
개발 프로젝트를 이끌어갑니다.
WBS 예시 화면 출처 : 야메의 웹 기획 가이드WBS 작성은 숙련된 개발 PM분들이 진행하지만
기획자가 초안을 잡아주는 경우도 많습니다.
상세한 내용은 아래 링크에서 찾아보시면 좋습니다.
WBS 작성법에 대해 자세히 설명한 포스트입니다.
2. IA / UID를 꼼꼼히 작성하세요.
이제 화면을 그릴 시간입니다.
우선 IA를 만듭니다.
IA는 Information Architecture
(정보구조도)의 약자입니다.
앱의 뼈대를 일컫는 말이죠.
사람이 머리뼈, 가슴뼈, 다리뼈 등으로 이루어져 있고,
그 가슴뼈도 1,2,3,... 25번 가슴뼈까지 있는 것처럼
앱도 화면 단위까지 쪼갤 수 있습니다.
정보 구조를 그릴 때는
1. 우선 앱 안에 필요한 화면을 나열 한 뒤
2. 나열한 화면을 생각해놓은 구조에 맞게 배치합니다.
3. 배치는 엑셀이나 마인드맵 형태에 옮겨 담습니다.
초기 단계에서는 기획자들끼리 모여
포스트잇에 화면을 써 붙이고
전체 구조를 확인한 뒤
어느 정도 윤곽이 나오면
개발자들과 합의하여
엑셀 등 도구에 옮겨 담고 구조를 확정합니다.
이렇게 IA를 완성하고 나면
다음은 UID(User Interface Description)입니다.
UID는 와이어프레임, 상세 설계서, 화면 설계서 등
다양한 이름으로 불리지만 결국 다 비슷한 문서입니다.
1. 앱 서비스의 화면을 그리고
2. 그 화면이 어떻게 동작하는지를
구체적으로 정의한 문서는 모두 UID라고 할 수 있죠.
앞서 IA를 꼼꼼하게 작성했다면
UID에서 그려야 할 화면의 개수가 나옵니다.
이제는 각 화면을 본격적으로 그리면서
앱의 설계도를 만듭니다.
UID는 보통
1. 헤드라인을 정하고
2. 화면까지 가는 경로를 써준 뒤,
3. 좌측에 화면을 큼직하게 그리고
4. 우측에 컴포넌트 별로 설명을 달아주면서
5. 필요한 경우라면 화면 예시를 들며
완성합니다.
UID예시 화면(브런치 제안하기) - 출처 : 저자UID는 워낙 내용이 방대하다 보니
좀 더 상세한 내용은 제가 예전에 썼던 글들을
참조해보시면 좋을 것 같습니다.
3. 먼저 물어보세요.
프로덕트를 만들 때
기획자에게 가장 중요한 것은
함께 일하는 사람들에게
먼저 물어보는 것입니다.
기획자는 프로젝트 전체에 대해 다른 직군보다
넓은 시야를 가지고 있지만 (혹은 가져야 하지만)
개발 과정에서 발생하는 기술적인 문제점은
개발자들보다 훨씬 모를 수밖에 없습니다.
때문에 프로덕트를 촘촘히 이해하고
진짜 도움이 되는 기획자가 되기 위해서는
다른 직군들의 지혜를 꼭 빌려야 하죠.
하지만 개발자들은 생각보다 기획자들에게
적극적으로 물어보지 않는 경우가 많습니다.
1. 불만이 있어도 좋은 게 좋다는 식으로 넘어가거나
2. 이 사람이 알고도 이렇게 했겠거니 넘겨짚는 식이죠.
행여나 다른 직군의 업무방식이나 설계에 대해
비판적인 질문을 하다가 사이가 틀어져버리면
앞으로 일하면서 계속 불편하기 때문에
갈등이 생길 상황 자체를 꺼리는 것입니다.
실제로 기획팀과 개발팀이 따로 있으면
서로 못 잡아먹어서 안달인 케이스도 많습니다. (...)
이런 상황을 막기 위해서는
기획자가 끊임없이 먼저 물어봐야 합니다.
기능을 생각하면 간단하게라도 요구사항을 적어
개발자의 의견을 반드시 들어야 합니다.
추가로 나의 업무 방식에 불편한 점은 없는지,
설계서 만드는데 원하는 방식이 있는지,
혹시 최근 업무가 너무 많다면
우선순위 조정이 필요하신지.. 등
개발자는 카레이서고 나는 정비사라는 마음가짐으로
계속 도움을 주기 위해 최선을 다합니다.
준비 끝 개발 시작! - 출처 : roadendtrack.com개발자의 입장에서도
기획자들이 나에게 윽박지르는 사람이 아니라
개발을 돕고 정리해주는 사람이라는 생각이 들 때
팀원을 믿고 할 수 있는 최고를 할 수 있습니다.
(다 안된다고 하더니 나중에 다 해놓는 경우도 많죠.)
이것도 예시를 한번 들어볼까요?
예전에 '사용자 평가 기능'을
기획한 적이 있었습니다.
처음에는 아래와 같이 UID를 만들었습니다.
초간단 UID - 출처 : 저자기획팀 입장에서는 아주 간단한 기능으로 보입니다.
때문에 '이 화면 아래 별점 넣을 거예요'
'UID는 이렇고요, 디자인은 다음 주까지 드릴게요'
하면서 스펙 리스트에 끼워 넣습니다.
그렇지만 이걸 받아 든 개발팀 입장은 곤란합니다.
우선 별표가 어떻게 동작하는지 모릅니다.
(1) 클릭했을 때, (2) 드래그했을 때,
(3) 클릭 후 드래그했을 때,
다양한 경우의 수를 전혀 고민하지 않은 UID이니까요.
고민이 부족하면 그 고민은 개발자가 해야 합니다.
1. 착한 개발자가 엄청 고생하거나
2. 보통의 개발자가 아무렇게나 개발하게 되죠.
따라서 일단 모르면 초안만 그립니다.
그리고 개발팀에게 검토를 요청한 뒤
추가적으로 필요한 내용을 듣고
UID를 꼼꼼하게 다시 그립니다.
그러면 아래 그림처럼 상세한 UID가 다시 나옵니다.
꼼꼼하게 새로 설계한 UID - 출처 : 저자간단한 기능 하나지만
기획자가 평상시에 개발자에게 자주 묻고
의견을 존중하면서 설계부터 함께한다고 생각하면
훨씬 쉽고, 즐겁게 작업할 수 있습니다.
6. 브랜딩
주요 사항
1. 핵심가치를 정하고 디자이너를 존중하세요.
2. 구성원의 힘으로 악당을 물리치세요.
1. 핵심가치를 정하고 디자이너를 존중하세요.
서비스 프로젝트는 처음부터
명확한 이름을 가지는 경우보다
프로젝트명 정도로 출발하는 경우가 많습니다.
구체적인 브랜드는 사업의 윤곽이 잡힌 뒤
전체적인 철학과 방향성을 녹여서 만들어집니다.
전문적인 브랜드 팀이 따로 있어서
작업을 해주면 좋겠지만
1. 회사에 그런 팀이 없는 경우도 많고,
2. 브랜드팀이 꼭 좋은 결과를 주는 것도 아닙니다.
제 경우에는 기본적인 정책과 설계서가 나온 후
개발 시작 시점부터 브랜딩을 함께 진행했습니다.
처음 브랜드를 정할 때는
프로젝트에 참여했던 기획, 개발, 디자이너 모두에게
의견을 들어보는 것이 좋습니다.
우리 프로젝트에 대해
1. 어떤 사람이 쓸 것이라고 생각하는지,
2. 가장 중요하다고 생각하는 기능이 무엇인지,
3. 우리 프로젝트와 비슷한 서비스는 무엇인지
를 물어보면 각자의 머릿속에 있는
추상적인 생각을 정리할 수 있습니다.
(기획 의도가 잘 전달되었다면
대부분 비슷한 대답을 할 겁니다.)
구성원들의 목소리를 들은 뒤에는
3단계를 거칩니다.
1. 브랜드 목표 설정
첫째, 브랜드 목표 (Brand Goal)를 뽑습니다.
여기서는 우리 서비스가 세상에 나옴으로써
이루고 싶은 목표를 정리합니다.
레드커넥트의 경우
1. 투명한 헌혈
2. 건강한 헌혈
3. 즐거운 헌혈
3가지 가치를 브랜드 목표로 잡았습니다.
브랜드 목표 설정 - 출처 : 레드커넥트기획자의 일은 목표를 정확하게 말해주는 것입니다.
정제된 문서로
'우리의 서비스가
1. 담고 싶은 가치는 A,B,C입니다.
2. 해결하려는 문제는 '이것'입니다.
3. 핵심 기능은 '이것'입니다.
4. 주 사용 고객은 '누구'입니다.'
와 같이 스토리를 작성해주어야 하고,
필요하다면, 고객 설문, 프로토타입 테스트,
관계자 인터뷰 등 줄 수 있는 자료는 다 주어야 합니다.
2. 목표 시각화
둘째로 정한 목표를 시각화합니다.
1단계에서 브랜드의 목표(가치)를 잡았다면
이 가치가 시각적으로 보이도록 작업합니다.
시각화 작업부터는 디자이너의 역량과 책임을
최대한 존중해주어야 합니다.
가끔 '엔틱하면서 모던하게 해 달라'
'블랙앤 화이트 톤에 화려하게 해 달라'
'우리 임원이 좋아하게 해 달라(?)'
처럼 말도 안 되는 요구를 하는 분들도 있습니다.
디자인에 대해 미학적인 가이드를 주는 것보다
앞 단계의 가치 설정을 명확히 하는 것이
기획자의 롤입니다.
필요한 것이 있다면 디자이너가 먼저 요청하기 때문에
원하는 방향이 있다면 레퍼런스 정도만
찾아주면 좋습니다.
핵심가치의 시각화 - 출처 : 레드커넥트위 예시처럼 레드커넥트는
'투명', '건강', '즐거움'이라는 가치를
R의 각 획수에 담아 표현했습니다.
(제 개인적으로는 매우 마음에 드는 디자인이었습니다.)
3. 브랜드 적용
셋째로 정해진 브랜드를 적용합니다.
GUI에 적용될 디자인 시스템을 만드는 일이죠.
이때 기획자와 디자이너는
폰트, 컬러, 심벌, 컴포넌트 전 영역에 걸쳐서
하나의 브랜드 가이드가 앱의 모든 지점에
녹아들 수 있도록 합니다.
이 과정을 거쳐야 1. 기획자가 생각한 핵심 가치가
2. 디자이너의 손을 거쳐 3. 개발자가 만드는 영역까지
순조롭게 녹아들 수 있습니다.
브랜드 적용 - 출처 : 레드커넥트가끔 졸속으로 만든 공공기관 앱을 보면
여러 개의 앱을 짬뽕해놓은 것 같은 화면을 볼 수 있는데요.
하나의 디자인 시스템이 없이,
윗사람이 지시하는 바를 그때그때 반영하다 보니
생기는 불상사라고 하겠습니다.
2. 동료들의 힘으로 악당을 물리치세요.
실무자가 서비스 기획을 할 때
가장 피곤한 순간이 있다면
'기획 과정에 거의 참여하지 않았던 높-으신 분께서
갑자기 숟가락을 들고 달려드는 경우'입니다.
그리고 브랜딩 작업이야말로
군침 싹 도는 12첩 반상이죠.
다 된 서비스에 이름 하나만 지으면
마치 모든 것을 혼자 만든 것처럼 느껴지거든요.
따라서 회사 혹은 파트너사에 간섭할 사람이 있다면
이 무렵에 태클이 매-우 심합니다.
이런 분이 꼭 있습니다. - 출처 : 미생레드커넥트도 공공기관과 함께 만드는
서비스였다 보니 출시하기 직전 간섭이 굉장히 심했습니다.
어느 날 정부의 높으신 분 한분이 등장하더니
앱 이름을 '모바일 헌혈'로 하자고 박박 우기셨죠.
그동안 함께 브랜딩을 토론했던 실무자들은 물론,
테스트에 참가한 헌혈자, 실무 디자이너들은 모두
레드커넥트의 의미가 좋고 향후 발전할 여지가 있다며
찬성표를 던졌지만.. 권력이 달콤한 이유는
졸개들의 의견을 무시할 수 있기 때문입니다. (...)
브랜드란 단순히 이름 하나 짓는 것이 아니며
이미 핵심가치, 디자인 에셋,
레이아웃이 맞추어져 있다고 해도,
설득이 먹히지 않았죠.
결국 이분 생각을 꺾기 위해
의견 수렴 과정을 다시 하고
'말 안 듣는 또라이가 버틴다'는
오명(?)을 쓰고 브랜드를 유지했습니다.
이렇게 되지 않으려면
기획자가 브랜딩을 조율할 때,
악당들이 침략할 상황을 대비하여
매사 근거를 꼼꼼하게 만들어 놓아야 합니다.
3편 : https://brunch.co.kr/@supernova9/206
