와이어프레임 중요하지 않아요 (PRD의 중요성)
기획자의 덕목
서비스기획자가 무엇을 해야 하는지를 검색하면 나오는 것들은 정해져 있고
기본적으로 나와야 하는 산출물도 정해져 있다.
이것저것 다양한 산출물을 만들어 내야 하는데 그중에서
서비스 기획자가 가장 신경 써야 하는 것은 무엇일까?
화면설계서?
요구사항명세서?
와이어프레임?
UI/UX?
주니어들에게 Task를 배분해 보면
큰 그림을 그리지 않고 와이어프레임 제작에만 매몰되는 경우를 많이 볼 수 있다.
서비스기획 업무 관련 사항들을 구글링 하다 보면 와이어프레임 / Description 용어 / UIUX 등 산출물 관련된 것들만 잔뜩 나오니 당연한 결과라고도 볼 수 있다.
하지만 결과적인 산출물에만 매몰되어 업무를 진행하다 보면 성과가 좋지 않을 수밖에 없다고 생각한다.
와이어프레임이 아예 중요하지 않다는 게 아니다.
설계서는 당연히 중요하다!
결과적인 산출물이 부실하면 이해관계자들이 업무를 진행하는 데 어려움을 겪게 되기 때문에
문서의 퀄리티는 당연히 좋아야 한다.
그렇지만 결과적인 산출물보다 원인을 파악하고 문제를 정의하는 사전 산출물도 중요하다는 말을 하고 싶은 것이다.
화면을 설계하기 전에 명확하게 현재의 상황과 문제를 정의하지 않는다면
기획의 결과물은 산으로 가게 될 수 있다.
사실 가게 될 수 있다라기보다는 가게 되어있다고 생각한다.
명확히 새로 작업해야 하는 Task가 있는 것이 아니라면 (신사업이라던지 구버전 업데이트라던지)
서비스기획자는 (회사의 포지션 Roll마다 다르겠지만) 문제를 정의하는 일부터 시작해야 한다.
서비스의 규모마다 달라지겠지만 기본적으로 서비스의 화면은 몇십 혹은 몇백 페이지이다.
그 많은 화면 중에 어떤 화면을 우선순위로 고쳐 나갈 것인지를 정해야 한다.
1. 페이지를 고도화하는 방향
2. 페이지를 신설하는 방향
3. 페이지를 삭제하는 방향
다양한 방향으로 서비스를 고도화할 수 있고 그렇기 때문에 더더욱 Why가 굉장히 중요하다.
PRD
위의 이미지는 내가 실무에서 사용하고 있는 PRD (Product Requirement Document) 이다.
위에서 언급했듯이 PRD를 작성하는 포지션의 회사마다 다르다.
문제를 정의하는 것을 프로젝트를 매니징 하는 PM이 할 수도 있고 기획자가 할 수도 있다.
나는 기본적으로 프로젝트를 시작하기 전에 PRD를 작성하고
작성한 PRD를 기반으로 간단한 와이어프레임을 그린 후
해당 프로젝트 담당 PM, 디자이너, 개발자 입회 하에 킥오프 미팅을 진행한다.
그 후 킥오프 미팅을 통한 피드백을 참고하여 화면을 설계해 나간다.
위의 PRD를 보면 화면 설계와 관련된 내용은 전혀 없다.
1. 어쩌다 이 프로젝트가 시작됐는지
2. 어떤 문제점을 발견했기 때문인지
3. 어떻게 해결할 생각인지
4. 이 프로젝트의 성공 여부를 어떤 지표로 확인할 수 있는지
5. 유저가 이 프로젝트를 사용하는 스토리
6. 기존화면과 어떤 점이 달라지는지
7. 이 프로젝트에서 많이 사용되는 단어와 그 정의
8. 이 프로젝트의 핵심 기능과 이를 구현하기 위해 필요한 디자인/개발 요구사항
9. 전체적인 일정
이를 모두 기획한 후에
PRD 기반으로 화면을 설계하는 것이다.
이 과정 없이 냅다 화면만 설계하게 되면 산으로 가게 된다.
예를 들어 "어... FAQ 화면 좀 구리지 않아? 지금 여유 좀 있으니까 이거 좀 고쳐보자" 하고 기획을 시작한다고 가정해 보자.
뭐 기획/디자인/개발이 불가능한 것은 아니지만...
구리다의 기준이 애매모호하고 구리지 않다의 기준도 애매모호하다.
구리지 않게 기획한다고 했는데 이게 잘한 건지 못한 건지 결과를 평가할 방법이 없다.
애초에 문제가 명확하지 않았기 때문에 해결도 명확하지 않고 성과도 명확하지 않다.
이렇게 화면을 좀 고도화했다고 말은 할 수 있겠지만
나중에 연봉협상 할 때 돼서 인사팀이 성과를 물었을 때
"제가 화면을 좀 안 구리게 만들었어요" 라고 말하는 상황을 마주하게 될 수도 있다.
PRD가 없어서는 안 되는 가장 큰 두 가지 이유만 이야기해 보겠다.
첫 번째
PRD를 통해 문제를 명확히 하고 개선할 방향성을 지정하고 기획한다면
기획 도중 "어... 근데 이 기능도 넣으면 좋을 듯?" 하고 길을 잃을 일이 없다.
사실 기획하다 보면 애초의 목표와 맞지 않지만 이것저것 추가하고 싶은 게 많아지고
그러다 보면 프로젝트의 규모와 공수가 걷잡을 수 없이 커지게 된다.
예를 들면 프로젝트 목표가 "입금 절차의 depth를 줄여서 입금 횟수를 증가시키자" 인데
"어... 근데 하는 김에 입금 말고 신용카드 결제도 도입하는 건 어떨까...?" 하고 갑자기 결제 API를 추가하게 되면서 프로젝트의 규모가 커지게 되는 것이다.
극단적으로 표현했지만 실제로 비슷한 경우가 굉장히 많다...
PRD는 이를 방지할 수 있는 아주 스마트한 안내자 역할을 해준다.
두 번째
목표와 성공 지표를 정했기 때문에
정량화된 프로젝트 성과를 측정할 수 있다.
예를 들면 "출금 페이지에서 출금 버튼의 크기를 키우고 눈에 띄는 위치로 옮김으로써 출금 횟수를 증가시키는 것을 목표로 하겠다." 라고 가정한다면
배포 전후의 출금 횟수를 비교하여 성과를 측정할 수 있다.
배포 전 출금 횟수 : 일 평균 100회
배포 후 출금 횟수 : 일 평균 200회
위의 데이터라면 해당 프로젝트의 성과는
일 평균 출금 횟수 2배 증가가 된다.
길게 주절주절 늘어놓았지만
뭐 결과적으로 내가 하고 싶은 이야기는
결과적 산출물에만 매몰되지 말고 큰 그림을 볼 수 있는
기획자가 되는 게 좋다.
