서비스 기획, 뭘 하는 걸까?
서비스 기획은 쉽게 말하면 우리가 가지고 있는 아이디어를 하나의 서비스, 제품으로 만들어가는 과정을 말한다. 서비스 기획은 무언가를 만들어내기 위해 고민하는 행위를 수반하는데, 무언가를 만들어낸다는 것은 사용자가 겪고 있거나 겪게 될 문제를 찾아내고, 문제를 해결하기 위한 방법을 고민해서 해결 방법을 만들어내는 과정이다. 즉, 다시 말해 서비스 기획은 사용자의 문제를 해결하기 위해 어떤 제품이 필요하고, 그 제품으로 무엇을 할 수 있으며, 제품과 서비스가 왜 필요한지 고민하는 과정을 수반하며 제품과 서비스가 어떻게 사용자에게 보이고 어떻게 사용자가 사용할 수 있을지도 고민하는 것을 말한다.
이 과정을 한 문장으로 압축하자면, 서비스 기획이란 어떤 제품이나 서비스의 생성과 소멸까지의 모든 과정을 고민하는 것이라고 볼 수 있다.
이번 글은 서비스 기획에 대해서 전체적인 과정과 각 과정에 대한 짧은 설명을 쓴 글이다. 글의 순서는 아래와 같다.
|
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님의 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
