기획서 하나 없이 시작된 프로젝트에서 벌어진 일
기준도 정책도 없던 프로젝트. 기획은 거기서 시작됐다
외주 일정이 끝난 새벽
하루치 에너지를 다 쓰고 녹초가 된 상태이지만
자꾸 서비스를 보게 된다.
이 프로젝트는 돈이 되진 않지만
이상하게 마음이 간다.
그리고 재밌다!
처음 다뤄보는 커뮤니티 도메인이라 그런 걸까?
스크린 하나하나를 들여다보고
피그마 디자인과 비교하여 흐름을 따라가다 보면 시간이 훌쩍 지나 있다.
나는 이번 프로젝트에 서비스 기획자로 합류했다.
그 시작은 QA였다.
디자인과 실제 구현 화면이 얼마나 일치하는지를 비교하면서
놓친 기능, 어색한 흐름, 예외 상황에서 오류를 찾아나가는 일.
처음엔 단순히 QA 체크 정도로 시작했지만
갈수록 반복되는 생각이 하나 있었다.
'기획자가 없었구나'
가장 먼저 보인 건 경우의 수에 대한 설계 부족.
댓글이 없는 게시글은 어떻게 보여야 할까?
댓글이 1개일 때와 100개일 때, 정렬 기준은 같아야 할까?
멤버십과 일반 회원은 같은 화면을 봐야 할까?
이런 조건들이 정의되어 있지 않았다.
그때 깨달았다.
기획자는 기준을 만드는 사람이구나
댓글은 몇 줄까지 보여줄지
입력은 몇 자까지 허용할지
사용자 등급 별 어떤 기능에 접근할 수 있을지
이런 걸 미리 정리해 두지 않으면
작업자들은 자기 해석대로 움직이게 되고
결국 서비스는 점점 본래의 의도와 다른 방향으로 흘러가게 된다.
처음에는 ‘이건 너무 사소한 것 아닐까?’ 싶었던 것들도
막상 개발자와 디자이너에게 공유하면
“이런 기준이 꼭 필요했다”는 말이 돌아왔다.
또 하나 중요했던 건 기능 프로세스와 UX 라이팅 기획
사용자가 어떤 흐름으로 기능을 사용할지
그 과정에서 어떤 문구와 피드백을 받아야 덜 헷갈리고
덜 부담스럽게 느낄지를 계속 고민했다.
예를 들어
글쓰기 버튼을 눌렀을 때
작성 도중 나가면 어떤 알림이 떠야 할지
입력값이 비어 있으면 어떤 말투로 안내해야 할지
단순히 “내용을 입력하세요.”가 아니라
“어떤 이야기를 나눠볼까요?”처럼
보이지 않는 배려를 설계하는 것도
기획자의 일이다.
알림 기획도 빼놓을 수 없었다.
사용가 어떤 행위를 했을 때
그 행위가 타인에게 어떤 알림으로 전달돼야 할지
그 타이밍과 방식, 문구를 하나하나 정리했다.
예를 들어
댓글이 달렸을 때 ‘누가’ 썼는지까지 나오는 게 좋을지
앱 내 알림과 푸시 알림은 어느 수준까지 중복으로 가야 할지 등
단순한 ‘알림 설정’이 아니라
서비스 전반의 경험 전체를 설계하는 일이었다.
이 프로젝트는 수익이 없다.
하지만 이상하리만치 계속 붙들게 된다.
피그마를 열고, QA 시트를 작성하고
엑셀과 노션을 정리하면서 드는 생각
‘나 이 프로젝트 정말 좋아하네!’
기획은 보이지 않는 것을 보이게 만드는 일
기준을 만들고
조금 더 안정적인 흐름을 만들고
조금 더 따뜻한 문장을 고민하는 것
이 프로젝트가 어디로 이어질진 모르겠다.
하지만 분명한 건
좋아하고 잘할 수 있는 일을 할 때
나는 가장 나답고 즐겁게 일을 할 수 있다는 것이다.
