[UXUI] 토스의 한도변경 UX구조
일관성 있는 UX 설계와 데이터를 통한 모델 검증방법
UX의 일관성과 데이터에 관해: 토스 앱을 중심으로
UX는 사용자의 경험에 기반한다. 사용자가 겪은 같은 경험에는 같은 결과가 나와야 한다. 그래야 쉽게 프로덕트를 이해하고 처음 보는 서비스나 제품이어도 빠르게 적응할 수 있다. 그렇지 않다면 사용자에게 혼란을 야기할 수 있다.
전 세계의 신호등은 빨간불은 멈춤의 의미, 초록불은 진행의 의미로 사용되고 있다. 이는 사회적 약속이기도 하지만 사람들이 학습과 경험을 통해 인지하게 된 사실이다. 만약 서울시에서는 신호등이 빨간불일 때 멈춰야 하지만, 경기도에서는 신호등이 초록불일 때 멈춰야 한다면 대 혼란이 올 것이다. 통상적인 화면 디자인에서는 오른쪽 버튼(>)은 다음으로 넘어가 기능이며, 왼쪽 버튼(<)은 이전으로 돌아가는 기능을 나타낸다. 만약 이를 반대로 제공하는 서비스가 있다면 이는 기존에 다른 서비스에서 경험을 통해 학습된 유저들은 잦은 실수와 함께 매우 큰 불편함을 초래할 것이다. 이처럼 UX일관성은 사용편의성과 연관된 매우 중요한 요소이다.
토스앱에서는 한도 변경과 관련된 총 3가지의 항목이 있다. 송금한도, ATM인출 한도, 카드 결제 한도. 이는 다시 1회 한도와 1일 한도 or 1일 한도와 한 달 한도로 2가지로 분류된다. 하지만 한도를 상향한다는 동일한 기능을 가졌음에도 모두 다른 구조를 취하고 있다.
송금
송금 한도 변경 플로우는 다음과 같다.
토스의 송금 한도 변경 주요 화면한도에는 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 한도 변경 플로우는 다음과 같다.
토스의 ATM 한도 변경 주요 화면ATM 한도 변경 플로우에서는 송금 한도 변경과 달리 금액 입력 후 입력 금액에 대한 확인 모달이 나오게 된다.
잘못된 ATM 한도 변경의 플로우
ATM 한도 변경의 경우 1회 송금 금액을 1일 송금 금액보다 높게 입력하게 되면 입력 금액 확인 모달과 비밀번호 입력까지 지난 후 1일 최대한도를 넘을 수 없다며 안내 팝업이 나오게 된다. 이러한 경우 유저는 다시금 1일 한도로 돌아가 한도를 올린 후 1회 한도를 올려야 한다. 잘못된 순서임에도 자동으로 두 한도를 바꿔주던 송금 한도와 다른 방법을 제공하고 있다.
카드 결제
카드 결제 한도 변경 플로우는 다음과 같다.
카드 결제 한도 변경은 처음 한도 변경 페이지에 들어가기 전 한도 안내 모달이 한번 나온 이후 ATM 한도 변경과 동일한 플로우를 거친다.
잘못된 카드 결제 한도 변경의 플로우
카드 결제 한도 변경의 경우 1회 송금 금액을 1일 송금 금액보다 높게 입력하게 되면 오류 컬러와 함께 안내 메시지가 나온다. 버튼 역시 비활성화되며 더 이상의 진행이 불가능해진다.
정리하자면 송금 구조에서 다음과 같은 3가지 부분에서 UX의 일관성이 없다.
1) 하위 개념의 금액이 상위 개념의 금액을 초과할 수 있는가
각자 다른 안내 구조를 취하고 있다.잘못된 순서로 변경을 하고자 할 때 나오는 UX가 각 한도별로 다른 구조가 갖고 있다. 이처럼 동일한 기능을 같은 앱에서 제공하는데 방식이 모두 다르다면 사용자 입장에서는 어떤 경험이 맞는 건지 혼란이 오게 된다.
송금 한도를 1일 한도를 초과하는 금액으로 1일 한도를 올린 경험을 가진 경험의 사용자는 금액이 자동으로 바뀐다는 것을 경험하였기 때문에 다른 한도 변경 시 이와 같다고 느낄 것이고 동일하게 행동할 것이다.
하지만 ATM 한도 역시 동일하게 1회 한도를 통해 높이려고 할 때 마지막에 나오는 안내 팝업에 당황할 것이고, 뒤돌아가서 다시 1달 한도 선택하여 변경하러 갈 것이다. 즉 유저는 일관성이 없는 구조로 같은 경험이지만 다른 결과가 나와 불필요한 행동을 취하게 되는 부정적인 경험을 하게 되는 것이다.
뿐만 아니라 해당 구조에 적응하는데 오랜 시간이 걸리게 된다. 같은 경험을 하게 되면 '한도 변경은 이런 구조구나'에서 'a한도변경은 a구조를 b한도 변경에서는 b구조를, c한도 변경에서는 c구조를 가지고 있구나'와 같이 인지해야 하는 정보의 양이 많아지게 되며 해당 구조에 적응하는데 오랜 시간이 걸리게 된다.
부가적으로 UI 역시 일관성이 없다. 송금한도만 유일하게 상단 부분 텍스트가 존재하며 텍스트 박스의 UI디자인과 서브문구의 텍스트 사이즈도 다르다.
2) 금액을 입력하였을 시, 변경할 금액을 올바르게 입력하였는지 안내를 하는가
ATM과 카드 결제 한도를 입력하였을 때 입력한 금액이 맞는지 확인하는 모달이 존재하지만 송금 한도는 입력 금액 확인 모달이 존재하지 않는다.
3) 한도 목록의 순서에서 일관성을 찾아볼 수 없다.
송금과 ATM은 아래 항목이 위에 항목이 더 하위의 개념이다. 하지만 결제 한도 변경에서는 아래 항목이 위의 항목보다 상위의 개념이다. 이 일관적이지 않는 순서 역시 사용자의 경험에 혼란을 주게 된다.
물론 토스의 전체 이용가중에 3가지의 모든 타입의 한도 변경을 사용하고 경험하는 유저는 많지 않을 것이다. 하지만 이를 일관성 있는 구조로 변경하게 된다면 사용자의 경험에 긍정적인 영향을 줄 뿐만 아니라, 추후 앱의 유지 보수과정에서도 한 번의 작업 수정으로 작업 역시 수월해진다.
그럼 저 3가지 타입을 한 가지의 공통된 구조로 통일을 하게 된다면 어떤 플로우가 유저에게 가장 좋은 플로우 일까? 답은 내부 데이터에 의해 정해질 수 있다.
데이터에 기반한 UX
송금의 플로우
1회 한도를 변경함으로써 1일 한도 역시 자동으로 변경되는 이 구조는 얼핏 보았을 때 사용자 입장에서 매우 편리한 구조로 보인다. 하지만 이 구조에서는 3가지를 고려하고 확인해야 한다.
첫 번째는 올바른 사용자의 역설이다. 올바른 순서로 한도를 변경하는 사용자의 경우 1일 한도를 변경 후 1회 한도를 변경하게 된다. 이러한 방법 및 순서는 올바르지 않게 사용한 사용자보다 상대적으로 더 번거롭다. 바르게 사용하였는데 더 불편하다는 역설이 생기게 된다.
잘못된 방법으로 1회, 1일 송금 한도를 변경하는 플로우
올바른 방법으로 1회, 1일 송금 한도를 변경하는 플로우두 번째는 두 가지 가설이 성립되어야 이 구조가 성립된다는 것이다. 1회 한도를 변경하면서 1일 한도도 같이 변경할 수 있게 해 주는 데에는 다음과 같은 가설이 성립되어야 한다.
1) 1일 한도보다 높은 금액으로 1회 한도를 올리는 사람은 1일 한도를 먼저 올려야 하는데 잘 못 들어온 사람이다.
2) 1일 한도를 높이는 사람은 동일한 금액으로 1회 한도를 높일 것이다.
이러한 가설은 데이터를 토대로 판단할 수 있다.
1)의 경우는 ATM 한도와 카드 결제 한도의 데이터에서 찾을 수 있다. ATM 한도와 카드 결제 한도는 더 큰 개념의 한도를 초과하여 변경이 불가능하다. 즉 이 두 구조에서 작은 개념의 한도를 올리려다가 실패하여 큰 개념의 한도를 올린 유저의 비율을 조사하면 된다. 단 송금 한도 변경을 경험하여 자동으로 변경이 되겠지 하면서 잘 못 들어오지 않은 사람이 있을 수 있다. 그러므로 해당 데이터를 뽑을 때 송금 한도 변경을 경험하지 않은 사람들로 필터링을 해야 한다. 필터링된 데이터에서 뽑은 결과값의 비율이 높다면 1)의 가설이 성립된다.
2)의 경우는 내부 데이터상으로 1일 최대한도를 A에서 A+B로 바꾼 유저가 1회 최대한도를 동일한 A+B금액으로 바꾼 수와 그렇지 않은 경우의 수를 비교해서 실효성을 검증할 수 있다.
ex) 1회 한도 50만 원 1일 한도 50만 원 일 때
1일 한도 100만 원으로 변경 후 1회 한도를 100만 원으로 변경한 사람 수 A
1일 한도 100만 원으로 변경 후 1회 한도를 유지 혹은 100만 원이 아닌 다른 금액으로 변경한 사람 수 B
A에 비해 B가에 비해 작다면 2)의 가설이 성립된다.
마지막 세 번째는 금액 확인 모달이 필요한지 여부이다.
송금, ATM, 카드 결제 한도 변경의 데이터를 비교하였을 때, 금액을 변경 후 즉시 다시 변경한 사람들의 비울이 얼마나 되는지를 알아야 한다. 송금에서만 해당 비율이 높다면 잘 못 입력하는 사람들이 많거나, 모달의 효율성이 좋다는 것이며, 세 데이터가 모두 비슷하다면 금액을 잘 못 입력한 사람들은 극히 적거나 모달의 효용성이 떨어진다는 사실을 도출할 수 있기 때문에 편의성을 위해 모든 플로우에서 모달을 삭제하고 단계를 간소화하는 것이 더 좋은 방향이라 생각한다. 다만 카드 결제 한도의 경우 모달에서 금액 확인뿐만 아니라 다른 정보 제공도 같이 하기 때문에, 이러한 내용은 전 화면에 넣을 수 없다면 모달이 있어야 한다.
ATM의 구조
ATM의 경우 인출금액 확인 및 비밀번호 입력까지 하고 난 뒤 사용자는 본인의 잘못한 점을 알게 된다. 입력 금액 확인 모달과 비밀번호 입력은 유저에게 불필요한 경험임으로 좋지 않은 구조라 생각한다.
카드 결제 한도의 구조
카드 결제의 경우 잘못된 순서로 진행할 때 더 이상 진행이 불가능하게 만듦으로써 ATM과 같이 불필요한 경험을 겪지 않게 하여 상대적으로 더 좋은 구조라 생각한다. 하지만 이 역시 되돌아가야 하며 잘못된 방법에서 정상적인 방법으로 넘어가는데 많은 플로우를 거쳐야 한다.
이때 상대적으로 송금 한도의 플로우가 더 간편하기 때문에 송금 한도의 가설입증이 된다면 송금한도의 구조를 가져가는 것이 더 좋을 거라 생각한다.
UX디자인 구조를 설계할 때 스타트업과 같이 아직 데이터가 충분히 쌓이지 않은 상황에서는 디자이너의 가설과 논리가 중요하다. 하지만 어느 정도 데이터가 쌓인 이후에는 실제 유저의 데이터가 매우 중요하다. 디자이너의 가설과 함께 데이터를 기반으로 해당 구조가 옳은지 판단하며 만들 수 있어야 한다.
구독과 라이킷은 글 작성에 많은 힘이 됩니다.
