이런 것도 컴포넌트로 만들어도 될까?

이 화면은 토스 앱에서 여러 가지 옵션을 선택하는 방식이었어요. 어떤 문제가 있는지 느껴지시나요?

1️⃣ 잘 모르겠다. 2️⃣ 알 것 같다.

1번, 2번, 선택 안 하신 모든 분들! 어떤 문제가 있는지 알려드릴게요.

바로 ‘물리적 거리 사용성’인데요

화면 위에서 버튼을 누른 후 아래에서 올라오는 바텀시트의 버튼까지 시선이 닿으려면, 사용자들은 인지 비용을 더 써야 하기 때문에 선택까지의 시간이 늘어나게 돼요.

현실 세계에서는 어떤 버튼을 눌렀을 때 그에 대한 반응이 버튼을 누른 곳에서 오는게 당연하잖아요. 이 사용성은 현실 세계와 동떨어진 모습을 띄고 있어요. 특히 지금 보시는 이미지처럼 옵션 개수가 적을 경우엔 거리가 더 멀어져요.

그동안 토스에는 모든 화면에서 셀렉터가 필요할 때 위와 같은 방법을 사용했었어요. 그 방법을 쓴 이유 중 하나는 컴포넌트 종류의 한계도 포함되어 있었어요. 셀렉터 역할을 할 컴포넌트가 바텀시트 밖에 없었던 것이죠.

그래서 우리 앱에는 ‘메뉴’라는 새로운 컴포넌트가 필요했어요.

메뉴는 버튼을 누르는 그 자리에서 바로 펼쳐지기 때문에 물리적 거리가 짧고, 인지 시간이 짧은 자연스러운 UI예요. 이 컴포넌트는 사용자의 선택이 많은 토스 앱에 꼭 필요한 UI인데… 새로운 컴포넌트를 만들어야겠다고 생각한 순간 작은 의심이 생겨나요.

이 컴포넌트를 만들면 사람들이 잘 쓸까? 이전 사용성보다 지표가 떨어지지는 않을까? 모바일은 iOS, Android, Web 세 벌을 만들어야 하는데 더 빨리 만들 수는 없을까?

이 컴포넌트가 과연 유효할지 확신이 서지 않은 상태에서는 구현 리소스도 고민하게 돼요. 그럼 이 의심을 확신으로 만드는데 어떤 과정이 있었을까요?

1. A/B 테스트 실험하기

실험을 통해 의심을 확신으로 만들기

우리는 바텀시트를 셀렉터로 보여주는 실제 서비스 화면에 메뉴를 적용해서 지표의 변화가 없는지 A/B 테스트를 통해 알아 보기로 했어요. 실험하는 화면은 네이티브 서비스여서 OS에서 기본으로 제공하는 메뉴 컴포넌트를 활용하기로 하고 열 흘간 지켜봤어요.

이렇게 바로 실험할 수 있다고?

저도 토스에 온 지 얼마 안 됐을 때는 활발한 실험 문화가 신기했어요. 그동안 실험이라는 것은 제가 하는 일과는 멀다고 생각해서 큰 허들처럼 느껴졌고, 개발자나 기획자가 하는 일이라고 생각했었어요.

토스는 실험 문화가 잘 만들어진 곳이에요. 사용자의 아주 작은 행동 변화까지 알아내어 더 좋은 경험으로 만들기 위해 매 순간 노력해요. 디자인 시스템에 컴포넌트를 만들 때도 종종 실험을 하는데요. 꼭 제품을 만드는 팀이 아니더라도 UI 디자인, 그래픽, 라이팅, 인터랙션의 시스템이나 기준을 만들 때 제품팀과 협업하여 A/B 테스트를 하거나, UT를 통해서 검증해요.

그래야 왜 이 컴포넌트가 존재하는지 설득하는 커뮤니케이션 코스트가 줄어들고 2,000명이 의심 없이 쓸 수 있는 논리와 근거가 탄탄해진 디자인 시스템으로 성장할 수 있어요. 시스템을 만드는 작업자의 직감을 믿는 영역도 물론 있지만, 이 일이 맞는지 의심부터 들게 된다면 실험은 확신을 만들어내는데에 가장 좋은 도구로 쓰고 있어요.

돌아와서, 그럼 우리가 A/B 테스트 지표로 알 수 있는 것

기존 대비 클릭율이 높거나 변화가 없다 → 시스템화 한다. 🙆 기존 대비 클릭율이 적다 → 시스템화 하지 않는다. 🙅

열 흘간 A/B테스트를 한 결과는?

바텀시트 대비 전체 지표 큰 변화 없음 🙅 Android는 바텀시트보다 메뉴에서 아이템 클릭율이 10% 더 높음 ⬆️ 메뉴 컴포넌트 시스템화 하기 결정! 🎉

2. OS 컴포넌트를 최대한 활용하기

컴포넌트 빠르게 구현하기

토스 컴포넌트 디자인의 핵심은 일관성이에요. iOS, Android, Web에서 사용하는 UI 디자인 스타일을 하나로 맞춤으로써 어떤 환경이든, 어떤 화면에서든 디자인 일관성이 지켜지면 정성적 경험에 좋은 영향을 미친다고 믿기 때문이죠.

하지만 메뉴 컴포넌트는 핵심 룰을 벗어나고 더 빠르게 구현하는 방법을 선택했어요. 메뉴 컴포넌트가 모든 화면에서 많이 쓰인다면 그때 디자인 일관성을 맞추는 것도 늦지 않는다고 생각했어요.

실험과 동일하게 iOS와 Android는 OS에서 제공하는 기본 컴포넌트를 제공 했어요. 그럼 iOS, Android 끝. Web만 구현하면 되는데 Web은 가장 사용자수가 많은 Android의 디자인을 따라 구현했어요.

Web에서 iOS와 Android의 뷰를 다르게 하여 분기 처리를 할 수 있었지만 당시 목적은 ‘빠르게 구현하기’ 였어서 고려하지 않고 넘어갔던 것 같아요.

새 컴포넌트를 만들 때 적용해보기

이 과정을 통해 두 가지 팁을 얻을 수 있었어요. 이 글을 읽는 여러분들도 컴포넌트를 만들 때 적용해보셨으면 좋겠어요.

1️⃣ 나의 직감을 확신으로 만들 수 있는 도구를 사용한다. A/B 테스트나, 사용자에게 직접 물어보는 UT를 통해 이전보다 더 나아진 사용성인지 확인해요.

2️⃣ OS 컴포넌트를 최대한 활용해서 속도를 빠르게 한다. 완벽한 컴포넌트를 만드는 일은 오래 걸려요. 처음부터 디테일에 집착하지 않고, 기본으로 제공하는 OS 컴포넌트가 있다면 고민 없이 쓰고 나중에 디벨롭 해도 돼요.