서비스 기획자가 되기 위한 정책 작성법?
기획자에게 왜 사고력을 요구하는가?
저번 글에는 서비스 기획자에게 필요한 개발 지식을 소개했다. 개발 지식에 대해 좀 더 이야기하고 싶다는 생각도 있지만 서비스 기획자에게 근본 그 자체인 정책에 대해 써보고자 한다.
정책이란 무엇일까? 정책은 정치적 목적을 실현하기 위한 방책이라고 사전에 나와있지만 기획에서는 서비스에 대한 설명이다. 예를 들어, 어떤 버튼을 눌렀을 때 어디로 이동하는지 작성된 글은 정책이라고 할 수 있다. 이런 정책들이 모여 기획서가 되고 기획 내용이 구현되어 서비스로 출시된다.
듣기에는 누구나 이런 정책 작성을 할 수 있을 것으로 보인다. 하지만, 짧은 글이라도 읽기 쉬운 글이 있는 반면 짧아도 정말 읽기 힘든 글이 있다. 읽기 쉽게 쓰여 있지 않다면 기획서를 읽는 개발자, 디자이너, QA는 고통받을 것이고 이 고통은 고스란히 서비스에 나타나게 된다. 이렇듯 정책 작성에는 전략이 필요하고 그 전략은 '조건에 따라 상위를 나눠 작성'이다.
조건이라는 것은 무엇일까? 어떤 UI의 상태가 될 수 있고 유저의 행동이 될 수 있다. 이러한 조건에 따라 상위를 나눠 작성해야 개발 시에도 기획서를 이해하는 시간을 줄일 수 있고 QA 역시 테스트 케이스를 적고 테스트 진행을 하는데 어려움을 덜 수 있다. 예를 들어, 정리가 되지 않았다면 어떻게 될까?
- 아이디 input 필수값
- 아이디 input focus 시, 윤곽선 색깔 변경
- 아이디 input focus 시, 유효성 검사 문구 input 하단에 노출하며 문구 색깔은 기본 색깔이 아닌 안내 색깔로 노출
- 아이디 값 유효성 검사 만족 시, 유효성 검사 문구 비노출
- 아이디 값 유효성 검사 불만족 시, 해당 유효성 검사 문구 빨간색으로 문구 노출
머릿속에서 금방 떠오로는 내용이 회원가입이라 해당 내용을 예시로 작성하였다. 이 예시는 짧고 해당 내용만 브런치 텍스트 에디터 안에 크게 글로 표현되어 있어 읽기 쉬울지도 모르겠지만 기획서에서 더 많은 내용이 작성된다면 읽기 어려워진다. 그리고 비밀번호, 비밀번호 확인, 주소, 휴대폰까지 쭉 줄 글로 서술된다면 과연 어떨까? 더군다나 개발자들은 문서를 읽기 싫어한다는 가장 큰 현실적인 문제를 생각한다면 아주 큰 문제이다. 그럼 이 글을 어떻게 정리해야 할까?
1. 아이디 (필수값)
아이디 input focus 시
- 윤곽선 색깔 변경
- 유효성 검사 문구 하단에 노출하며 안내용 문구 색깔로 변경
유효성 검사 만족 시
- 만족된 유효성 검사 문구 비노출
유효성 검사 불만족 시
- 해당 유효성 검사 문구 빨간색으로 문구 노출
위와 같이 정리해 볼 수 있다. 이렇게 조건 별로 상위를 나눠서 작성하는 데는 이유가 있다. 물론 보기 쉽게 만들기 위해도 큰 이유이지만 다른 큰 이유는 개발이 이렇게 이루어지기 때문이다. 코드는 실상 실행 조건과 실행의 연속이다. 수많은 if문 들이 이루어져서 이 조건에서는 이렇게 저 조건에서는 저렇게 작동하도록 한다. 실상 기획서는 나보다 디자이너, 개발자, QA가 주요 독자이기에 이들을 고려한 작성이 필요하다. 시중에 나온 책들은 정책을 이야기할 때, 독자를 고려한 기획서 작성을 모두 언급하지만 실질적으로 how가 빠진 글이 많아 정책 작성에 어려움을 겪는 사람들에게 이 글이 도움이 되었으면 좋겠다.
