토스로 보는 일관적인 UI·UX와 데이터의 중요성
데이터에 기반한 UI·UX 디자인 검증과 보완
잘 나가는 서비스라고 해서 UX까지 완벽한 건 아니죠? 현직 UI·UX 디자이너이자 기획자인 데이지 인사이터가 각종 서비스 디자인을 꼼꼼하게 분석했습니다. 철저히 사용자 관점에서 논리 구조 단까지 깊숙이 파헤친 뒤 개선 방안까지 제안합니다.
※ 해당 콘텐츠는 지난 2023년 8월 9일 작성된 콘텐츠를 기반으로 재구성됐습니다.
모름지기 UX는 사용자 경험에 기반한 디자인입니다. 사용자가 겪은 같은 경험엔 같은 결과가 나와야 하죠. 그래야 사용자가 제품 서비스를 쉽게 이해하고 처음 보는 제품 서비스여도 빠르게 적응할 수 있습니다. 만일 매번 사용할 때마다 다른 경험을 겪는다면 사용자의 혼란을 야기할 수 있습니다.
대표적으로 전 세계 신호등의 빨간색 신호는 멈춤의 의미, 초록색 신호는 전진의 의미를 가지고 있습니다. 이는 사회적인 약속이기도 하지만 사람들이 학습과 경험을 통해 인지하게 된 사실이기도 합니다. 만약 서울시에선 빨간색 신호에 멈춰야 하지만 경기도에선 초록색 신호에서 멈춰야 한다면 대혼란이 벌어질 겁니다.
UI·UX 디자인에서도 마찬가지입니다. 대표적으로 오른쪽 화살표 버튼(>)은 다음으로 넘어가는 기능의 버튼이며, 왼쪽 화살표 버튼(<)은 이전으로 돌아가는 기능을 나타냅니다. 만약 이를 반대로 제공하는 서비스가 있다면 기존에 다른 서비스에서 경험을 학습한 사용자는 잦은 실수와 함께 매우 큰 불편함을 느끼게 될 겁니다. 이것이 바로 UX에서 일관성이 중요한 이유입니다.
자동으로 설정을 바꿔주는 토스의 ‘송금 한도’
토스 앱에선 송금 한도, ATM 출금 한도, 카드 결제 한도까지 한도 변경과 관련된 총 3가지 항목이 존재합니다. 하지만 한도를 높이는 동일한 기능을 가졌음에도 모두 다른 구조를 취하고 있습니다.
먼저 송금 한도에는 1회 한도와 1일 한도, 더 나아가 1달 한도가 존재합니다. 한도를 변경할 때 1회 한도는 1일 한도를 초과할 수 없으며, 1일 한도 역시 1달 한도를 초과할 수 없습니다. 즉 작은 기한의 한도는 무조건 큰 기한의 한도 이하여야만 하는 겁니다.
토스의 송금 한도 변경 예시
ex) 1회 한도가 50만원이고, 1일 한도가 50만 원일 경우
1-1. 1회 한도를 100만원으로 올리고 싶은 경우엔 먼저 1일 한도를 100만원으로 변경한 이후 1회 한도를 100만원으로 변경한다.
1-2. 1일 한도를 10만원으로 줄여야 하는 경우엔 1회 한도를 10만원으로 변경 후, 다시 1일 한도를 10만원으로 변경한다.
그런데 이런 방법을 따르지 않고, 잘못된 순서로 더 큰 기한의 한도를 변경하려고 하면 어떤 일이 벌어질까요?
의외로 송금 한도 변경 과정의 경우, 1회 송금 금액을 1일 송금 금액보다 높게 입력하면 자동으로 1일 송금 금액까지 상승합니다. 낮추는 경우 역시 마찬가지입니다. 이렇게 사용자는 1회 송금과 1일 송금 금액을 한 번에 손쉽게 변경할 수 있습니다.
직접 다시 돌아가야 하는 토스의 ‘ATM 출금 한도’
반면 ATM 출금 한도 변경 과정은 앞선 송금 한도와 달리 금액 입력 후 입력 금액에 대한 확인 모달이 나옵니다.
또한 1회 송금 금액을 1일 송금 금액보다 높게 입력하면 입력 금액 확인 모달과 비밀번호 입력 과정까지 거친 후 1일 최대 한도를 넘길 수 없다는 안내 팝업이 나옵니다.
이로 인해 사용자는 다시 한도 조정 단계로 돌아가 1회 한도를 올려야 합니다. 앞서 송금 한도의 경우 동일하게 잘못된 순서로 한도를 설정해도 자동으로 바꿔주던 모습과 다른 방법을 제공하고 있는 겁니다.
UX 일관성이 부족한 토스의 한도 조절 구조
정리하자면 토스의 한도 조절 기능은 각기 다른 구조를 갖고 있고, UX 일관성이 부족하다고 볼 수 있습니다. 이처럼 같은 앱에서 제공하는 동일한 기능임에도 구조가 각기 다르면 사용자의 입장에선 어떤 경험이 맞는 건지 혼란에 빠지게 됩니다.
예로 송금 한도에서 자동으로 한도가 조정된 경험을 가진 사용자는 한도가 자동으로 바뀐다는 경험 때문에 다른 종류의 한도 변경에도 같은 경험을 기대하고 동일하게 행동할 겁니다. 하지만 ATM 출금 한도 과정에선 갑자기 안내 팝업에 나타나고 추가적인 행동이 요구됩니다. 일관성이 없는 구조로 불필요한 행동을 한 부정적인 경험을 가지게 되는 겁니다.
실제로 ATM 출금 한도 변경을 시도하는 사용자는 ‘올바른 사용자의 역설’을 겪고 있습니다. 올바른 순서로 한도를 변경한 사용자가 올바르지 않게 한도를 변경한 사용자보다 더 번거로운 과정을 거치고 결국 바르게 사용했는데 더 불편하다는 역설이 생기게 된 겁니다.
뿐만 아니라 이렇게 같은 기능들의 구조가 달라 UX 일관성이 부족하게 되면 인지해야 하는 정보의 양이 많아져 앱에 적응하는 데도 오랜 시간이 걸리게 됩니다.
UI 일관성이 부족한 토스의 한도 조절 구조
또한 토스의 송금 기능은 일부 UI 역시 일관성이 부족합니다. 송금 한도만 유일하게 상단 부분 텍스트가 존재하며, 텍스트 박스의 UI 디자인과 서브문구의 텍스트 사이즈가 다릅니다.
실제 ATM 출금 한도 기능의 경우 한도를 입력했을 때 입력한 금액이 맞는지 확인하는 모달이 존재하지만, 송금 한도에는 입력 금액 확인 모달이 존재하지 않습니다.
또한 송금 한도와 ATM 출금 한도의 경우 윗 항목이 아래 항목보다 더 하위 기한이지만, 결제 한도 변경 시도 시 윗 항목이 아래 항목 보다 상위기한입니다. 이런 일관적이지 않은 버튼 배치 또한 사용자의 경험에 혼란을 제공합니다.
물론 토스 사용자 가운데 모든 종류의 한도 변경을 경험하는 사용자는 많지 않을 겁니다. 하지만 이를 일관성 있는 구조로 변경한다면 사용자 경험에 긍정적인 경험을 줄 수 있을 뿐만 아니라 추후 앱의 유지보수 과정에서도 효율을 꾀할 수 있을 겁니다.
그렇다면 앞선 2가지 한도 타입을 한 가지 공통된 구조로 통일하게 된다면 어떻게 사용자에게 가장 좋은 과정을 도출해낼 수 있을까요? 답은 내부 데이터에 있을지도 모릅니다.
데이터에 기반한 UX① 가설 확인
송금 한도의 한도 자동 과정은 얼핏 보았을 때 매우 편리한 구조로 보입니다. 하지만 이 구조를 토스의 모든 송금 과정에 적용하려면 먼저 두 가지 가설 조건이 성립하는지 알아야 합니다.
첫 번째 가설 조건은 1일 한도보다 높은 금액으로 1회 한도를 높이려는 사람들 중 대부분이 1일 한도를 먼저 조정하지 않은 실수를 한 사람이어야만 하며, 두 번째 가설 조건은 1일 한도를 높이는 사람이 동일한 금액으로 1회 한도를 높일 것이라는 가정입니다. 다행히 이 가설들은 데이터를 토대로 검증하고 판단할 수 있습니다.
첫 번째 가설은 ATM 출금 한도는 앞서 보았듯 1회 한도가 1일 한도를 초과할 수 없기 때문에 1회 한도를 올리려다가 실패해 1일 한도를 올린 사용자의 비율을 조사하면 됩니다. 물론, 과거 송금 한도 변경을 경험해 자동으로 변경될 것이라 예상한 사람이 존재할 수도 있습니다.
그러므로 해당 데이터를 수집할 땐 송금 한도 변경을 경험하지 않은 사람들의 데이터만 수집·분석해야 합니다. 필터링된 데이터에서 실패하고 한도를 올린 사용자의 비율이 높다면 첫 번째 가설 조건이 성립한 겁니다.
두 번째 가설 조건 역시 내부 데이터 상으로 ‘1일 한도를 변경한 후 1회 한도 역시 같은 금액으로 변경한 사람의 수‘가 ‘1일 한도를 변경 한 후 1회 한도를 유지하거나, 1회 한도를 100만원이 아닌 다른 금액으로 변경한 사람 수’보다 작다는 것을 확인할 수 있다면 두 번째 가설 역시 성립시킬 수 있습니다.
데이터에 기반한 UX② 증명
가설 성립 증명이 끝났다면 이제 마지막으로 금액 확인 모달 필요 여부를 확인입니다. 이 역시 데이터를 통해 확인이 가능합니다. 송금, ATM 출금 한도 변경 데이터에서 금액을 변경한 후 즉시 다시 변경한 사람들의 비율을 비교 확인하면 됩니다.
만약 한도 금액을 변경한 후 즉시 다시 변경한 사용자의 비율이 높다면 잘못 입력한 사람들이 많거나, ATM 출금 한도 과정의 확인 모달 효율성이 자동 한도 변경 보다 좋다는 이야기입니다.
반대로 사용자 비율이 비슷하다면 금액을 잘못 입력한 사람들이 극히 적거나 ATM 출금 한도 과정의 확인 모달의 효율성이 떨어진다는 이야기입니다. 때문에 그럴 경우엔 편의성을 위해 모든 과정에서 확인 모달을 삭제하고 단계를 간소화 하는 것이 더 좋은 방향이라 생각합니다.
이처럼 UX 디자인 구조를 설계할 때에는 데이터가 중요합니다. 다만 스타트업처럼 아직 데이터가 충분히 쌓이지 않은 상황에선 디자이너의 가설과 논리가 앞설 수밖에 없습니다. 하지만 그런 스타트업이라고 하더라도 어느 정도 데이터가 쌓이면 실제 데이터를 중요시해야 합니다. 훌륭한 UX 디자이너는 가설과 함께 데이터를 기반으로 자신의 디자인 구조가 옳은지 판단하면서 디자인할 수 있어야 합니다.
? 원문 링크: 토스의 한도변경 UX구조
뉴스콘텐츠는 저작권법 제7조 규정된 단서조항을 제외한 저작물로서 저작권법의 보호대상입니다. 본 기사를 개인블로그 및 홈페이지, 카페 등에 게재(링크)를 원하시는 분은 반드시 기사의 출처(로고)를 붙여주시기 바랍니다. 영리를 목적으로 하지 않더라도 출처 없이 본 기사를 재편집해 올린 해당 미디어에 대해서는 합법적인 절차(지적재산권법)에 따라 그 책임을 묻게 되며, 이에 따른 불이익은 책임지지 않습니다.
- 에디터김동욱 (jkkims@ditoday.com)
