신고도 '잘' 했으면 좋겠어요
내가 애정하는 운영개선 프로젝트 1/2
목차
1. 신고하기 : 신고 프로세스 뒤에 고객경험(CX)팀 있습니다
2. 신고 '잘' 하기 : 드디어, 정형 데이터를 만나다
1. 신고하기
자주 사용되진 않겠지만 (그래서도 안되지만) 모든 서비스가 필수적으로 갖추어야 하는 기능이 있다: 신고하기. 으레 '신고'라고 하면, 서비스를 이용하면서 발생한 에러나 시스템 장애를 신고하는 케이스를 떠올릴 테다. 결제가 안돼요, 여기 페이지에서 안 넘어가요, 이상한 창이 떠요 등등. 나만 그런지는 모르겠는데 이런 경우엔 '문의'라는 워딩이 더 잘 어울리는 것 같다. 결이 다르다는 점을 차치하고서라도, 내가 이번 글에서 다루고 싶은 '신고'는 서비스 내에서 부적절한 활동을 펼치고 있는 타 유저 혹은 타 유저의 게시물을 reporting하는 케이스에 해당한다.
플랫폼 서비스는 수요와 공급을 끊임없이 연결하는 활력을 갖추면서도, 문제 회원을 솎아내거나 부적절한 활동을 모니터링할 수 있는 시스템을 구축해야 한다. 전자와 후자 중 어떤 항목이 우선시되어야 하는가? 를 궁금해하는 분도 계실 것 같은데, 이건 닭이 먼저인지 달걀이 먼저인지를 논하는 것과 마찬가지라고 생각해서.. 음, 아무래도 각자의 믿음을 따르는 편이 좋겠다. 그러나 분명한 사실은 이 2가지 시스템이 갖춰져야만 플랫폼 내의 생태계가 건전하게, 그리고 지속 가능한 형태로 유지될 수 있다는 점이다.
타 서비스의 '신고하기' 기능 레퍼런스물론 우리 서비스도 '신고하기' 기능을 갖추고 있다. 그러나 우리 서비스의 '신고하기' 페이지를 살펴보기 전에, 잘 만들어진 '신고하기' 페이지들은 어떤 공통점을 갖고 있는지를 먼저 살펴보려 한다. 우선, 이들은 신고 유형을 정말 체계적으로 분류하고 있다. 그리고 각 항목마다 입력하거나 제출해야 할 자료의 depth를 각각 다르게 설정하고 있다. 그런데 유저의 편의성만 따져보면, 그러니까 유저가 더 편리하게 신고하길 바랐다면 그냥 빈 입력창을 하나 만들어놓는 편이 좋지 않았을까? 왜 잘 만들어진 서비스들은 신고 유형을 이렇게 섬세하게 분류하고 있는 걸까?
그 이유는 '신고하기' 기능의 핵심이 신고가 아닌, 접수와 처리이기 때문이다. 애초에 유저들이 타 유저 혹은 타 유저의 게시글을 신고하는 목적은 부적절한 활동에 대한 제재/처벌이다. 그래서 '신고하기' 페이지에서 유저가 편리하게 신고할 수 있는 UI/UX를 제공하는 것은 큰 의미가 없다. 오히려 신고된 건들을 빠르고 정확하게 처리할 수 있는 시스템을 만들고 '신고하기' 페이지도 그 시스템의 일부로 기능할 수 있도록 다양한 depth를 가진 UI를 적용하는 편이 더욱 유의미할 것이다. 즉, '신고하기' 페이지의 핵심 유저는 고객경험(CX)팀 담당자이며, 해당 페이지의 주목적은 그들의 업무 효율성을 높이는 것이 되어야 한다.
2. 신고 '잘' 하기
자, 이제 우리 서비스의 기존 '신고하기' 페이지를 함께 살펴보자. 신고대상 유저의 프로필 사진과 마스킹 처리된 이름, 그리고 회원번호가 기재된 영역이 전체 페이지의 1/4 가량을 차지하고 있다. 그 아래로 신고 유형과 내용을 입력하도록 되어있고, 가장 하단에는 주의사항 문구가 기재되어 있다. 신고 유형은 크게 6가지이고 이 중 무엇을 선택하든 신고 내용을 자유롭게 입력할 수 있도록 만들어져 있다.
1.에서 언급했던 레퍼런스들이 best practice라고 생각했던 나는, table 구조와 UI/UX를 대대적으로 개편하자고 제안했다. 페이지도 나누고, 그 안에서도 텍스트 입력을 받을지 말지도 구분하고 싶다고 했다. 그것도 2주 안에. 솔직히 "이게 2주 분량인 것 같냐!"라고 화내며 맥북으로 내 머리를 내려쳐도 됐을 텐데, 메이커 분들은 침착하게 날 앉혀놓고 이렇게 하면 최소 4주는 걸린다는 점을 차근차근 설명해주셨다. 그래서 다시, 2주 안에 최대의 impact를 낼 수 있는 기획안을 메이커 분들과 함께 고민하기 시작했다. (오늘도 개발자가 안된다고 말했다.. 왜냐하면 내가 말도 안 되는 걸 들고 갔으니까)
내가 원하는 건 유저들에게도, 그리고 고객경험팀 분들께도 카테고리 구분이 명확하게 "보이는" 것이었다. 그런데 이 목표를 달성하기 위해 table 구조까지 엎어가면서, 대분류 페이지와 중분류 페이지를 별도로 제공할 필요는 없었다. 이미 '신고 유형'과 '신고 내용' 영역이 구분되어 있으니, 각각의 input 값을 대분류 > 중분류로 설정해주면 될 일이었다. 이렇게 컨셉을 잡고 나니 개발 scope이 확 줄어들었고, 서버에서는 '신고 유형'의 key값을 업데이트하고, 클라에서는 해당 페이지에 액션시트를 추가하는 간단한 작업만 진행하기로 했다. 제품에 진심인 사람들과 함께 고민하면 언제나 멋진 답이 나오는 것 같다.
신고대상 유저의 프로필 정보 표시 영역도 tone down했다그 결과물이 바로 이 페이지다. 유저들의 반응은 어땠을까? 동기간 내 신고 수가 40%+ 증가하는 쾌거를 달성했다. 내가 이 결과를 '쾌거'라고 부르는 이유는 딱 하나다. 기존 '신고하기'와 달리, 신규 버전에서는 정형화된 데이터가 쌓이기 시작했기 때문이다 (심지어 더 많이). 혹자는 '아니, 카테고리를 2-depth로 만들어놨으니 당연히 그렇게 쓰겠지'라고 생각할 수도 있다. 그러나 '기타(직접 작성)' 옵션을 선택해 예전처럼 신고 사유를 작성할 수 있음에도 대부분이 대분류 > 중분류 값을 선택했다는 것은 (1) 우리가 더욱 편리하고 직관적인 UI를 제공했다는 점, (2) 그리고 우리가 특정 유형에 대한 후속 조치(예: 페널티, 유의사항 안내)를 자동화할 수 있게 되었다는 점에서 큰 의미를 갖는다.
그래서 그걸 자동화했냐고 질문하신다면, 아직 못했다. 우선순위가 더 높은 작업이 많았기 때문에 아직은 백로그에 담겨있는데 조만간 고객경험(CX)팀과 미팅을 해서 자동화 방식을 논의하기로 했다. 정말이다. 그래서 아쉽지만 다음 글에서는 '신청' 도메인에서 진행했던 운영개선 프로젝트를 하나 더 공유해보겠다. 운영개선 프로젝트로 시작해서 우리 팀 Objectives 달성의 주역으로 떠올랐던 감동의 프로젝트다.
*덧. 최근 새로운 사이드 프로젝트를 시작하게 되면서 브런치 글을 작성할 시간이 줄어들었는데, 가까운 미래에 고객경험팀 업무 자동화 프로젝트에 대한 글을 쓰기 위해서라도 계속 열일해보겠습니다.
