기획자로 몇 년 일하면서 가장 많이 받았던 질문 중 하나가 "그래서 기획자는 정확히 뭘 하는 사람이에요"였습니다.
디자이너는 화면을 만들고, 개발자는 코드를 짜는데, 기획자는 대체 뭘 만드는 사람이냐는 질문이었죠.
이 질문에 제대로 답하기까지 시간이 꽤 걸렸는데, 협업 과정에서 제 역할이 뭐였는지 되짚어보며 정리해봅니다.
"예쁘게 만들어주세요"는 요구사항이 아니다
기획 초반에 저는 디자이너에게 시안을 요청할 때 "사용자 친화적으로 예쁘게 만들어주세요" 정도로 말했던 적이 많았습니다.
그런데 이 말은 사실 아무 정보도 담고 있지 않은 요청이었어요.
디자이너 입장에서는 "예쁘다"의 기준이 사람마다 다르고, "사용자 친화적"이라는 말도 구체적인 제약 없이는 방향을 잡기 어렵습니다.
지금은 시안을 요청할 때 반드시 세 가지를 같이 전달합니다.
이 화면에서 사용자가 해야 할 핵심 행동 하나, 이 화면에 들어가야 하는 정보의 우선순위, 그리고 비슷한 서비스 중 참고할 만한 레퍼런스 한두 개입니다.
이렇게 구체적으로 전달하기 시작하면서 시안 수정 횟수가 평균 4~5번에서 2번 정도로 줄었어요.
예외 상황을 미리 정의해주는 게 기획자의 역할
개발자와 협업하면서 가장 많이 받았던 질문은 "이 경우엔 어떻게 되나요"였습니다.
정상적인 흐름은 PRD에 잘 적어놨는데, 사용자가 중간에 뒤로가기를 누르거나 네트워크가 끊기거나 동시에 같은 액션을 두 번 누르는 경우는 미리 생각하지 못했던 거죠.
개발자가 이런 질문을 할 때마다 그 자리에서 즉흥적으로 답을 정하다 보니, 나중에 QA 단계에서 "이때는 왜 이렇게 동작하나요"라는 질문이 다시 나오는 악순환이 있었습니다.
이후로는 PRD를 쓸 때 "예상 가능한 예외 상황 다섯 가지"를 미리 뽑아서 각각의 처리 방침을 정의해두는 습관을 들였어요.
완벽하게 모든 예외를 예측할 수는 없지만, 최소한 개발자가 임의로 판단해서 구현하는 상황은 크게 줄었습니다.
중간에서 "번역"하는 역할
디자이너와 개발자가 직접 이야기할 때 서로 다른 언어를 쓰는 걸 여러 번 목격했습니다.
디자이너가 "이 인터랙션이 좀 더 자연스러웠으면 좋겠어요"라고 하면, 개발자는 "자연스럽다는 게 구체적으로 어떤 애니메이션 곡선을 말하는 거죠"라고 되묻는 식이었어요.
저는 이럴 때 중간에서 구체적인 기준으로 바꿔주는 역할을 하게 됐습니다.
"버튼을 눌렀을 때 0.2초 안에 반응이 와야 하고, 로딩이 그보다 길어지면 스피너를 보여준다"처럼 숫자와 조건으로 바꿔서 양쪽에 전달하는 식이었죠.
이 역할을 하다 보니 저 스스로도 인터랙션 디자인의 기본적인 용어와 개발 쪽의 성능 제약을 어느 정도는 이해해야 한다는 걸 느꼈습니다.
디자이너와 개발자 사이에 의견이 갈리는 순간들이 종종 있었습니다.
디자이너는 화려한 트랜지션 효과를 원했고, 개발자는 "이거 넣으면 로딩이 눈에 띄게 느려집니다"라고 반대했던 적이 있어요.
이럴 때 저는 누구 편도 들지 않고, "이 트랜지션이 사용자 경험에 실제로 얼마나 영향을 주는가"를 다시 물었습니다.
결국 A/B 테스트를 짧게 돌려서, 트랜지션이 있는 버전과 없는 버전의 이탈률을 비교했어요.
차이가 통계적으로 의미 없는 수준이라는 결과가 나오자, 디자이너도 "그럼 성능을 우선하죠"라고 수긍했습니다.
감정적인 논쟁이 될 뻔했던 문제가 데이터 하나로 깨끗하게 정리된 경험이었어요.
한동안 저는 디자이너의 시안과 개발자의 구현 방식까지 세세하게 관여하려고 했던 시기가 있었습니다.
"이 버튼은 여기 말고 저기로 옮기는 게 좋을 것 같아요", "이 로직은 이렇게 짜는 게 낫지 않을까요" 같은 말을 자주 했었죠.
그런데 이게 오히려 팀의 전문성을 무시하는 행동이라는 걸 디자이너 동료의 피드백을 듣고 깨달았습니다.
"저희도 전문가인데, 결과물의 이유만 물어봐 주시면 저희가 더 좋은 답을 찾을 수 있어요"라는 말이 꽤 뜨끔했어요.
그 이후로는 "왜 이렇게 하면 안 될까요" 대신 "이 부분에서 우리가 놓친 게 있을까요"라고 질문하는 방식으로 바꿨습니다.
기획자의 역할을 한 문장으로 정리하면, "팀이 같은 목표를 보게 만들고, 그 목표를 향해 가는 길에서 각자의 전문성이 최대한 발휘되도록 조건을 정리해주는 사람"이라고 생각합니다.
디자이너와 개발자가 각자의 영역에서 최선의 답을 낼 수 있도록 맥락과 기준을 전달하는 것, 그게 결국 기획자가 협업에서 해야 할 가장 중요한 일이라는 걸 이번에 다시 배웠습니다.
'Planning · PM > 프로젝트 · PM' 카테고리의 다른 글
| 2023년 가트너 전략 기술과 우리 팀 로드맵 (0) | 2023.02.11 |
|---|---|
| 서비스 정책 문서, 왜 자꾸 누락되나 (0) | 2020.07.26 |
| 게이미피케이션의 7가지 요소 (0) | 2020.05.31 |
| 재택 환경에서 기획 회의 진행하는 팁 (0) | 2020.05.24 |
| 서비스 정책 vs 기능 정의, 헷갈리는 경계 (0) | 2020.05.03 |