Toss Design Conference | Simplicity24
Product Designer (Tools) 특별편 - Simple Questions, Big Wins
toss.im
혹시나 이 컨퍼런스가 궁금하신 분은 아래 정리내용이 매우 난잡하고,
개인 공부를 위한 기록용이니, 원본 컨퍼런스를 보실 것을 추천드립니다 😂
토스 디자인 컨퍼런스 Simplicity24
오픈 사전신청만해두고 시간이 없어서 못보고 있었는데 강의가 일찍 끝난 김에 듣기 시작했다.
심플리시티24는 토스의 Product Designer (Tools) 직군 특별편으로 제작했어요. Product Designer가 여러분이 사용하는 토스 앱을 만든다면, Product Designer (Tools)는 B2B 고객과 내부 고객 대상의 제품을 만드는데, 그래서 토스 외부에선 우리가 어떤 제품을 만드는지, 어떻게 일하는지 알기 어려웠어요. 그래서 토스 뒤에 가려졌던 디자인 프로세스를 여러분과 공유하고 싶어서 기획했어요
track 1. Wise Whys
문제의 본질을 파고들어 모호함을 임팩트로 만들어낸 이야기
1. 우선순위가 없을 때 디자이너는 어떻게 해야할까?
#토스쇼핑광고 #우선순위
Product Designer(Tools) 이지현님
- 문제
: 토스 광고 내 쇼핑광고팀 사용성 개선 필요
문제1. 쇼핑광고팀 업무에 대한 파악 필요
Product Design팀 내 디자이너와 개발자가 지속 VOC가 들어오는 토스 쇼핑광고팀의 업무를 어디에서부터 우선순위를 두고 개선해야할지 어려움을 느낌 → 해당 팀 업무에 대한 이해 필요
- 가설
: 역할자별로 여정(어떤 업무를 하는지) 정리하면 문제를 파악할 수 있을 것이다.
[토스 쇼핑광고팀]
1)셀러팀과 제안팀: 광고에 관심이 많은 고객(셀러)들에게 광고를 제안 및 추천
2)광고운영팀: 신청서 검수 및 승인
- 해결
셀러/운영팀/제안팀 세가지 카테고리로 나누어 유저맵을 그렸고(일주일 반정도 소요)
운영팀과 주 1~2회 미팅을 가지며 완성해나감
- 결과
- 당팀 외 유관팀들도 업무와 업무들이 어떻게 이어지는지 파악이 됨
- 우선순위에 대한 공감대가 형성됨: 이전에는 각자의 우선순위를 다르게 생각했음
문제2. 쇼핑광고팀의 업무 편의성 개선 툴 개발
- 유저 저니맵을 통해 운영팀의 예약현황단계에 대해 개선으로 방향이 좁혀짐 (예약현황단계: 광고상품을 진열하는 6슬롯을 예약현황단계라 명명하고, 이들이 모두 찼는지 관리하는 것)
- 이 부분을 먼저 개선하기로 한 이유: 비즈니스 측면과 운영 효율 단계에서 시급도가 높다고 판단함
- 사용성이 너무 불편함: 매번 수기로 진행 단계를 변경하고 있었음(하기 첫 이미지 역제안 부분)
- '제안팀'에서 하기 시트를 채워서 '운영팀'에 전달할 경우, 운영팀에서는 셀러의 신청서와 일치하는지 이를 일일히 확인작업이 필요했었음(제안 담당자와 확인 담당자가 달라, 커뮤니케이션 코스트가 많이 소요됨)
- 운영팀은 이 작업을 위해 하루 약 30분, 한달 중 15시간, 약 이틀의 시간을 소요하고 있었음
- 슬롯이 채워지지 않을 경우, 월별 600~2000만원의 비즈니스 기회를 놓치는 것(연 2억 이상)
- 빈 슬롯을 발견하더라도, 짧은 시간 내에 빈 슬롯을 채우기 위해 수소문 하는 것이 어려움
- 가설
'날짜별로 채워지지 않은 슬롯을 확인하고 그 상태에 맞게 조치를 취하는 것을 개선'한다면 해결될 것이다.
- 해결
1)슬롯의 상태 분류: 예약 확정 전과, 예약 확정으로 나뉨
2) 친숙하도록 캘린더 형태를 취하고, 각 상황을 좌측과 같이 단계별로 정렬함
3) 단순 상태만 보여주는 것이 아닌, 필요한 조치를 취할 수 있게 해줌 (정말 중요하다고 생각한 부분)
4)제안하기 신청으로 바로 제안 상태가 '자동'으로 업데이트 되도록 함
5)화면 내에서 필요한 프로세스를 수행할 수 있도록 개선
- 결과
큰 숲을 바라보는 작은 움직임부터 시작하자!
2.지표가 좋으면 UX도 좋은걸까?
#다크패턴 #정성지표
토스코어 인벤토리팀 디자이너 이영진님
- 문제: 인텔리전스 영역 지표가 좋음에도 불구하고, 사내 제보 시스템 내 VOC가 늘어남
토스의 인텔리전스 영역의 '인텔리전스를 등록하고 관리하는 어드민 제품'을 만들고 있음. 주 사용자는 토스 팀원들임.
어떤 메세지를 어떻게 노출할 것인지에 대해 세팅함. 또 어떤 메세지를 얼마나 많은 유저가 봤는지, 또 유저가 얼마나 많이 봤는지 지표를 볼 수 있음. 당팀에서는 이 지표를 트래킹하고 있음.
하지만 정성적인 지표와 유저 만족도도 계속해서 살펴보고 개선 필요 느낌.
눈에 보이지 않는 영역 가시화에 대한 노력과 꿀팁을 공유함.(브랜드디자인 성과지표에 참고할 수 있을 것 같아 기대된다)
- 가설:
가설A.제품의 자잘한 업데이트 과정에서 VOC가 발생했다
가설B.우연히 특정 시점에 VOC가 몰렸다
가설 B에 대한 검증을 위해 기존 VOC에 날짜를 추가해서 데이터를 확인함
- 검증
일정별 3개월 단위로 2~4월은 기술관련/휴먼에러(오타 등)가 많은 반면,
5~7월은 사용성 관련 VOC가 다수 발견됨. (7월은 50%이상)
- 문제정의
유저들이 인텔리전스를 '광고'라고 느끼기 때문에 '인텔리전스'지표가 높음에도 불구하고, 사용자 불만이 야기됨
→광고가 아닌 문구를 작성함으로서 사용성을 개선하자!
- 검증
사람들이 '광고'라고 느끼는 부분이 어떤 것인지 유저 인터뷰 진행
토스 앱으로 한정X. 유저가 자주 쓰는 금융 앱 화면을 보여달라 하고 그 중 광고라고 생각되는 부분과, 이유 물어봄
[설문결과]
가설: 상단에 뜨는 메세지 자체를 광고로 받아들일 것으로 생각함
- 자신의 상황에 해당하지 않는다고 생각하는 주제는 광고로 판단함
- 후킹한 문구(예시.100만원 당첨)를 광고라고 생각함(진실여부와 상관없이)
- 생각보다 빠르게 광고 여부를 판단함
- 확실함을 중요하게 생각함: 클릭 시 예상되는 화면이 아니면 낚시라고 생각함 (예시. 누르면 100원을 준다는 팝업 -> 50원을 주면 광고, 100원을 즉각적으로 보상하면 혜택이라고 생각함)
- 경험해보지 못해 상상할 수 없는 내용(예시. 스마트폰 요금제 중 실제 3만원대 알뜰요금제가 있음에도 존재를 몰라 낚시성 광고로 판단함)
- 광고를 경험한 유저는 그 이후는 해당 영역을 광고로 인식하는 문제가 발생함
→ 그렇기 때문에 유저가 기대하는 내용이 나올 수 있도록 정직하고 친절한 문구를 쓰는 것이 중요함
- 해결
인텔리전스 어드민을 쓰는 팀원들은 디자이너가 아닌 경우가 대부분이기 때문에 유저 경험에 대한 이해도가 조금 낮아, 감정 이입도 어려워함. 이를 보완하기 위한 장치들 마련
1.사례들을 모아 가이드라인 제작
2.UX라이팅팀에서 보았을 때에 문구가 정직하고 클릭율이 높았던 사례를 모아 템플릿으로 제공
3. 광고문법 검사기능 추가. 다크패턴 감별기
4.유저 만족도와 정성 평가 공유 대시보드 기획 중
만족도 점수가 떨어지게 한 선택지가 무엇인지
유저군이 적절하게 세팅되어있는지, 유저가 이해하기 쉬운 문장으로 작성되었는지
문구를 눌렀을 때 나오는 내용이 이어지는지 이런 것들을 팀원 개개인이 직접 점검할 수 있음
→이를 반영해서 유저에게 더 유용하고 좋은 정보를 제공 기대
B2C와 달리 B2B 영역은 긴 호흡을 가지고 갈 수밖에 없지만,
일단 문제를 파악하면 어떻게든 해결할 수 있으니 지치지 말자
3.100%자동화, 정말 좋은걸까?
#사기대응 #자동화
Product Designer(Tools) 한세희님
보이스피싱 사기로 잃어버린 돈을 피해자에게 돌려드리기 위한 은행업무 자동화 경험
- 문제: 송금내역 선택하는 것이 어렵고, 요청서 송부 과정도 복잡함. 시간이 많이 소요됨.
1. 지급정지 요청할 건들에 대해 선별 필요
2.지급정지 요청서를 돈을 받은 계좌별로 따로 작성해야 함
3.지급정지 요청서와 별개로, 타 서류들(피해자 신분증, 피해구제 신청서)를 합쳐서 하나의 파일로 만들어야 함
4.전체 프로세스를 돈을 보낸 계좌 수만큼 반복해야 함
사기꾼이 이미 돈을 빼돌린 경우, 돈을 받은 계좌 은행에 지급정지 요청서를 통해 요청함
타행 지급정지 시 필요한 정보
- 송금내역 중 어떤 것을 지급정지 해야할지 송금내역을 찾아야 함
- 사기와 관련있다 싶은 거래내역만 골라서 지급정지를 해야함
그리고 사기꾼이 돈을 송금한 계좌별 따로따로 지급정지요청서를 보내야 함
[프로세스]
고객에게 지급정지 요청 수신 → 지급정지할 건들 선별 → 지급정지 요청서 작성(피해자 신분증, 피해구제 신청서 서류 함께 송부)→ 틀린 것이 없는지 확인 → 팩스로 송부
- 가설: 직무역량이 필요 없는 단순반복 작업에서 휴먼에러를 줄여 효율을 개선하기
[자동화 시킬 수 있는 부분으로 가정한 것]
1)지급 정지 요청서를 '보내기': 파일을 합치고 팩스로 보내는 업무들은 단순업무라고 생각했기 때문(트리거, 조건, 동작이 명확했기 때문)
2)계좌번호끼리 분류하기: 사기와 관련있는 내역 중 동일한 계좌번호끼리 묶기
3)거래내역 선택하기: 사기 내역이 있었던 계좌 발라내는 과정에서 과거 지급정지 기록이 있었던 사례 기록을 적용
4)요청서 확인하기: 휴먼에러가 생길만한 부분을 없앴으니, 생략가능한 것으로 판단
- 검증: 뜻밖에도, 사용자들은 만족하지 못했다...
알아서 처리되었을 때에 수정할 기회가 없기에 불안감이 생긴 것
하지만, 요청서가 맞는지 '확인'하면 기존 프로세스와 달라질 것이 없었기에 불안해하는 이유에 대해 더 인터뷰를 해보았더니
사기와 관련된 송금 내역 데이터가 사람이 선택했던 내역이기 때문에 휴먼에러가 있을까봐 불안함.(자동화에 적용한 데이터 자체에 대한 신뢰 부족)
신고 당시에는 빠른 처리가 중요했지만, 요청서로 정식 요청시에는 정확함이 중요하기에 한번 더 확인하고 싶었던 것.
- 해결
'자동으로 만들어진 요청서' 확인 → '선택한 거래 내역' 확인하는 것으로 수정
아래 세가지 단계를 자동화함
- 분류: 직접 계좌별로 분류
- 찾기: 최초 일시를 찾기
- 계산: 합계 금액 계산하기
처음엔 어렵고 복잡한 과정을 보여주어야하나 고민했는데, 이 부분이 실수였음.
이 업무 담당자분들은 이 업무에 정말 굉장한 책임감을 가지고 있기 때문에 아무리 복잡하더라도 이걸 명확하게 인지할 수 있어야 버튼을 안심하고 누를 수 있었던 것.
→ 어쩌다 한 번씩 쓰는 툴과, 매일 쓰는 주업무용 툴은 다르게 접근해야한다는 인사이트를 얻음
→ 빠르고 심플해도 사용자를 불안하게 하면 정답이 아니다
- 결과
기존 요청서 1개 작성시간 4분 이상 → 40초로 단축(요청서 수가 아무리 많아도 2~3분이면 종료)
자동화를 하다보면 효율성 고도화를 주 목표로 삼지만,
사용자가 제품을 신뢰하고 안정감있게 사용하는 것이 중요
4.아무도 눈치채지 못한 문제까지 해결해야 할까?
#고객센터 #워크플로우개선
토스뱅크 상담 플랫폼팀 박성경님
챗봇이나 채팅 어드민과 같이 여러 맥락의 상담 제품을 디자인
365일 24시간동안 상담. 고객 상태 확인 및 문제 해결을 돕는 어드민을 제작 중.
핼프데스크(토스뱅크 사용 문의)를 개선한 내용
- 문제:
다양한 토스뱅크 상품을 이해해야하는데, 상담 단말, DIG, 통합 단말등 흩어진 기능을 하나로 아우르는 새로운 상담 툴을 만드는 것
상담원들에게 너무 익숙한 제품이라서 뚜렷한 문제점 찾기 어려움
인터뷰보다 객관적 관찰하는 방법이 낫겠다 판단 → 반복적인 비효율 지점 발견
레거시 제품에 대해 오히려 뉴비의 시선으로 보니, 새로운 시각으로 발견할 수 있었음
착오 송금 업무 수행 시, 접수 및 연락하는 역할을 상담원분들이 직접 처리하고 있었음.
접수 시 필수 정보: ①어떤 계좌 ②누구에게 ③얼마를 잘못 보냈는지
이 정보에 불필요한 정보들이 섞여있어, 처리 및 상담하는 시간이 오래 걸리는 것이 문제
- 검증
그렇다면 접수할 이 3개 내역만 있어도 착오 송금 접수에 전혀 문제가 없는지 검증이 필요했음
→ 트랜스퍼 스쿼드 개발자분들에게 방문해서 QnA 진행
[착오송금 내역 특징]
1) 해당 통장에서 '내'가 사용한 출금 내역일 것
2) 다른 '사람'에게 보낸 돈일 것
3) 예금이나 적금 통장은 송금할 수 없으니 제외
4) 통장에 연결된 '나의 다른 계좌'로 옮긴 내역 제거
- 가설: 착오 송금과 관련한 상담에 불필요한 정보를 제거하면 업무 속도가 빨라지지 않을까?
기존 전체 거래 내역이 아닌 '착오 송금'만을 위한 화면 제작
여기에서 끝난 것이 아니라, 검색 및 필터 기능을 추가해서 더 편하게 사용하게 해드리고 싶어서
고객센터로 전화하는 분들의 대화에 힌트를 얻어 착오송금 접수 시 필수 정보를 필터에 추가함
- 결과: 상담시간을 건당 70초 절약, 월 525분 세이브
근데 워크플로우를 그려보다보지 상담을 접수하는 것만으로 착오 송금이 해결된 것이 아니라, 고객이 돈을 돌려받는 것 까지가 해당 업무의 끝이라는 사실을 발견. 또 접수 이후에 돈을 돌려드리는 일이 훨씬 앞의 전화상담 시간보다 훨씬 많이 걸림.
기존 상담 제품은 통화 중에 이루어지는 효율을 높이는데 집중했다면 사용자 관점에서 겪을 불편함을 끝까지 따라가서 모두 개선해보고자 함.
문제1 착오 송금건 해결을 위해 상담원이 여러개의 화면을 봐야 함.
- 이유: 거래 제한냐, 기해지 계좌냐에 따른 업무 방법이 다르기 때문.
심지어 여러 사람이 순차적으로 진행하는데, 이전 진행과정을 보기 위해 모달을 열고 변경 버튼을 눌러 처리하는 등 많은 화면을 오가는 불편함이 있었음.
문제2 총 1개의 접수건을 처리하기 위해 4~5번의 화면을 왔다갔다 하는 것
하지만 유저들은 몇가지 꼬리 질문에도 불구하고 기존 방식에 익숙해져있었음. 동선이 조금 불편하지만 보아야할 정보는 모두 확인할 수만 있다면 괜찮다는 입장.
- 가설: 여기저기 흩어진 정보들을 사용자가 작업 중인 화면 하나에, 업무 방식에 맞춰 정보를 재구성하면 효율이 높아지지 않을까?
- 결과: 흩어져있던 정보는 잘 보였고, 다음 내역을 보기에도 용이해짐.
문제3 업무 패턴을 반영하지 못한 제품의 정보 구조
이유: 진행이력 때문(진행 흐름이 잘 드러나는 것이 중요한데 반영하지 못함)
- 상담 이력이나 실제로 전화로 주고받은 메모가 따로 떨어져있어 불편함
- 하나의 메모를 여러 사람이 기록하고 있음
- 전체 흐름을 한눈에 보기 어려운 UI
- 해결
- 히스토리 패널을 제작하여 통화일시와 통화중 기록 남김
- 이력을 추가하거나 접수를 처리하는 액션도 히스토리에 실시간 반영되어 편리함
- 결과
상담원 5명 2,100건 처리 → 동일 시간 내 5,800건 처리 가능(효율 2.5배 개선)
디자이너는 유저에게 잘 공감해야하는데 상황에 대해 받아들이는 것이 달랐기 때문에 고민이 많았음.
직감을 믿고, 당연하다고 말하는 유저의 말에 그렇구나 넘어가지 않고, 집요하게 문제를 파고들다보면 확신이 생긴다. 제품이 생긴지 오래되었거나, 혹은 매일 이 업무만 하는 사람이라면 불편에 쉽게 익숙해지는 것 같다. 문제를 해결해야하는 디자이너니까 왜 이렇게 해야하는지 이해가 되지 않을때, 나라면 너무 불편할 것 같을 때 이 직감을 믿어보자!