프로덕트 매니저와 화면설계(와이어프레임)
적당히 하자.
프로덕트매니저와 서비스기획자를 혼용해서 사용하던 어느 스타트업에서 어느날 S/W 엔지니어 출신의 창업자 양반이 나에게 물었다.
'기획자가 화면기획을 어떻게 해서 디자이너에게 전달하는게 좋을까요?'
사실 이 문제에 대해서 정답이 있는건 아니긴 하다.
회사의 특성, 문화, 조직 구성원의 역량과 직무 희망에 따라 달라지기는 한다.
20여년 전에는 서비스기획자라는 직군의 사람들이 스토리보드라는 이름으로 PPT 에 화면을 그리고 화면에 대한 온갖 디스크립션을 붙여서 기획서를 만들어내고는 했다.
많은 분들이 경험하고 아시다시피 요새는 조직에 따라 조금씩 달라진다.
1. PRD, 유저스토리 등만 텍스트 위주로 작성하고 화면설계는 UX/UI 디자이너가 전적으로 담당.
2. Low Fidelity 까지만 작성하고 더 상세한건 UX/UI 디자이너가 담당
3. High Fidelity 까지 작성하고 디자이너는 UI 디자인만 담당
4. 프로덕트매니저(또는 기획자)가 없음...
(참고로 과거에 주로 작성하던 스토리보드는 2와 3의 그 중간 어디쯤이 아니었나 개인적으로 생각한다.)
사실 이 부분은 프로덕트매니저와 UX/UI 디자이너의 역량에 따라 차이가 있을 수 있다.
몇년 전에 있던 한 스타트업에서는 초반에 팀에 디자이너가 없어서 디자인 작업을 전적으로 외주로 맡겼고, 그러다보니 커뮤니케이션 및 업무 효율화를 위해서 프로덕트매니저인 내가 직접 High Fidelity 수준으로 화면설계 작업을 했다. (그러다보니 화면설계에 시간을 엄청나게 사용했다.)
이후 역량있고 경험치 있는 디자이너가 들어오면서 나는 PRD, 유저스토리 및 Customer journey map 정도만 관여하고 실제 화면설계는 전적으로 디자이너에게 맡겼다.
이후, 다른 스타트업에 조인했을 때 그곳에는 이제 총 경력이 3년이 안되는 쥬니어 디자이너 1명만 있었던 상황인지라 여기서도 High Fidelity 수준까지 화면설계 작업을 하게 됐다.
만약 그곳에서 디자이너가 쥬니어가 아니라 더 경험 있고 역량이 쌓인 분이었다면 디자이너에게 화면설계의 많은 부문을 맡겼을 것이다.
다만 이 부분은 디자이너와 충분히 소통이 필요하다.
8년전에 해외 송금 관련 웹서비스를 개발하는 프로젝트를 할 때 기획자(나였다.)가 별도로 화면설계를 하지 않고 디자이너가 직접 UX/UI 디자인을 한 적이 있다.
화면기획안을 받아서 디자인하던 업무 프로세스로 일하던 사람이라 처음에는 조금 낯설어하기도 했지만 이후에 나온 퀄리티를 보고는 디자이너가 바로 화면을 그리는게 나은 점이 많다는 생각을 하게 됐다.
그런데 디자이너는 디스크립션을 다는데 익숙하지 않아서 각 화면에 대한 설명이 마많지는 않은 상태였고, 그 당시 개발자는 스토리보드와 디스크립션을 보고 개발하는데 익숙하던 상태였는데 디스크립션이 별로 없이 화면 UI 만 나온걸 보고 개발을 못하겠다고 하는 사태가 발생했다. 그래서 결국 디자이너가 작업한 UI를 모조리 화면을 떠서 PPT로 옮긴 후 일일이 디스크립션을 달아야 했다.
사실 화면설계, 디스크립션 등등은 잘하는 사람이 하면 가장 좋다고 생각한다.
못하는 사람이 힘겹게 또는 잘못해서 전체 속도가 느려지는 것보다는 잘하는 사람이 빠르게 잘하는 효율적이다. 다시 말해 화면설계는 프로덕트매니저가 할 수도 있고 디자이너가 할 수도 있다. 상황에 따라서는 개발자가 할 수도 있다. 기능에 대한 설명도 마찬가지다.
다만, 프로덕트매니저가 '저는 화면설계는 할 줄 몰라요' 라고 말하는건 본인의 영향력을 굉장히 축소시키는 것이라 생각한다. 그리고 잘 할줄도 모르면서 이렇다 저렇다 다른 사람이 한 화면설계를 평가하고 지적하는 것도 조금은 우습지 않나 생각된다.
결론적으로 프로덕트매니저가 직접 화면설계를 다 할 필요는 없지만, 혼자서도 충분히 잘하고 디자이너와 개발자들에게 가이드를 주고 방향성을 제시할 정도로 UX/UI 설계를 경험하고 역량을 쌓아놓는건 필요하다.
