잠깐, 이건 좀 이상해요!
프로덕트 디자이너의 문제제기 경험기
들어가며,
이 글은 지난 회사에서 새로운 의견을 개진할 때 했던 행동과 생각, 회고를 솔직하게 정리한 글입니다. 날것의 과정이지만 개인의 기록 차원에서, 그리고 비슷한 상황에 놓인 메이커들에게 도움 되었으면 하는 바람에서 작성했습니다. 재밌게 읽어주시면 감사하겠습니다.
오류를 고치고 싶어요
그럭저럭 잘 다니고 있던 회사에 바라는게 생겨버렸습니다. 바로 눈엣가시 같은 앱의 오류들을 싹-없애버리고 싶다는 것이였어요. 눈치를 찔끔찔끔 보면서 주변 동료에게 오류들을 손보고 싶다고 슬쩍 얘기해봤지만, ‘개발자들이 바쁘니까’, ‘손이 없으니까’ 어렵지 않을까? 라는 어물쩍한 말들로 넘어간 기억입니다. 하지만 아무리 생각해봐도 오류는 덮어둘 수 없는 이슈였고, 그래서 이 문제를 꼭-반드시-필수적으로- 해결해야겠다고 다짐했어요.
직속 보고 체계를 통해 이슈화 하자
감사히도 회사 c-level분 들은 열린 마인드를 가지고 계셨어요. 조직 개편 당시도 팀마다 1:n 미팅을 해서 각 팀원에게 동의를 얻을 정도로 민주적이신 분들이였답니다. 열린 태도를 고스란히 담은 제도가 사내에 있는 ‘슈퍼패스’인데요, 간단히 말하자면 매니저(일반 사원)들이 원하는 제안이 있으면 직속으로 제안해서 검증을 거친 다음, 프로젝트화 할 수 있는 기회를 주는 제도입니다. 저는 이 제도에서 기회를 봤답니다.
논리적으로 이슈 레이징 하기
공론화 하자는 결심을 한 다음부터는, 어떻게 하면 설득력있게 이슈를 전달할지 고민을 했어요. 따끈하게 들어온 신입사원이 “앱 오류가 많이 발생하니, 고쳐보아요” 라고 얘기하는 상황이 갑작스러울 수 있을 것이라고 생각했기에… 이걸 진짜 해야하나 속으로 고민을 하기도 했답니다. 이때 마침 고민을 털어놓았던 주변 동료분이 문제의식에 공감 해주시고, 진심으로 응원 해주셔서 용기를 내었던 기억입니다.
1. 오류로 인한 탈퇴율 파악
가장 먼저 “이것은 문제입니다! 문제 있어요-!”라고 외칠만한 설득력 있는 데이터를 모으고자 했어요. 스텝바이 스텝으로 접근 가능한 사내 지표부터 들여다 봤는데요, 초심자의 행운 덕분인지, 그 가운데 눈에 확 튀었던 지표를 발견했어요. 순조롭게 적은 탈퇴 건수를 유지하다가, 최근 한 달 동안 특정 시점에서 몇 십배의 탈퇴 인원이 발생한 시점을 발견한 것이죠.
2. 탈퇴 사유 파악
탈퇴율은 왜 높아진걸까?
호기심이 발동해서 탈퇴율이 높아진 원인이 무엇인지 알아보고 싶어졌습니다. 오가며 마주치는 마케터, PM 분들께 가볍게 여쭤보며 알아본 결과, 당시 한창 진행 중이였던 앱 다운로드 이벤트로 인한 영향일 것 같다는 말을 들었습니다.
그렇다면, 유저가 탈퇴하는 이유는 뭘까?
다음은 유저의 탈퇴 사유가 궁금해졌답니다. 서비스 탈퇴 플로우 중에 탈퇴 사유 설문이 있었기에 있었기에, 해당 데이터를 보면 되겠다는 생각이 들었어요.
이후 수많은 탈퇴 사유 데이터를 정리해서 살펴본 결과… 유레카! 탈퇴 사유 설문 3위가 앱 오류로 인한 탈퇴라는 사실을 발견했답니다. 탈퇴율의 nn%가 ‘오류가 많아서’ 탈퇴하고 있었답니다. 설득력의 핵심 근거가 되는 데이터를 발견한 순간이였어요. 그와 동시에 ‘유저가 느끼기에도 앱에 오류가 많으니까 꼭 고쳐야 겠다’는 생각이 들었답니다.
“서비스 운영 주체로서 앱 오류는 필수적으로 고쳐야하기도 하고, 탈퇴 원인 3위를 차지할 정도로 사안의 중요성이 높으니… 오류를 손 볼 필요가 있어요”라는 주장의 논리가 세워졌답니다.
3. 미니멀 리소스 액션 플랜
어떻게 해결 해야할까?
마지막으로 어떻게 하면 쉽고 빠르게 해결할 수 있을지에 대한 액션 플랜을 고민했어요. 회사 입장에서는 리소스를 낭비하고 싶지 않을 테니, 최대한 메인 플로 위주로 미니멀하게 계획을 수립했답니다. 프로덕트 디자이너(본인)가 이틀 동안 앱 내의 모든 오류 케이스를 파악하고. 이틀동안 디자인을 수정하고. 개발자는 딱 하루만이라도 시간을 사용해서 긴급하고 중요한 오류만이라도 수정했으면 좋겠다고 생각했답니다. 앞으로 펼쳐질 야근 생각에 마음이 조금은 아찔해졌지만 눈 질끈 감고….. 마음을 가다듬었습니다.
제가 느낀 오류 이슈에 대한 일련의 생각과 제안, 액션 플랜을 담은 안건을 사내 워크 플레이스에 올렸답니다. 앗차차 너무 나대버린건가… 맘 졸이긴 했지만 다행히 대부분 문제에 동의하고, 용기있는 신입의 열정을 응원하는 분위기여서 마음이 놓였던 기억입니다.
그렇게 안건은 채택 되었고, 시간이 흘러 발표일이 다가왔어요. 사내에서 관심있는 사람은 자유롭게 참석할 수 있는 구조였는데, COO님과 단란하고 얘기할거라고 생각했던 것과 달리… CFO, HR, UX, PM 분들… 등 많은 분들이 이슈에 공감하셨는지 참관하러 와주셨답니다.
발표 현장에서는, 서비스의 발전에 대한 진정성을 담은 덕인지 ‘동의’의 공기가 멤돌았습니다. 안건 발제 이후 자연스럽게 논의가 오가며 ‘전사 QA체계 개선’으로 주제가 확장되었어요. 기존 엑셀 형식에서 QA를 하며 느꼈던 불편한 지점들을 새로운 툴을 사용해서 체계적으로 관리해보자는 의견이 오갔고, 담당자가 애매한 gray area가 재조명 되었고, 담당 팀 외에도 사내에서 누구나 오류를 발견하면 QA를 제보할 수 있는 창구를 마련하자는 대화가 오갔어요.
2시간 가량의 논의 끝에… 오류 잡기 프로젝트는 채택되었고, 나아가 탈퇴 페이지를 개선하는 tf 팀이 꾸려졌어요. 이후로 빙글빙글 일어났던 일들을 정리하면 다음과 같습니다.
IMPACT 1. 서비스 전체 QA 진행
액션 플랜대로 앱 전체 QA를 진행했답니다. 정말 운이 좋게도 오랜기간 QA직무로 일하신 경험을 가지신 신규 입사자 PM분이 함께 하고 싶다고 제안주셔서 수월하게 진행할 수 있었어요. Android, IOS 별로 구분해서 어떤 범위를 어떤 순서로 확인할 것인지 QA 전략을 세웠고, 발견한 오류를 우선 순위에 따라 분류했어요. 그리고 오류가 발생하는 파트의 담당자를 지정해서 오류를 인지할 수 있게끔 유도했답니다.
IMPACT 2. 탈퇴 페이지 개선
다음으로 탈퇴 페이지 개선 업무를 진행했어요. 오류 잡기 제안이 업무 외로 비공식적으로 진행되었다면, 탈퇴 페이지 개선은 업무의 일환으로 진행 되었답니다. 유저로부터 탈퇴를 하려고 결심한 원인을 파악해서 이를 해결해주고, 서비스에 한 번 더 머물러 볼까? 생각할 수 있게끔 하는 방향으로 플로우를 개선했어요.
IMPACT 3. QA 프로세스 개선
나비효과란 이런 것일까요...! 확장된 주제로 언급된 ‘전사 QA 체계 개선’이 진행되었어요. 해당 부분은 앱 오류 전반을 함께 파악했던 오랜 QA 경력을 가지신 PM 분이 진행해주셨는데요, 정기 배포일과 담당자 부재 영역 상황 등을 꼼꼼히 따지며 체계를 탄탄하게 다져주셨습니다. 바로 다음 달부터 Jira로 이관해서 진행했던 기억입니다.
회고
그래서 의미있었나, 어땠나... 생각해본다면 일단 ‘용기 내보길 잘했다’라는 생각이 들었습니다. 과정은 다사다난했을 지라도 결과적으로 조직과 서비스에 더 좋은 결과를 가져다 준 점이 무척이나 뿌듯했답니다. QA 프로세스 자체에 대한 이해도도 많이 올라갔구요. 또한 서비스 전체를 조망했을 때, 여러 기능이 하나의 플랫폼 안에서 구현될 때의 사용성에 영향을 미치는 일관성의 중요함, 오류를 발생시키는 변수를 디테일하게 고려하는 것의 중요성을 체감했답니다.
