“근데 솔직히 모임 일정 잡는 게 진짜 제일 귀찮고 불편해요.”

인턴분이 툭 던진 그 한마디가 시작이었다. PM은 원래 온갖 사람의 의견을 듣는 자리이다. 현장에 가장 가까이 서 있는 사람의 말에는 특히 더 귀가 기울여지기 십상이다. 대학생들이 팀플이나 동아리 일정을 잡을 때 외부 서비스를 쓴다는 건 알고 있었다. 정확히 무엇이 불편한지는, 사실 한 번도 깊게 들여다본 적이 없었다.

가설 검증 | 모임 일정을 조율하는 일은 피로하다

다른 학생들도 인턴과 똑같은 피로를 느끼고 있을 거라는 가설을 세웠다. 검증을 위해 곧바로 인터뷰이를 모았다. 팀플 팀장 경험이 있는지, 지금은 일정을 어떻게 조율하는지, 그 불편함이 어느 정도인지를 기준으로 세그먼트를 나눴다.

돌아온 대답은 크게 두 가지였다.

하나는 모바일 경험의 붕괴였다. 대학생들의 모든 대화는 스마트폰 안에서 이루어진다. 그런데 정작 일정을 입력하려고 하면 PC 화면에 맞춰진 웹사이트를 열어야 했다. 손가락으로 가느다란 시간 칸을 하나하나 위태롭게 누르고 있었다.

다른 하나는 리마인드의 피로였다. 팀플의 팀장들은 팀원들이 가능한 일정을 입력했는지 확인하고, 아직 입력하지 않은 팀원이 있다면 한 명 한 명 지목하며 리마인드 메시지를 보내야만 했다.

여러 차례 인터뷰를 진행하며 이러한 불편이 실제로 존재하는지, 일부 학생에게만 국한된 문제는 아닌지를 확인했다. 문제의 강도와 빈도, 보편성을 기준으로 하나씩 검증해 나간 것이다. 이렇게 검증을 거듭한 끝에 확신이 섰다. 이 정도 크기라면 지표에도 유의미한 임팩트를 만들 수 있겠다는 확신이었다. 가설 검증이 끝나자, 프로젝트는 비로소 정식 궤도에 올랐다.

화면 한 장으로 기획의 속도를 앞당기다

가설 검증이 끝나고 디자이너와 함께 화면 스케치부터 시작했다. 머릿속에만 있던 아이디어를 그려서 팀장님, 본부장님과 나눴다.

글로만 논의할 때는 사람마다 전혀 다른 그림을 그린다. 눈에 보이지 않는 건 결국 각자 상상으로 채워야 한다. 그 상상력이 부족하면 논의 자체가 겉돌기도 한다. 그런데 눈에 보이는 화면 한 장을 펼쳐놓으면, 얼라인먼트 속도는 완전히 달라진다.

예전 같으면 이 정도 합의에 최소 일주일은 걸렸을 거다. 구두로 대략의 방향을 공유하고, 디자이너 손에서 결과물이 나오면 그걸 다시 논의하고. 그 사이사이 서로 다른 상상을 하고 있었다는 걸 뒤늦게 확인하는 일도 잦았다. 요즘은 다르다. Google AI Studio나 클로드 코드로 논의가 시작되는 순간부터 실제 제품에 가까운 프로토타입을 띄워놓고 이야기한다. 덕분에 리스크나 고려해야 할 지점을 더 빨리 캐치하게 됐다. 서로 다른 생각도 훨씬 쉽게 정렬할 수 있었다. 의사결정권자와 논의할 때도 그 자리에서 제품의 큰 그림을 빠르게 맞출 수 있었다. 일주일이 하루가 됐다고 하면, 조금 과장 같지만 정말 그렇게 됐다.

모바일 UX 디테일 하나하나에 기준을 세우며 구현하다

구현 단계로 넘어가서는 엔지니어들과 기술적으로 가능한 범위를 맞춰가며 모바일 UX 디테일에 매달렸다. 화면에서 정보를 어떤 순서로 배치할지, 투표 결과를 어떤 컬러로 구분해서 보여줄지. 사소해 보이지만 놓치면 바로 티가 나는 디테일들이었다. 혼자였다면 절대 여기까지 못 왔을 거다.

먼저 생성 과정을 ‘날짜·시간 선택’과 ‘세부 정보 입력’까지 두 단계로 나눴다. 한 화면에서 너무 많은 결정을 내리게 하고 싶지 않았다.

투표 결과를 직관적으로 보여주기 위해 선택한 요소는 ‘컬러’였다. 시간표에 어떤 컬러로 어떻게 구분해서 보여줄지 결정하는 일이 생각보다 단순하지 않았다. 단순히 인원수 순서대로 명도를 매기면, 참여 인원이 많아졌을 때 구분이 뭉개져 버린다. 그래서 명도 단계를 여섯 개로 고정했다. 가장 많은 인원이 가능한 시간대는 가장 진하게 표시했다. 그 아래로는 상대적으로 흐린 농도를 주되, 일정 비율 이하로 투표를 받은 시간대는 유저의 일정 조율에 미치는 영향이 크지 않을 것으로 보고, 전부 가장 옅은 값으로 묶었다. 10명이 투표했다면 5명 이하가 고른 시간대는 다 같은 색이 되는 식이다. 사소해 보이지만, 정하는 데 가장 오래 걸린 기준이었다.

다음 기능과의 접점까지 미리 그려둔 설계

하나 더 신경 쓴 게 있다. 단발성 기능에 그치지 않는 것.

요즘 에브리타임은 연합게시판이나 지역채팅처럼 캠퍼스 밖으로 손을 뻗는 시도를 이어가고 있다. 판이 커질수록, 모임과 팀플을 이어주는 유틸리티의 자리는 더 커진다. 그래서 모임 일정 투표가 시간표나 채팅 같은 기존 기능들과 자연스럽게 엮이도록 설계에 미리 여지를 남겨뒀다. 유저가 에타 안에서 모임을 만들고 소통하는 흐름 전체를 이어가려면, 지금 당장 쓰지 않을 연결고리라도 미리 정리해둬야 한다.

정해둔 지표로만 돌아본 배포 후 성과

배포 이후에는 배포 전에 정해둔 지표로만 성과를 추적했다. 지표를 나중에 정하면 결국 보고 싶은 것만 보게 된다. 그래서 무엇을 성공으로 볼 것인지는 가능한 미리 정해두고 있다.

목표는 모임 일정 투표에 참여하는 유저를 충분히 확보하고, 그중 일정 비율 이상이 실제로 캘린더에 일정을 추가하도록 만드는 것이었다.그런데 이 두 숫자는 전형적인 output metric, 즉 결과가 다 벌어지고 난 뒤에야 확인할 수 있는 후행 지표였다. 그래서 이 결과를 만들어내는 더 앞단의 지표, input metric이 필요했다. 누군가 투표에 참여하려면 그 전에 누군가 먼저 투표를 만들어야 한다. '투표 생성'이 있어야 '투표 참여'도 일어날 수 있는 셈이다. 그래서 참여보다 앞서 일어나는 이 생성수를 input metric으로 정하고, 매일 들여다봤다.

단순히 얼마나 많이 쓰이느냐보다, 실제로 어떻게 쓰이는지를 더 눈여겨봤다. 예상한 방식대로 사용되고 있는지. 무엇보다 반복해서 쓰이고 있는지, 나아가 이게 전사 목표에 얼마나 영향을 주는지까지 확인하려 했다.

배포 후 지켜본 유즈케이스는 다행히 예상과 크게 다르지 않았다. 팀플부터 개인적인 약속, 동아리, 대외활동까지, 그려뒀던 그림 그대로 쓰이고 있었다. 다만 같은 이름으로 투표를 여러 개 만드는 유저들도 눈에 띄었다. 처음 만들 때 뭔가 실패해서 같은 걸 다시 만드는 게 아닐까 싶어, 지금 그 지점에서 개선할 포인트가 있을지 들여다보고 있다.

한 가지는 아직 풀지 못했다. 유저들이 투표를 한 번 만들고 나면 다시 만들지 않는 흐름이 이어지고 있다. 기대했던 것보다 생성수 자체가 작다. 어디서 매력을 못 느끼고 있는 건지, 애초에 세운 가설 자체가 틀린 건 아닌지, 여전히 답을 찾는 중이다.

단 한 명의 목소리에서 읽어낸 유저 피드백

모임 일정 투표를 함께 쓰는 친구들 모두, 이 기능이 시간표랑 연동됐으면 좋겠다고 입을 모아 이야기했다는 걸 인터뷰이에게 전해 들었다. 사실 예상 못한 반응이었다. 시간표 연동은 그동안 후순위 로드맵으로 미뤄둔 상태였으니까.

모임 일정 투표 기능의 사용량 자체가 많지 않다 보니 이 기능에 대한 의견을 모으는 일부터 쉽지 않았다. 이 인터뷰도 모임 일정 투표에 VOC를 남겨준 딱 한 명의 유저를 겨우 섭외해서 진행할 수 있었다. 표본은 단 한 명. 하지만 PM의 직감이랄까? 이 '시간표 연동' 요청이 유저들이 이 기능에 걸고 있는 공통된 기대라는 확신이 들었다. 사람은 새로운 걸 접하면 자기도 모르게 그동안의 경험을 기준으로 기대치를 세운다. 동네에 새로 생긴 순대국집에 가도, 그동안 먹어본 순대국의 경험을 무의식중에 끌어와 나름의 예상을 하게 되는 것처럼 말이다. 모임 일정 투표에서 그 기준은 시간표였다. 시간표는 에브리타임을 상징하는 기능이니까, 유저 입장에서는 당연히 새 기능도 시간표와 연결되어 있을 거라 상상했을 거다. 그 기대를 맞추려면 너무 새로워도, 너무 뻔해도 안 된다. 적당히 새롭고, 어느 정도는 뻔해야 한다.

더 마음에 걸렸던 건, 사실 이 얘기가 처음이 아니었다는 점이다. 출시 전 인터뷰에서도 한 번 같은 이야기가 나온 적이 있었다. 다만 한 번뿐이라 그냥 흘려보냈다. 왜 그때 더 기민하게 반응하지 못했을까. 모임 일정 투표 기능이 시간표와 연동되었다면 더 많은 유저가 사용하게 되었을까. 그동안 애써준 사람들의 노력을 내가 흐려버린 건 아닐까. 한동안 이런 생각에서 쉽게 벗어나지 못했다.

그럼에도 그 뻔한 기대치를 맞추기 위해, 시간표 연동을 다음 로드맵의 최우선순위로 올렸고 업데이트를 앞두고 있다.

돌아보면, 모호함 앞에서 해야 할 일

이번 프로젝트에서 확실히 배운 게 있다. 기능을 기획할 때는 기능 그 자체만큼이나, 유저가 에브리타임 안에서 이 기능을 어떤 모습으로 상상할지를 함께 고려해야 한다는 것. 같은 기능이라도 어떤 앱 안에 놓이느냐에 따라 유저가 기대하는 모양이 달라진다. 에브리타임에서 일정을 잡는다면, 유저는 당연히 자기 시간표가 거기 있을 거라 생각한다.

물론 유저의 말이 항상 정답은 아닐 수도 있다. 그만큼 신규 기능이라는 건 정답이 없고 모호한 일이라는 생각이 거듭 든다. 모호하다고 확신을 얻을 때까지 마냥 기다릴 수만은 없다. 내가 할 수 있는 일에 집중해야지. 계속 시도하고, 유저를 만나러 가야지.

-

Written by 정성훈 | 비누랩스 프로덕트 매니저

자기 소개 : 혹시 에타 쓰시나요? 인터뷰 좀 가능하실까요?