이건 다섯 개의 레슨, 좋은 건 다같이 알기
에이전시에서 2년 일했었고, 인하우스에서 일한 지 1년이 넘었다.
이제는 이전 회사에서 일했던 방식보다 지금의 회사에서 일하는 방식이 훨씬 익숙해졌다.
현재의 방식에 익숙해지기 위해 그동안 많은 시행착오가 있었던 만큼 나도 성장했다는 생각이 든다.
WHY를 고민하는 서비스 기획자로서 일하면서 배우고 느꼈던 바가 있는데, 이 점을 공유해보려 한다.
다섯 개의 레슨
하나. 쉬운 기획과 어려운 기획을 나누지 말자.
둘. 최악의 케이스를 생각하며 기획하자.
셋. 데이터의 함정에 빠지지 말자.
넷. 로직을 세울 때는 개발자처럼 생각하자.
다섯. 기획 공유 시 히스토리와 WHY 설명은 기본 중의 기본
VoC, 협업 팀의 요청, 아니면 내가 발견한 포인트들... 하나하나 들여다보면 어떤 기획은 쉬울 것 같고, 어떤 기획은 어려울 것 같다는 생각이 들 때가 있다.
아래 이슈를 살펴보자.
- 이슈 1 : A라는 페이지의 뎁스(depth)가 깊어서 사용자가 '좋아요'한 게시물을 보기 위해서는 버튼을 3번을 클릭해야 하는 이슈가 있다.
- 이슈 2 : B라는 공간 유형을 보러 온 사용자들에게, 그들은 관심이 없는 C라는 공간유형을 추천해 주고 C 공간에 관심을 갖게 해야 한다.
위 두 가지 이슈를 봤을 때 이슈 1은 2에 비해 쉬워 보인다.
그래서 이슈 1을 쉽게 생각하고, 쉽게 기획한다면?
기획 내용을 공유할 때 협업자들에게 이 부분이 들통난다.
내가 쉽게 풀어낼 수 있는 이슈는 상대도 쉽게 파악하기 때문에 어쩌면 여러 공격(?)이 들어올 수도 있다.
내가 너무 가볍게 생각해서, 미처 고민하지 못한 부분까지 말이다.
난이도의 경중을 따지지 않고 어떤 사항이든 깊게 고민하는 것이 매우 중요하다.
사용자가 우리가 의도한 대로만 움직인다면 얼마나 좋을까?
아마 그랬다면 모든 서비스는 성공할 수밖에 없을 것이다.
슬프게도 사용자는 우리가 의도한 대로만 움직이지 않는다.
그렇기 때문에 기획을 할 때 청사진만 그리는 것은 위험하다.
내가 기획한 기능이 실패로 돌아갔을 때를 생각해야 한다.
최악의 케이스를 고려하지 않으면 기획의 허점이 많이 생길 수밖에 없다.
바야흐로 데이터가 중요한 시대.
그렇다 하더라도 데이터에만 너무 의존하거나 데이터에 의해 모든 결정을 내리면 안 된다.
데이터를 통해 인사이트를 얻고, 이를 통해 기획을 해나가는 것은 일반적인 일이지만 데이터가 주가 되면 많은 것을 놓칠 수 있다.
데이터로 봤을 땐 문제가 없어 보였던 것이, 실제로 내가 사용을 해봤을 때 UX 흐름에 문제가 있을 수도 있다.
아니면 사용자 인터뷰를 했을 때 문제가 발견될 수 있다.
데이터는 나의 의견에 힘을 보태줄 여러 근거 중 하나임을 잊지 말아야 한다.
데이터와 별개로, 정성적인 다른 요소들 또한 중요하다.
기획할 때는 개발자의 리소스를 고려하며 그 리소스 안에서 최선의 기획을 하게 된다.
하지만 개발자처럼 생각하며 로직을 세우지는 않았던 것 같다.
예를 들어, 커머스에서 많이 쓰는 방식이 있다.
장바구니에 물건을 담는 행위를 하면, 유사한 물건을 추천해 주는 모달을 띄운다.
만약 이 모달에 대해 기획을 하게 된다면?
어떤 물건을 추천해 줄지에 대한 로직을 세우게 될 것이다.
이때, '사용자가 조회한 물건, 좋아요 한 물건은 빼야지.'라고 생각하며 기획을 한다.
그리고 그대로 개발자에 전달하면, 개발자는 이렇게 말한다.
"그러면 사용자가 최근 조회한 물건 50개, 좋아요 한 물건 50개, 총 100개의 데이터를 불러와서 걸러야겠네요. API를 많이 사용하게 되면 로딩이 좀 느려질 것 같아요."
이와 유사한 대화를 한 후 느꼈다.
'아, 나도 개발자처럼 사고하면 개발적으로 어려운 것을 미리 잡아낼 수 있겠구나.'
물론 대화하면 개발자 분들이 이런 부분을 짚어주겠지만, 기획 시에 이 부분까지 고려한다면 정말 실력 있는 기획자가 될 수 있을 것이다.
최종 기획서를 개발팀에 공유하기 전, 상사에게 기획의 배경부터 왜 이렇게 해야 하는지에 대한 이야기를 미팅을 통해 전했다. 그랬더니 개발팀과 킥오프 미팅을 진행할 때 WHY에 대한 설명을 놓치게 된 적이 있었다.
상사에게 이미 너무 많이 설명해서 정작 개발팀에게는 중요한 부분을 간략하게 전달하게 되는 것이다.
이러한 상황이 되면 꼭 개발팀에서 질문한다.
"이건 왜 이렇게 하는 거예요?"
왜 이 기획을 하게 되었는지, 그리고 왜 사용자에게 선보여야 하는지에 대한 사항을 말해주지 않으면 개발자는 의문이 들 수밖에 없다.
"내가 이걸 왜 만들어야 하지?"
내가 한 기획을 진행하겠다고 설득해야 한다면,
기획의 대한 배경과 이유에 대해 '당연히' 설명해야 한다.
그리고 이러한 부분은 기획 시 정말 잘 준비가 되어야 한다.
기획을 하다 보면 나도 자꾸 잘 될거라며 좋은 쪽으로만 생각하게 될 때가 있고, '이건 쉽네' 하며 깊게 고민하지 않고 넘어가려고 할 때가 있다. 쉽게 넘어가려 할 때, 이 다섯 가지 원칙을 떠올려야겠다는 생각이 들어 다시 기록을 남겨봤다. 2025년에 배운 서비스 기획자의 다섯 가지 자세. 2026년에는 더 큰 깨달음을 얻고, 그 인사이트를 공유할 수 있으면 좋겠다는 생각이 든다.
+) 사실 작년에 성장하며 브런치에 많은 글을 남기고 싶었는데 우선순위가 계속 밀렸다.
그리고 글을 '잘' 쓰고 싶다는 욕심 때문에 글을 쓰는데 주저하게 되었다.
올해는 조금 더 가벼운 마음으로, 여러 생각을 나누는 것을 목표로 최소 20개의 글을 브런치에 남겨보려 한다. 자주 돌아 오겠습니다 :)