[ 토스 디자인 컨퍼런스 ] Simplicity 21: 2일차 내용 정리

도입

이번 2021년 8월 30일 월요일부터 9월 2일 목요일까지, 4일 동안 토스에서 Simplicity 21이라는 주제로 디자인 컨퍼런스를 진행한다.

아래는 해당 컨퍼런스에서 공개한 영상 내용을 정리하고 관련된 개인 의견을 작성한 글로, 오늘은 2일차 영상 관련 글이다.

 

1일차 영상 관련 글의 경우 아래 URL을 클릭해서 확인해볼 수 있다.

2021.08.30 - [강연 및 컨퍼런스/디자인] - [ 토스 디자인 컨퍼런스 ] Simplicity 21: 1일차 내용 정리

[ 토스 디자인 컨퍼런스 ] Simplicity 21: 1일차 내용 정리

 

전체 시청은 글의 맨 아래 URL에 접속하여 확인할 수 있다.

 

공통적으로 느꼈던 점

2일차 내용의 경우 1일차에 언급했던 <도널드 노먼의 UX 디자인 특강> 속 책 내용, 복잡함을 처리하는 대상의 트레이드 오프에 관한 이야기가 주된 내용이었다.

 

"모든 프로그램에는 더 이상 줄일 수 없는 복잡한 정도, 즉 복잡함의 하한선이 있다. 이때 던져야 할 질문은 이 복잡함을 누가 감당하냐는 것이다. 사용자인가, 이나면 개발자인가?" 기술 분야에서 사용 방식을 단순화하면 내부 시스템의 복잡함은 증가한다.

- <도널드 노먼의 UX 디자인 특강>, 도널드 노먼, 범어디자인연구소, 유엑스리뷰, 2018, p.085.

 

사용자들의 편리한 이용과 경험을 위해 토스 팀에서 어떤 노력을 했는지 엿볼 수 있었다. 단순히 인터페이스를 바꾼다는 개념이 아닌, 상세하게는 말투와 태도(Tone & Manner)부터, 배치 방법, 법적 근거, 엔지니어링적 개선(속도와 같은 효율성 측면)까지 얽혀 있는 여러 이해 관계들을 고려하며 서비스를 개선 시킨 사례에 관해 알 수 있어서 좋았다.

 

특히 관심 있던 UX Writing에 대한 언급이 중간 중간에 나왔는데 9월 2일에 관련 영상이 나온다고 하니 기대해봐야겠다.

 

<불편한 경험 완전히 밀어버리기>

내용 정리

다들 로그인을 할 때 비밀번호를 틀려 본 경험이 한 번씩 있다. 이때 반복적으로 비밀번호를 틀릴 경우 계정이 잠기는 상황이 발생한다. 토스에서도 계좌를 등록할 때 따라야 할 규정이 많아 사용자들 입장에서 복잡할 수 밖에 없었는데, 이 과정을 다 없애버리기로 결정하였고 이를 최소한으로 단순하게 만들었다.

 

우선 가장 복잡한 부분은 은행 홈페이지 비밀번호를 입력하는 경우였다. 사실 비밀번호만 입력할 경우 바로 계좌가 연결되는, 따지고 보면 가장 단순한 기능이었는데 사용률을 분석해보니 실제로는 모두가 포기하는 단계였다. 그래서 세 가지 방향으로 문제를 분석해서 해결책을 고려했다.

 

첫째, 비밀번호 입력을 더 시도할 수 있는 경우다. 이때는 비밀번호를 입력할 수 있는 남은 횟수와 틀린 이유를 함께 보여주고, 모르는 비밀번호를 계속 시도하는 것보다 새로 바꾸는 게 사용자 입장에서도 훨씬 빠른 일처리가 가능하기 때문에 비밀번호 변경을 권유한다. 그런데 비밀번호를 바꾸려고 할 때 지켜야 하는 은행 규정 때문에 복잡해진다. 따라서 만약 오입력했던 비밀번호가 은행 규정에 통과된다면 해당 비밀번호로 바로 바꿀 수 있게, 다시 말해 버튼 클릭 한 번만으로 비밀번호 변경이 가능하게 하였다. 이때 보여주는 문구는 "방금 입력한 비밀번호로 바꿀까요?"이다.

 

둘째, 마지막 시도까지 한 번 남은 경우다. 이때는 "한번 더 비밀번호를 틀리면 로그인이 제한될 수 있어요."와 같은 문구를 활용하여 강력하게 비밀번호를 바꾸라고 제안하였다.

 

셋째, 마지막 시도인 경우다. 이때는 서비스 자체에서 비밀번호를 바꿀 수 있게 연결해주는, 다시 말해 서비스에서 도움을 줄 수 있는 경우와 도움을 줄 수 없는 경우가 존재한다. 후자의 경우 사용자가 직접 은행에 가야하는데 이런 불상사가 최대한 발생하지 않기 위해 전 단계에서의 비밀번호 변경 권유를 강조했고 결국 사용자가 불편할 수 있는 상황을 최대한 예방할 수 있었다.

 

다음으로 처음 만나게 되는 복잡성, 계좌번호 입력 과정을 단순화했다.

 

사용자가 계좌번호를 모를 경우 기존에는 은행 애플리케이션을 열어 확인할 수 있게 유도했는데, 이런 경우 사용자는 필연적으로 해당 애플리케이션에서 다시 로그인 과정을 진행해야 하기 때문에 결국 더 복잡한 과정을 만들게 된다. 따라서 토스에서는 어떤 계좌로 다른 사람에게 돈을 보낸 적 있다면 혹시 해당 계좌가 본인의 계좌가 아닌지 물어보는, 추천 시스템을 개발했다.

 

이 과정에서 동명이인과 같은 문제점으로 본인의 계좌가 아닌 경우에 대한 사용자의 혼란스러움을 예방하기 위해 추천 로직을 고도화하여 우선 순위에 따라 계좌를 추천하였다. 이런 추천 시스템을 통해서 결국 사용자는 토스를 나가지 않고도, 계좌번호를 입력하지 않고도 버튼만 클릭하여 계좌를 연결할 수 있게 되었다.

 

흔히 로그인 기능에서의 사용자 경험(UX)은 어디서나 흔하게 볼 수 있어서 불편하고 어려운 게 당연하다고 생각한다. 그래서 그 복잡함을 사용자에게 떠넘길 때가 많다. 토스는 이러한 고정관념을 없애고, 세상에서 가장 친절한 퍼널(Funnel)을 만들기 위해 노력 중이다.

 

개인적 의견

<도널드 노먼의 UX 디자인 특강>에는 다음과 같은 이야기가 나온다.

 

내가 이 책을 쓰겠다고 마음먹은 가장 큰 이유는 복잡함(Complexity)과 혼란스러움(Complicated)을 명확하게 구분하고 싶었기 때문이다. '복잡함'은 실재(實在)의 상태이고, '혼란스러움'은 마음의 상태다. '복잡함'의 사전적 의미는 많은 부분이 뒤얽히고 서로 연결된 상태를 말한다. 나 역시 이러한 의미로 사용할 것이다. '혼란스러움'은 여기에 부차적으로 어지럽다는 뜻을 더한 것이다.'

- <도널드 노먼의 UX 디자인 특강>, 도널드 노먼, 범어디자인연구소, 유엑스리뷰, 2018, p.018.

 

책에서는 사용자가 그 이유를 받아들일 경우 복잡한 과정을 그대로 따르게 되지만, 만약 그 이유를 받아들이지 못할 경우 이것은 혼란스러움으로 받아들여져 제품을 사용하기 꺼려한다고 이야기한다. 이 맥락에서 알 수 있듯, 복잡함과 혼란스러움의 차이는 필요성에서 발생한다.

 

책에서도 나오는 예시이지만, 우리가 사용 중인 언어는 사실 무척 복잡하다. 단어를 외워야 하고, 문법을 익혀야 하며 관용어와 같은 맥락마다 사용이 다른 여러 가지 문장들에서도 경험을 통해 학습해야 하기 때문이다. 심지어는 똑같은 문장이라도 상황과 어투에 따라 그 의미가 확연히 달라지기도 한다. 이러한 복잡성에도 불구하고 언어를 계속 학습하며 익히는 이유는 실생활 속에 언어가 없다면 소통을 할 수 없기 때문이다. 다시 말해 사용자는 필연적으로, 무의식적으로 그 필요성을 인지하고 있기에 복잡하다고 느끼지 않고 자연스레 학습한다. 그리고 이때 우리가 자연스레 언어를 사용하는 그 과정을 '개념적 모델(conceptual model)'이라 한다.

 

책에서는 개념적 모델을 아래와 같이 정의하고 있다.

 

개념적 모델(conceptual model)이란 무엇이 어떻게 작동하는지에 대한 생각이 머릿속에 근본적으로 구조화된 것을 말한다.

- <도널드 노먼의 UX 디자인 특강>, 도널드 노먼, 범어디자인연구소, 유엑스리뷰, 2018, p.068.

 

로그인의 경우 해당 서비스를 이용하기 위한 필수 절차이기 때문에 사용자는 무의식적으로 가입을 할 때가 많다. 다른 서비스에서도 평균적으로 요구하는 절차가 이미 있고, 이를 경험해 본 사용자라면 자연스레 어떤 절차를 요구할 때 받아들이기 마련이다. 다시 말해 로그인과 관련된 개념적 모델이 이미 존재하고 따라서 이를 자연스럽게 사용자가 수용하는 것이다. 하지만 그 개념적 모델이 과연 자연스러운 것일까?

 

현재 커뮤니티 서비스 프로젝트를 기획하고 개발 중인 상태다. 아직은 프로토타입도 나오지 않은, 단순 아이데이션 상황인데 커뮤니티의 개념적 모델을 깰 수 있는 방법에 관해 고민한 적이 있었다. 우리는 흔히 커뮤니티 서비스를 생각할 때 상단 또는 좌측에 카테고리가 존재하고 해당 카테고리에서 원하는 게시판으로 이동하여 글을 검색하고 조회한다. 이러한 개념적 모델을 깨서 사용자에게 더 단순하면서 긍정적인 경험을 제공할 수 있는 방법으로 소셜 네트워크 서비스(SNS)와 추천 로직을 도입하는 방법을 고려한 적 있었는데, 아직은 해당 아이디어가 더 발전되지 않은 상황이다.

 

어쨌든 중요한 점은 언제나 파괴할 수 있는 기존의 개념적 모델은 존재하며, 이를 결정하고 적용할 때의 그 근거는 데이터여야 한다는 것이다. 토스가 금융이라는 보수적 개념적 모델에서 더 보여줄 혁신은 무엇일지 기대된다.

 

<우리가 귀찮을수록 사용자는 더 편해지니까>

내용 정리

모바일을 통해 카드를 신청하면 편하지만 귀찮을 때가 많다. 그리고 언제나, 어디서나 쉽게 할 수 있다고 느껴지기 때문에 그만큼 조금만 불편한 상황을 마주치더라도 사용자는 이용을 쉽게 포기한다. 반대로 은행에 가서 직접 카드를 신청하는 경우 물리적으로 이동해야 하는 불편함은 있을 수 있지만, 막상 도착하면 훨씬 편하게 신청할 수 있다. 직원이 사용자가 꼭 작성해야 하는 부분만 알려주며 나머지는 대신 해주기 때문이다.

 

토스도 이를 바탕으로 사용자가 반드시 작성해야 하는 부분을 제외하고는 나머지를 알아서 할 수 있게 서비스를 개편했다. 그래야 중간에 포기하는 이탈률(Bounce Rate)이 적게 발생하기 때문이다.

 

UI를 단순화하기 위해 토스는 크게는 비즈니스 정책 자체를 바꿨다. 그리고 이 과정에서 가장 중요했던 건 사용자 경험의 중요성을 팀의 공감대로 이끌어내는 것이었다. 

 

단순화하는 과정 속에서 사용자마다 처한 상황이 다르다는 걸 알게 됐다. 예를 들어 신분증 인증 같은 경우 카메라 촬영을 통해 자동으로 그 내용이 인식되는 게 간단한 기능으로 보이지만 사실은 사용자 입장에서 아무 곳에서나 할 수 있는 활동이 아니기 때문에 복잡한 서비스였다. 그래서 반드시 신분증 인증을 해야하는 사용자에게만 해당 기능을 하게 유도했고, 다른 사용자의 경우 없애버렸다. 사용자 마다 마주하는 서비스를 다 다르게 한 것이다.

 

추가적으로, 현실적으로 금융 서비스이기 때문에 모든 절차를 없앨 수는 없다. 따라서 최소한의 필요한 것들만 남기고 사용자가 마주하게 되는 복잡한 상황 또한 질문의 순서를 바꾸는 등의 방법을 통해 사용자 입장에서 더 단순하게 느낄 수 있게 하였다.

 

노동은 사라지지 않는다. 다만 누가 그것을 해결하는 지에 달려 있다.

 

개인적 의견

영상에서 언급된 다음의 문장들이 인상깊었다.

아이러니하게도 사용자에게 부담이 되는 만큼 만드는 입장에서는 설계도 개발도 엄청 편해진다.
...
케이스를 모두 고려해서 만드는 입장에서는 까다롭지만 이렇게 해야 사용자의 입장을 최대한 덜 수 있다.
....
사용자는 똑같은 질문이라도 건네는 말과 처해진 상황에 따라 받아들이는 태도가 굉장히 달라진다.

 

 

말투와 태도(Tone & Manner) 뿐만 아니라 사용자 분석에 있어서도 각 상황 별로 세세하게 분류하여 서비스를 다양하게 제공할 필요성을 느꼈다. <Data-Driven UX> 책을 읽으면서도 인종, 언어 등 제품을 이용하는 사용자의 세세한 환경까지 전부 고려해서 분류하고 분석해야 한다는 걸 알게 됐는데 이를 실제 사례로 풀어낸 과정을 보게 되어서 좋았다.

 

반응형

 

728x90

 

<완벽한 제품에도 필요한 혁신>

내용 정리

서비스는 자전거와 같다. 조금만 타지 않아도 자전거에는 고이 슬고, 방치했다가는 누가 훔쳐가기 마련이다. 토스 또한 이러한 고민이 있었기에 이미 사용자가 잘 사용 중이던 <간편 송금>을 더 혁신적으로 바꾸기 위해 노력했다.

 

사람들이 돈을 보내는 대상을 크게 아는 사람과 모르는 사람, 이렇게 두 집단으로 구분할 수 있다. 이때 문제는 모르는 사람에게 돈을 보낼 때 발생하는데 사기 등에 대한 부분이 사용자 입장에서 불안하기 때문이다. 그래서 보통 송금하기 전, 다른 애플리케이션을 통해 해당 사용자에 관해 조회를 해본다. 그런데 이 과정이 귀찮기도 하고, 급할 경우 그냥 돈을 보냈다가 사기를 당하는 경우가 발생한다.

 

토스가 이 복잡함을 해결해주기로 했다.그래서 <사기 계좌 조회>라는 기능을 추가하여 보내기 전 돈을 전달 받는 사용자에 관해 알려주기로 했다. 그리고 이를 직관적으로 인지할 수 있게 하기 위해 아래와 같이 세 가지 목적에 집중하였다.

 

1. 무조건 잘 보이게 한다.
2. 신뢰감 있게 한다.
3. 사기 계좌라면 송금을 못하게 한다.

 

이를 달성하기 위해 문구를 바꿨고, 이미지도 화려하게 수정했다. 그런데 더 쉽고 직관적이게, 사용자에게 확실한 신뢰를 줄 수 있게 변경하고 싶었다. 그래서  경찰청과 업무 제휴를 맺고 사용자에게는 단순한 이모티콘과 함께 경찰청에 신고된 횟수를 알려주었다.

 

이와 비슷하게 더 바꿀 수 있는 게 없을지 고민하였고, 늦은 밤 송금할 때 은행 영업 시간이 종료 돼 사용자가 기다려야 하는 상황을 발견했다. 이는 은행끼리 정산을 위해 사용자의 송금을 막는 시간이었는데, 문제는 은행마다 시간이 다 달랐다는 점이고 사용자가 이를 기다려야 할 필요성을 인지하지 못한다는 것이었다.

 

자동 이체 기능을 통해 토스가 은행의 정산 시간이 끝나면 자동으로 송금이 되도록 기능을 변경하였고, 이를 기다리는 동안에도 은행이 잠자고 있는 형태의 아이콘을 통해 재미있는 요소를 넣어 사용자 입장에서 즐거운 경험을 할 수 있게 했다.

 

또다른 예시로 송금 기능의 위치를 바꾸는 시도가 있었다. 2-30% 정도의 사용자들이 송금 기능을 바로 사용하고, 나머지 사용자들은 다른 기능을 탐색하다가 사용하는 경우가 많았다. 그래서 이를 단축시켜주기 위해 송금 기능을 눈에 띄는 곳으로 바꾸려고 시도하였는데 이 과정에서 버튼 하나의 위치 변경이 가져올 파장이 꽤 크기 때문에 고민이 많았다.

 

프로토타입을 만들고 테스트를 진행해보며 실제 사용자들이 버튼의 위치가 바뀌더라도 불편하게 인지하지 않는다는 걸 알게 되었고 그래서 바꾸기로 결정을 하게 됐다. 테스트를 진행하면서 점진적으로 변경해 접근성을 높인 것이다. 추가적으로 송금할 때 기존의 페이지가 중첩되는 방식에서 한 페이지 내에 송금 관련 정보를 전부 입력할 수 있게 바꿔 편의성 또한 높였고 메시지 톤도 그 과정에서 통일 시켰다.

 

잘 쓰고 있는 제품이나 기능을 변화할 때, 이미 성공적인 것을 바꾸려는 시도이기에 실패에 대한 두려움이 있을 수 있다. 이미 사용자들이 충분히 잘 사용하고 있기 때문에 변화의 필요성을 크게 느끼지 못하는 것이다. 하지만 이때가 가장 위험한 순간이다. 제품의 본질을 놓칠 수 있기 때문이다.

 

이러한 맥락에서 서비스란 결국 사용자 필요의 변화에 따라 함께 변화해야 하는 것이다.

 

 

개인적 의견

디자인 개념에서 사용자에게 어떤 행동을 유발하는 표시를 어포던스(Affordance)라 한다. 잘못된 어포던스를 사용할 경우 사용자는 더 혼란스러울 때가 많은데, 이를 테면 위 사례에서 <사기 계좌 조회>에 대한 경고를 할 때 불필요한 긴 문장으로 서술하는 경우를 들 수 있다.

 

"해당 계좌는 2018년 12월 사기 행위로 발각되어 신고 된 계좌입니다." 와 같은 신고 내역을 불필요하게 많이 보여준다거나, 아니면 보수적인 톤앤 매너를 사용하는 경우가 나쁜 예시라고 할 수 있다. 사용자 입장에서는 본질적으로 돈을 보내도 괜찮은지 여부만 궁금하기 때문이다.

 

이를 수정한 과정이 영상의 핵심 내용이라고 생각하는데, 톤앤 매너를 변경한 것뿐만 아니라 더 나아가 아이콘과 경찰청 신고 횟수를 통해 아주 직관적으로 사용자가 판단할 수 있게 도왔다. 불필요한 정보를 제거하고 사용자 입장에서 필요한 것만 단순하게 제공한 것이다.

 

어떤 기능을 개발하거나 개선할 때면 불필요한 기능들이 추가되는 경우가 많다. 제작하는 입장에서는 더 많은 기능을 추가해야 사용자 입장에서 좋을 것이라는, 전문성에 대한 욕심이 생기기 때문이다. 본질을 놓치면 사용자는 떠난다는 점을 잊지 말아야겠다.

 

<대출, 새로고침>

내용 정리

대출은 사실 본인의 소득과 빌리고 싶은 금액만 있으면 되는데 사용자 입장에서 반려 때문에 심리적으로 불안할 때가 많다. 그런데 이때의 불안은 사실 사용자 입장에서 불필요한 소비이다.

 

토스에서는 대출 관련 기능이 크게 두 가지가 있었다. 대출 종류를 조회 및 비교해볼 수 있는 서비스와 대출 상품을 카테고리 별로 나누어 확인할 수 있는 서비스다. 그런데 두 제품의 차이점을 사용자는 제대로 인지하지 못 하고 있었다. 더 문제가 되었던 부분은 토스 팀 조차도 이미 해당 서비스가 꾸준히 성과를 내고 있었기 때문에 문제 의식이 없었다는 점이다.

 

두 개의 서비스를 하나의 서비스로 통합하려고 할 때, 그 변화에 대한 가설을 검증하기 위해 구성원들의 공감을 얻어야 했는데 이 과정이 쉽지가 않았다. 그래서 토스 사용자의 5%에게만 테스트를 진행하며, 이 과정에서 '대출 받기'라는 두 메뉴를 통합했을 때 가장 적절한 이름도 선정하였다.

 

인터페이스 또한 위-아래 분류를 통해 어떤 곳에 기존 두 기능들을 배치할 것인지 고민하며 픽셀 단위 비율까지도 세세하게 조정하였다. 이 과정에서 스크롤을 통한 확인을 제공할 것인지, 아니면 버튼 클릭을 통한 확인을 제공할 것인지 고민하였고 심지어 문구까지도 세세하게 고민하였다. 그리고 결국 테스트를 통해 가장 조화로운 결과물을 도출할 수 있었다.

 

이에 대한 성과로 사용자는 통합된 기능을 통해 기존의 두 서비스를 헷갈리지 않게 되었고 이전보다 성장률을 더 빠르고 가팔랐다. 그리고 팀원들에게도 이러한 성과 공유를 통해 공감과 신뢰를 획득할 수 있었다.

 

다른 문제점으로는 대출을 받는 동안 사용자가 꽤 긴 시간 동안 대기해야 한다는 점이었다. 은행이랑 연결하는 시간이 오래 걸렸기 때문이다. 하지만 이것 또한 사용자가 굳이 기다려야 할 이유가 없는 부분이었고, 이를 해결하기 위해 애플리케이션을 꺼도 괜찮게 만들었다.

 

대출 신청을 하자마자 기다릴 필요가 없다는 점을 인지시키기 위해 우선 첫 화면으로 돌아오게 하였고, 모션 그래픽을 생동감 있게 바꾸며 문구 또한 지속적으로 변경되게 하여 기다리는 시간을 지루하지 않게 만들었다. 더욱이 알림을 통해서 결과를 알려주는 방식으로 애플리케이션 내에서 기다릴 필요가 없게 하였고, 이때 푸쉬 문구로 "7분 만에 31개 은행에 다녀왔어요!" 같은 톤앤 매너를 사용하여 사용자 입장에서 기다린 시간에 대해 긍정적으로 받아들일 수 있게 하였다.

 

추가적인 사항으로는 이러한 대기 시간이 개발자 입장에서 길다고 판단되었고 리팩토링을 통해 코드를 개선하여 최대 7분이 소요되던 대기 시간을 45초 내외로 개선할 수 있었다.

 

개인적 의견

토스에서 근무 중인 김강령 UX Writer 분의 인터뷰가 생각났다. 해당 인터뷰의 자세한 내용은 아래 글을 통해 확인할 수 있다.

 

책 <마이크로 카피>에는 다음과 같은 문장이 나온다.

 

제품과 서비스가 소비자와 만나는 접점에는 언어가 있다. 모바일 앱의 버튼에서부터 윈도우의 에러 창까지, 그 내용은 단어와 문장으로 구성된다. 이러한 '말'은 태생적으로 '말하는 자'의 캐릭터를 담는다. 소비자는 여러 메시지를 접하면서 메시지 주체에 대한 이미지를 그려간다. 이것을 페르소나(Persona)라고 한다.

- <마이크로 카피>, 킨너렛 이프라, 변상희, 에이콘, 2021, p.005.

 

토스는 기존 보수적이고 어렵게 느껴지던 금융을 톤앤 매너를 적절히 활용해서 사용자에게 가깝고 편하게 느껴지게 하였다. 이를 통해 사용자가 토스를 자연스럽고 쉽게 사용할 수 있는 금융 서비스라 떠올리게 되고, 기존 어렵게 느껴지던 금융 문제를 해결해야 할 때 더더욱 토스를 이용하게 될 수 밖에 없다. 

 

제품을 만들 때 쉽게 간과하는 사실 중 하나는 사용자가 제품에서 직접적으로 마주하는 게 바로 '언어'라는 점이다. 서비스를 기획하고 만들 때 긍정적인 사용자 경험을 위해 인터페이스, 기능적 구현 등을 고려하게 되지만 실은 사용자가 직접적으로 서비스와 대화(Communication)하는 방식은 결국 언어를 통해서다. 따라서 어떤 문장 구조와 단어를 선택했는지에 따라 제품에 대한 사용자 인식 자체가 달라지고 이는 곧 차별화된 브랜딩을 의미한다.

 

UX 글쓰기와 관련해서는 마지막 날인 9월 2일에 하나의 영상으로 준비되어 있다고 하니 그때 더 자세히 살펴봐야겠다. 

 

https://blog.toss.im/article/uxwriter-interview

토스가 금융을 더 쉽게 만드는 또 하나의 방법, UX Writing

 

 

<1,000만 명의 홈 개편하기>

내용 정리

토스를 이용하는 사용자가 많아지고, 더 다양한 기능들이 추가되면서 홈 기능이 그만큼 복잡해졌다. 그래서 홈 화면을 단순하게 변경해야겠다고 결정했는데 사용자마다 패턴이 다 달라 이를 쉽게 바꿀 수가 없었다.

 

최상의 사용자 경험을 위해 우선 많이 쓰는 사용자 패턴을 분석하여 그룹화하였다. 예를 들어, 기존의 계좌 목록이 아무렇게 뒤섞여 있어서 사용자 입장에서 지저분하게 보던 UI를 카테고리를 지정하고 분류하여 단순하게 확인할 수 있게 바꾸었다. 또한 이전에는 각 계좌별 정보와 관련된 상세 내역을 불러올 수 없었기에 사용자가 마주하는 화면이 부정적이었는데, 토스 애플리케이션 내에서도 볼 수 있게 기능을 개선하였다.

 

다음으로는 필요 없는 것들을 삭제했다. 이를 위해 <토스 머니>라는 기존의 고정적으로 존재하던 토스의 대표 기능을 제거했다. 사용자는 돈을 입금 받을 때 <토스 머니>를 거쳐 본인의 계좌로 돈을 받고 있었는데, <토스 머니>를 삭제하고 바로 본인의 계좌로 받을 수 있게 변경하였다. <토스 머니>는 사실 초기부터 존재하던 오래된 시스템이었기에 엮여 있는 시스템들이 많았고, 각 시스템 별 담당자들과 조율해야 하는 부분이 많았다. 사용자 입장에서도 <토스 머니>를 잘 쓰던 사용자들은 갑자기 사라질 경우 당황스러울 게 뻔했기에 사용자 별로 상황을 전부 분석해서, 다시 말해 다양한 경우의 수를 고려해 <토스 머니> 기능이 정말로 필요한 사용자에게만 보여질 수 있게 하였다.

 

끝으로 부족한 부분을 추가했다. 생일, 관리비 지급일 등 중요한 순간(Moment)을 토스가 알려줘야 할 필요성을 느꼈고, 사용자가 더 다채로운 경험을 할 수 있게 분석했다. 토스에서는 타 부서의 데이터가 모두 열려 있어, 이를 확인하고 분석해서 더 다양한 모먼트를 만들 수 있었다.

 

개인적 의견

애자일(Agile) 조직을 운영할 때 가장 많이 강조되는 부분 중 하나는 바로 정보의 투명성이다. 조직의 적폐라 할 수 있는 사일로(Silo)를 없애기 위해서라도 정보의 투명성은 무척 중요한데, 토스에서는 정보가 투명하게 공유되어 타 팀에서 이를 참조하여 더 획기적인 변화를 시도할 수 있는 것 같다.

 

또한 중요한 점은 팀에 공통된 언어가 있다는 점이다. 개발자와 기획자, 디자이너와 같이 서로 일하는 분야가 다른 직군들끼리 동일한 프로젝트에 대해 소통을 할 때 무엇보다 모두가 이해할 수 있는 공용어, 다시 말해 기준이 존재해야 한다는 점이다. 보통 이것을 사용자 경험을 기준으로 삼아 대화를 하고, 기능을 기획하고 개선해나가는 데 조금 더 구체적으로 정해보면 데이터가 될 수 있다.

 

데이터는 누구나 수집하고, 누구나 사용한다. 기획자 또한 대시보드나 유저 리서치를 통해 데이터를 수집하고 사용하며 디자이너 또한 UX 리서치, 뷰저블(Beusable)과 같은 비주얼 분석 도구 등을 통해서 데이터를 수집하고 분석한다. 더욱이 개발자도 로그를 수집하는 등 데이터를 적극 활용하기에 결국 사용자 경험이라는 거시적 공동 목표에 데이터라는 언어를 통하여 소통할 수 있다.

 

팀 내의 데이터를 통한 원활한 소통 뿐 아니라 다른 팀과도 데이터를 통한 원활한 소통을 한다는 점이 지금의 혁신을 만들어낸 것 같다.

 

---

Simplicity 21

https://toss.im/simplicity-21

토스 디자인 컨퍼런스 Simplicity