로톡 의뢰인 스쿼드는 어떻게 문제를 풀까? 사용자 로그인 요청 프로젝트 ①

WORK

BY | 로톡 의뢰인 스쿼드 (정우철)

DATE | 2023. 05. 17.

로톡 의뢰인 스쿼드의 로그인 요청 프로젝트 로톡 의뢰인 스쿼드는 구성원은 누구이고, 이들은 어떻게 일하고 있을까요? 로그인 요청 프로젝트를 완료한 의뢰인 스쿼드를 소개합니다.

로톡은 법률문제 해결이 필요한 의뢰인과 법률 전문가인 변호사가 자유롭게 소통할 수 있는 공간을 제공하고 있습니다. 그 공간을 만들어내기 위해서 로앤컴퍼니의 다양한 구성원들이 각자의 자리에서 열심히 노력하고 있는데요, 로앤컴퍼니 프로덕트본부는 로톡의 이용자인 의뢰인과 변호사 사이드에서 각각 스쿼드를 구성하여 제품을 유지하고 개선하는 업무를 하고 있습니다.

그중 의뢰인 스쿼드는 로톡의 의뢰인이 제품을 사용하는데 있어 불편함이 없도록 제품을 개선하는데 집중하고 있어요. 의뢰인 스쿼드에는 누가 어떻게 모여서, 어떤 방식으로 제품을 유지하고 개선하고 있을까요?

로톡의 의뢰인 스쿼드에 대해, 그리고 우리가 일하는 방식에 대해 소개해 보려고 해요.

로톡의 의뢰인 스쿼드를 소개합니다.

로톡 의뢰인 스쿼드 (왼쪽부터 근영님, 정아님, 초이님, 수연님, 종인님, 우철님, 중현님 그리고 마늘이)

의뢰인 스쿼드에서는 누가 무슨 일을 하고 있나요?

의뢰인 사이드에서 로톡 제품을 개선하는 업무를 하고 있는 의뢰인 스쿼드는 어떻게 구성되어 있을까요? 스쿼드 구성원 각자가 맡고 있는 역할과 핵심멤버(?) 마늘이까지 소개합니다.

프로덕트 오너(PO;Product Owner) 담당하고 있는 영역이 개선되어야 할 큰 방향을 설정·조율하고 목표 지표 및 제품 개선 로드맵 설정을 주도하고 있습니다. 제품 개선 방향에 대해 제안하고 주요 팀장님들과 목표 및 가설설정에 대한 크리틱을 거치며 로드맵 설정까지 한다는 측면에서 일반적인 PM(Product Manager)업무보다 조금 더 넓은 범위의 업무영역을 갖습니다.

프로덕트 디자이너(PD;Product Designer) 설정된 비즈니스 목표를 달성해내기 위해 요구되는 사용자 경험을 사용자 여정에 따라 점검하고 구축하는 역할을 합니다. 사용자 인터페이스에 대한 이해관계자 피드백 수렴 그리고 구현된 결과물의 최종 검수 및 사용성 분석 결과에 대한 고민까지를 수행하고 있습니다. 또 마늘이의 유산균 간식 배급을 책임지며 마늘이의 사랑과 관심을 잔뜩 누리고 있습니다.

데이터 분석가(DA;Data Analyst) 사용자의 서비스 이용 경험이 정량화 될 수 있도록 데이터 수집을 계획하고 분석하는 업무를 수행하고 있습니다. 데이터 분석을 토대로 다양한 분석 보고서를 작성하여 팀의 의사 결정을 지원하는 역할을 합니다. 다양한 종류의 지표 추적을 고민하고 의사결정 기준 설정 단계부터 사용자 인터페이스 활용 분석 단계까지 다양한 논의에 참여하고 있습니다. 무엇보다 마늘이 엄마로서 사료 배급과 교육 관리를 병행하고 있습니다.

프론트 개발자 (FE;Front-End developer) 논의된 사용자 인터페이스와 사용자 경험을 최종 구현하는 역할을 합니다. 단순히 시각적 인터페이스 구현을 넘어 UI 인터랙션 및 사용자 경험을 위한 기술적 고민을 주도하고 있습니다. 스프린트에서 다루어지는 기능개선 이외에도 다른 스쿼드에서 요청된 코드 리뷰도 수행하며 제품의 기술적 안정성까지 고려하기 위해 노력합니다.

백엔드 개발자 (BE;Back-End developer) 새롭게 시도하려는 개선사항에 있어 서버 단에서 지원해야 할 사항은 무엇일지 고민하며 데이터베이스, 서버, API를 구축/관리합니다.

그리고,

마늘이(dog, puppy) 출근하면 구성원들 자리를 한 번씩 체크하고 데일리미팅 회의 중에는 주변의 위협은 없는지 경계하기도 합니다. 구성원의 무릎에 앉아 결과물을 함께 구경하기도 하고요. 무엇보다 구성원들의 스트레스 해소 및 공동 관심사 역할을 맡고 있습니다.

로톡 의뢰인 스쿼드는 어떻게 제품을 개선할까?

최근에 로톡 의뢰인 스쿼드가 해결한 ‘사용자 로그인 요청’ 사례를 소개해보려고 해요.

어쩌면 이번 아티클 내용은 어떤 스타트업 조직에서든 흔히 있는 뻔한 이야기일 수도 있지만, 저희 로톡 의뢰인 스쿼드가 일하는 방식을 잘 보여주는 사례라고 생각해서 이 글을 작성하게 되었습니다.

목표를 설정하고, 우선 순위 정하기

로톡 의뢰인 스쿼드는 제품을 개선할 때 목표를 설정하고, 목표에 따른 업무의 우선 순위를 정해서 프로젝트를 진행하고 있어요. 저희가 이렇게 하는 이유가 무엇일까요?

실제로 운영되고 있는 제품의 경우에는 개선해야 할 점들이 산발적으로 발생합니다. 현재 기능에 대한 보완 및 개선부터 신기능 출시뿐만 아니라, 넓게 보면 협업부서에 대한 지원과 시장상황에 대한 대응 등도 제품 개선 사항에 큰 영향을 끼치죠. 이렇게 다양한 개선사항들이 발생하기 때문에 로톡 의뢰인 스쿼드는 여러 갈래길 사이에서 우선순위를 정해야만 하는 어려움이 있어요.

그 어려움을 해결하기 위해 로톡 의뢰인 스쿼드는 이용자에게 필요한 수많은 기능들 중 제품이 놓여있는 현 시장상황에서 가장 시급하게 개선되어야 할 것이 무엇인지를 선정하고 우선 순위를 정하고 있어요.

물론, 우리가 상상하듯이 한번에 모든 걸 다 이룰 수 있다면 목표와 우선 순위 설정이 불필요하겠지만 우리에게 주어진 제품 개선 시간(리소스)은 한정되어 있기 때문입니다.

그렇다면 로톡 의뢰인 스쿼드의 목표는 무엇일까요?

저희에게는 로톡을 통해 ‘시장에 없는 새로운 사용자 경험을 만들고, 그 토대 위에 비즈니스 가치를 일궈낸다’ 라는 확실한 목표가 있습니다. 로톡 의뢰인 스쿼드는 이러한 목표에 맞춰 업무 우선순위를 설정하고 있어요.

개선 아이템 선정 사례 ‘사용자 로그인 요청’

최근에 저희가 우선 순위로 업무를 진행했던 ‘사용자 로그인 요청’ 과제는 로톡 의뢰인 스쿼드의 업무 방식을 잘 보여줘요.

이 과제는 ‘사용자의 재방문’이라는 목표에 초점을 맞추고 진행하였는데요, 사용자 로그인 요청은 다양한 개선 아이디어 중에서도

•

의뢰인 스쿼드가 목표로 하고 있는 ‘사용자 행동’ 을 유도하는 과제

•

짧은 기간 동안 낮은 구현비용(the low-hanging fruit; 다른 기능개선이 진행되는 중이라도 시도 가능한 쉬운 일)으로 시도해보기 좋은 과제

위 두 가지에 구성원 모두가 공감하여 적극적으로 시도해보기로 한 백로그였어요.

얼핏 간단해 보이는 ‘사용자 로그인 요청’ 프로젝트에도 의뢰인 스쿼드의 디자이너, 개발자, 데이터사이언티스들의 의도와 목적이 모두 반영되어 있는데요, 의뢰인 스쿼드의 각 구성원들은 이번 업무를 어떻게 리뷰할까요?

‘사용자 로그인 요청’의 OOO

로톡에 방문한 사용자에게 로그인을 요청하는 화면

프로덕트 디자이너 초이님 “왼쪽 모바일에서는 로그인 영역을 일부러 크게 잡았어요. 이용자에게 해당 영역이 신경 쓰이게 만들어서 로그인을 유도해보려는 의도였어요”

① 디자인 의도 ( 초이님 )

‘사용자 로그인 요청’ 에는 다양한 디자인 의도가 숨어있는데요, 디자인 의도를 세부적으로 나눠서 이야기해보자 합니다.

•

인터렉션 : 모바일은 바텀시트, 데스크탑은 하단 띠배너 형식으로 부담스럽지 않게 부드럽게 하단에서 뿅!하고 silde in/out 되는 인터렉션을 구현했어요.

•

이미지 : 심볼 로고를 활용한 이미지를 통해 아이캐칭을 유도했어요 (+ 새로운 심볼 은글슬쩍 데뷔)

•

텍스트 : ‘나에게 맞는 사례를 더 쉽게 찾고, 내 관심글로 저장해보세요.’ 라는 로그인 혜택을 언급했어요.

•

‘다음에’ 버튼 :

◦

좌측에 작게 위치시켜 최대한 손가락에서 멀어지도록 했어요.

◦

‘로그인’과 같은 레벨의 버튼으로 노출하여 방향성에 맞게 “굳이 지금 로그인 안 해도 괜찮아” 라는 쿨한 느낌을 주려고 했어요.

◦

‘닫기’ 보다 ‘다음에’라는 좀 더 부드럽고 로그인에 대한 여지를 남기는 워딩을 사용했어요.

•

‘로그인’ 버튼 : 터치 및 클릭을 유도하기 위해 우측에 width 값을 크게 노출했어요.

②개발과 속도 ( 종인님 )

의뢰인 스쿼드는 보통 2주 단위로 묵직한 제품개발 단위를 가져가고 있었는데, ‘사용자 로그인 요청’은 1주일 만에 구현 가능한 아이디어를 그 사이에 밀어넣어 시도해 본 사례였어요.

•

리서치와 완성도를 공들여 성공가능성 높이기 VS 빠른 전달을 통해 가설 검증하기

보통 무엇인가를 하나 할 때 여러 사람의 의견을 수렴하고 리서치 방법론을 사용하여 공을 들이는 경우들도 있지만,작은 스쿼드 단위에서는 빠른 전달을 통해 시장 반응을 보고 개선해가는 방식도 있습니다.

의사결정 속도를 높여 제품개발 속도를 끌어올리는데 있어서 중요했던 건 ‘동료를 믿고 맡기기’ 그리고 ‘분석 결과를 통해 다음 개선포인트 잡기’였습니다. 제일 어려운 건 ‘동료를 믿고 맡기기’인데요. 이게 보는 관점(view point)에 따라 너도나도 할 잔소리가 많아지고 내가 보기엔 누군가의 결과물이 어리숙해 보이는 결과물로 보여져 받아들이기 힘들게 느껴질 수도 있다는 점이에요.

제가 말하고자 하는 개발 속도는 개발자의 코딩 속도도 아니고 디자이너의 마우스 클릭 속도도 아니며 ‘팀의 속도’를 의미합니다. ‘팀의 속도’는 일회성 달성 마감일(due date)이 아닙니다. 반복되는 주기 속에서 기대 가능한 개발속도 정도로 말씀드리고 싶은데 이는 팀이 겪는 반복된 실패에 기반해 그 속도가 결정된다고 생각해요(제식이나 이인삼각처럼). 우리는 모두 다른 방식으로 일해왔고 다른 전문성을 띤 사람들이고 각 도메인에 대한 이해의 깊이가 상이하니까요.

무엇보다 동기부여 측면에서도 ‘이번엔 실패했네’가 객관적으로 드러나야 다음 시도에서는 같은 방식으로 실패하지 않기 위해 더 많이 알아보거나 공부를 하는 계기가 되고, 이러한 일련의 과정을 통해 팀이 실제로 성장하게 되는 것이라고 생각하고 있어요.

③신뢰할 수 있는 데이터 ( 근영님 )

우리는 제품 개발을 할 때 이런 이야기를 할 수 있어요.

“아 그거 벌써 해봤는데 별거 없어”,

“그거 봐 내가 뭐라고 그랬어”

업무경험이 쌓인 자의식 강한 나 정도가 이정도 짬밥이 되었는데 이런 이야기를 하는 것은 사실 안 봐도 뻔하거든요. 하지만 우리의 입장에서의 대답은 이런거였습니다.

“아 그래? 그럼 정말 그런지 빨리 확인해보자”

“어 이번에 해보니까 이런 부분들이 실제로 발견되네”

결국 우리가 문제를 해결하는 방식은 “이상적인 UI의 정답은 사용자가 알고 있다. 사용자에게 물어보자.” 였어요. 우리 스쿼드 멤버들은 이 방식에 모두 공감하고 실제 사용자에게 빠르게 확인해보자는 입장입니다.

그래서 A/B 테스트를 준비하고 데이터분석을 함께 병행하는데요, 이 과정에서는 데이터분석팀의 리드 정아님이 다른 로톡엑스 아티클에서 강조한 것과 같이 ‘신뢰할 수 있는 데이터’가 정말 중요합니다. 신뢰할 수 없는 데이터라면 결국 ‘코에 걸면 코걸이 귀에 걸면 귀걸이’ 식으로 해석되기 때문이에요. 신뢰할 수 없는 데이터 진흙탕에서 굴러먹던 억울함이 느껴지시나요?