알다 앱 디자인 리뉴얼 이야기 (2)
알다 디자인 시스템 3.0 과 온보딩 개선
이 글은 2024년 6월 24일 알다 디자인 팀 미디엄에도 발행된 글입니다.
이전 내용이 궁금하시다면
알다 앱 디자인 리뉴얼 1편을 확인해 주세요!
알다 디자인 시스템 3.0
서비스를 운영하다 보면 새로운 UI와 정책들이 생겨납니다. 이때 프론트엔드와의 논의 없이 일단 급하게 만드는 것에 집중하다보면 점점 레거시가 되기 시작하죠. 레거시를 없게 만드는 건 불가능하지만, 항상 관리할 수 있는 수준으로 레거시를 유지하는 게 중요합니다. 만약 이 레거시가 관리 역량 이상으로 쌓이기 시작하면, 작은 기능 하나를 만들 때도 커뮤니케이션이 과도하게 발생해 결국 제품 조직의 속도와 효율을 느리게 만듭니다. 따라서 이 레거시를 주기적으로 정리하거나, 컴포넌트 설계 시 디자인에서는 확장성을, 개발에서는 모듈화를 최대한 고려해서 디자인 시스템을 운영해야 합니다.
디자인 시스템과 제품 비효율성, GPT-4로 제작앞서 세운 가설을 기반으로 다양한 디자인 시안을 만드는 동시에, 기존 디자인들도 같이 개선해보기로 했습니다. 새로운 브랜드 디자인을 UI에 적용하면서, 동시에 기존 레거시 디자인을 정리해야 앞으로 프론트엔드와 디자인이 더 속도를 낼 수 있을 것이라는 판단이었어요. 물론 기존 디자인 시스템이 존재하고 있지만 버전 관리가 제대로 되지 않거나, 운영과 다른 디자인이 있는 등 개편할 필요가 있었습니다.
알다 3.0 이전의 텍스트필드 컴포넌트 핸드오프색상과 폰트를 새로 변경하면서 컴포넌트의 규격이나 설계에 영향을 받는 부분들이 있었습니다. 특히 버튼이나 텍스트필드, 앱 바처럼 전역에서 사용되는 컴포넌트들을 일괄적으로 관리하기 위해선 설계를 변경해야 했어요. 이처럼 새로운 브랜드 디자인을 바로 적용할 수 없는 컴포넌트들을 찾아내고, 규격을 새로 정의할 필요가 있는 것들을 추려내 알다 디자인 시스템 3.0으로 정의했습니다.
만들어진 지 오래 되어 쓰지 않는 컴포넌트, 같은 UI지만 규격이나 속성이 통일되지 않은 컴포넌트, 제품에는 있지만 디자인엔 없는 컴포넌트 등 레거시로 되어 있는 디자인 현황을 파악해보며, 알다 디자인 시스템 3.0의 첫 버전에서는 다음 2가지 항목을 중점적으로 고려했습니다.
디자인과 개발의 컴포넌트 구조를 최대한 같게 맞출 것
개념이 중복되는 컴포넌트는 지양하고, 최대한 단일 컴포넌트의 확장 형태를 고려할 것
디자인과 개발의 컴포넌트 설계 구조 통일
먼저, 컴포넌트의 설계는 프론트엔드의 구조와 최대한 동일하게 맞추되, 다른 개발 일정에 영향을 주지 않기 위해 최소한의 범위를 적용하고 이후 점진적 개선을 목표로 했어요. 디자인과 개발에서 각각 형태는 같아 보여도, 피그마에서 쓰는 속성과 실제 개발에서 쓰는 속성이 다르면 커뮤니케이션을 한번씩 더 해야 하는 비효율이 발생하고 있었기 때문이에요.
단적인 예로, 버튼 컴포넌트의 속성들이 개발과 맞춰져 있지 않아 매번 커뮤니케이션을 추가로 더 해야 하거나, 프론트엔드에서 추가 작업을 해야 하는 경우가 빈번하게 발생했습니다. 특히 기존 버튼에선 로딩이나 비활성화를 토글 속성으로 받아서 사용하고 있었어요.
알다 3.0 이전 버튼 컴포넌트 속성. 이전 버전에선 로딩(Loading)과 비활성화(Disabled)를 토글(Boolean)으로 처리하고 있었어요.
알다 3.0 버튼 컴포넌트 속성.컴포넌트 설계 관점에서 보자면, 상태값은 상보적 분포(Complementary Distribution) 관계에 있어야 합니다. 하나를 선택하면 다른 것들은 선택할 수 없어야 하고, 이 모든 상태들을 종합하면 빠진 케이스가 있어서는 안 된다는 뜻이에요. 쉬운 말로, 버튼이 로딩 상태가 된다면 자연스럽게 호버나 기본 상태를 선택할 수 없어야 한다는 뜻입니다. 만약 상태값과 별개로 비활성화나 로딩이 존재하면, 상태값마다 비활성화와 로딩이 있는 것과 없는 경우가 생긴다는 모순이 생겨버릴 수 있어요.
알다 3.0의 버튼 상태값. 로딩과 비활성화를 토글이 아니라 상태값으로 포함시켰습니다.개발 관점에서도 별도의 토글 속성이 아니라 상태값으로 처리하는 것이 더 쉬워요. 따라서 새로 설계한 버튼 컴포넌트는 버튼의 상태값에 로딩 및 비활성화를 포함시켰습니다.
알다 디자인 시스템 3.0의 텍스트필드의 구조 및 명칭또한 컴포넌트 구조 역시 개발 지향적인 구조와 속성으로 변경했어요. 피그마에서 그룹 기능으로 만들어져 있던 텍스트필드를 프레임으로 개편하고, 컴포넌트 구조와 각 부분의 명칭을 핸드오프로 명확하게 작성했어요.
단일 컴포넌트의 확장성 부여
또한 중복으로 만들어진 디자인을 제거하고, 최대한 단일 컴포넌트를 응용해 확장할 수 있도록 설계 방식을 변경했어요. 특히 앱 바(네비게이션 바)처럼 다양한 형태와 속성을 가질 수 있는 UI들은 설계 자체를 확장성 있도록 만들지 않으면 과도한 관리 비용이 발생하기 쉽기 때문에, 프론트엔드와 긴밀하게 협업해 최대한 하나의 컴포넌트만 만들고, 그 안에서 속성들을 다양하게 조정해서 사용할 수 있는 환경을 만드는 걸 목표로 했어요.
단일 컴포넌트화로 효율화를 대폭 올릴 수 있었던 대표적인 컴포넌트는 텍스트필드 컴포넌트와 앱 바를 꼽았어요.
먼저 텍스트필드의 경우, 입력 값에 따라 단위나 타이머 등의 부차적인 정보가 필드에 같이 존재하는 등 다양한 케이스가 있었어요. 전화번호나 생년월일 등 모든 케이스를 따로 분류해 컴포넌트를 만들다보니, 중복되는 케이스가 있기도 하고 심지어 일부 케이스는 생략되거나 빠져 있는 경우도 발생하고 있었어요.
알다 디자인 시스템 3.0 이전의 텍스트필드 컴포넌트. 케이스가 정리되지 않은 채 사용되고 있었어요.새로 개편하면서 케이스마다 다르게 만들어진 텍스트필드의 구조를 동일하게 맞추고, 필드 뒤쪽에 따라오는 서브 유닛 영역을 설계했어요. 단위 등을 입력할 수 있는 케이스와, 타이머를 입력할 수 있는 케이스로 통일했어요.
또한 생년월일이나 통신사+휴대전화번호처럼 필드 여러개를 합성해서 사용하는 경우, 기존에는 별도의 케이스를 다 하나하나 만들어서 사용하고 있었지만, 3.0 에서는 기본 필드를 모아 컴포넌트로 재구성한 합성 컴포넌트 개념을 적용해 구축했습니다.
새로 개편된 텍스트필드 컴포넌트.
텍스트필드와 셀렉트박스를 인스턴스로 합성해 만든 복합 필드 컴포넌트.앱 바의 경우, 우측의 보조 기능 및 메뉴 유무, 좌측 뒤로가기 유무, 페이지 이름 유무 등의 다양한 경우의 수를 모두 별개의 배리언츠로 받아 사용하고 있었어요. 새로운 케이스가 생길 때마다 디자인 시스템에 추가해야 했고, 개발에서도 일관된 형태나 구조를 이해하기 힘들다 보니 매번 규격을 확인해야 하는 비용이 꽤 크게 발생하고 있었습니다. 특히 우측 아이콘을 변경하려면 디자인 시스템에서 새로운 케이스를 정의해서 써야 하는 불편함이 매우 컸어요.
기존 앱 바 컴포넌트. 경우의 수를 모두 배리언츠로 따로 관리하고 있었습니다.또한 디자인을 변경할 때도 케이스가 워낙 많이 사용되다 보니, 한두 군데만 수정하더라도 전체 앱 바의 디자인을 다시 만져야 하는 비효율도 심각했습니다. 케이스를 정리해낸 후, 앱 바의 기본 규격 및 설계 구조를 통일했어요.
알다 3.0 에서 개편된 앱 바. 3가지의 케이스로 통일했어요.뒤로가기 아이콘 버튼을 기본값으로 두고, Boolean 속성을 부여해 필요하지 않을 때는 숨길 수 있도록 설계했습니다. 또한 기존의 수많은 케이스를 버튼, 아이콘 1개, 아이콘 2개로 정리했어요. 아이콘들은 미리 정의된 아이콘 라이브러리를 통해 어떤 아이콘으로든 교체해서 사용할 수 있도록 설계했습니다.
다양한 케이스를 하나의 컴포넌트 안에서 속성(Property) 조절만으로도 만들 수 있습니다.디자인 시스템은 그 자체도 하나의 제품으로써, 사용자가 외부가 아닌 내부 디자이너와 개발자일 뿐 항상 개선점을 찾아내고 적용하는 과정은 같아요. 사용자를 위한 제품이 발전하고 고도화될 수록, 디자인 시스템 또한 같이 발전하고 고도화되어야 합니다. 그래야 제품 조직의 유연함과 기민함을 계속해서 유지할 수 있고, 제품 조직의 역량을 UI 설계가 아니라 실험과 이터레이션에 집중 투사할 수 있게 함으로써 조직의 실행 가속도를 최대한 끌어올릴 수 있기 때문이에요.
알다 앱 리뉴얼의 핵심 개선, 홈 화면
알다 디자인 팀이 세운 가설(1편 참고)홈 화면에 도달한 사용자들에게 다른 기능을 제안하지 않고 바로 대출 비교에 집중할 수 있도록 유도한다면 대출 비교 실행률이 오를 것이라는 가설을 토대로 디자인 시안을 만들어 보기 시작했습니다.
디자인 시안을 도출하는 과정에서, 데이터 팀에서 앱 설치 직후부터 홈 화면에 오는 과정인 ‘온보딩’ 에서의 사용자 이탈이 제품 전체에 꽤 큰 영향을 미치고 있다는 인사이트를 공유해 주셨어요.
전환 퍼널의 개념. 맨 위에 도달한 사람들이 많을 수록 맨 아래쪽까지 내려오는 사람들의 수도 많아져요.전환율이 일정할 때, 홈 화면까지 도달하는 사용자가 많을 수록 대출 비교를 실행하는 사용자 역시 자연스럽게 더 많아집니다. 따라서 홈 화면에서의 전환율을 극대화하기 위해 온보딩 과정도 추가적으로 개선하는 걸 리뉴얼의 보조 목표로 챙기기로 했어요. 다만 전체 일정과 공수가 정해져 있어서 대대적인 개선보다는, 일정에 영향을 주지 않는 선에서 UX가 어색한 부분을 건드려 보기로 했습니다.
대출 비교 플랫폼을 사용하는 사용자들은 대출을 받으려는 사람과 받은 대출을 관리 하려는 사람, 이렇게 2가지 경우로 나눌 수 있어요. 그 외의 행동을 유도하거나 제안하는 건 우리가 세운 가설과 비교해봤을 때 적합하지 않다고 생각했습니다. 이전 글에서 고민했듯이 사용자가 대출 비교에 더 빠르게 진입하도록 유도하기 위해선, 홈 화면에서 최대한 많은 것들을 덜어내야 했어요.
위에서 정리한대로 홈 화면까지의 과정인 온보딩, 홈 화면에서의 대출 받기, 그리고 대출 관리 등 총 3가지의 큰 작업 범위를 정하고, 디자이너 셋이 각자 범위를 책임지고 맡아 진행하기로 했습니다.
온보딩, 대출받기, 대출관리 담당자 등장온보딩
온보딩 개선 방향
온보딩의 사전적인 의미는 ‘탑승’ 으로, 전통적으로 선원들이 출항을 위해 배에 올라타는(on + board) 행위를 뜻합니다. 앱 생태계가 커지면서 사용자가 새로운 서비스에 ‘탑승’ 하는 것으로 의미가 확장됐습니다.
항공기 탑승 시에도 ‘Welcome on board’ 라는 인사를 받을 수 있습니다온보딩은 일반적으로 서비스 로고가 보이는 스플래시 화면을 시작으로, 회원가입 과정이나 튜토리얼이나 코치마크같은 앱 사용 설명 단계 등을 포함하고 있어요. 서비스마다 사용자를 맞이하는 전략이나 방법은 상이하기 때문에 다양한 온보딩 형태가 있지만, 일반적으로는 스플래시 화면 이후에 회원가입 또는 로그인 과정 정도를 말합니다.
Uber Eat의 온보딩 과정 예시(출처 : Mobbin)알다는 대출을 중개하는 플랫폼이기 때문에, 데이터를 주고 받는 과정에서 본인을 면밀하게 확인하는 과정이 반드시 있어야 합니다. 이 본인 인증 과정 및 회원 가입 과정을 알다에서는 온보딩으로 부르고 있습니다. 본인 인증을 거치지 않으면 서비스를 사용할 수 없도록 설계되어 있었습니다.
알다 3.0 이전의 온보딩 본인인증 화면리뉴얼 TF 구성원들과 논의한 결과, 본인 인증 과정을 대대적으로 개선하는 건 리뉴얼의 목적에서도 벗어날 뿐만 아니라 개선을 관찰하고 측정하는 것 역시 어려울 수 있다는 소결론을 만들 수 있었습니다. 따라서 이탈이 가장 큰 부분의 UX를 다듬는 작은 변화부터 만들어 보고, 리뉴얼 이후에도 꾸준히 추적하면서 차근차근 쌓아 보기로 했습니다.
온보딩 과정의 문제 정의
온보딩은 사용자가 제품에 대한 인상을 학습하는 중요한 부분입니다. 온보딩의 경험이 얼마나 매끄럽고, 만족스러웠는지에 따라 비즈니스 성과가 달라질 수 있습니다. 핵심 기능이나 가치를 소구함으로써 사용자가 서비스에 대해 가지는 기대감을 키워주거나, 또는 퍼널 자체를 매우 단순하게 만듦으로써 빠르게 서비스에 유입될 수 있도록 유도해 최대한 앱에 진입한 사용자들을 이탈시키지 않고 원하는 화면까지 데려가는 것이 중요합니다.
기존 온보딩에서는 다음 2가지 이탈지점을 찾아낼 수 있었습니다.
시작하기 화면에서 이탈
정보 입력 단계에서 이탈
시작하기 화면
스플래시 화면을 거친 사용자는 앱의 첫 화면인 시작하기 화면에 도달합니다. 일반적으로 이 화면에선 앱이 줄 수 있는 핵심가치나 핵심 기능에 대한 소구를 전달하며, 사용자로 하여금 자연스럽게 앱을 탐색할 수 있도록 유도하는 부분입니다.
기존 알다 앱의 시작하기 화면. 시작하기를 누르면 본인 인증 단계로 넘어가요.기존 알다 앱에서는 시작 화면에서 핵심 가치를 캐러셀 형태로 전달하고 있었습니다. 이 부분에서 시작하기를 누르지 않고 이탈하는 사용자들이 제법 많았어요. 앱 설치까지 했는데, 열자마자 바로 앱을 이탈하는 사용자가 있다는 뜻이었어요.
리뉴얼 TF에선 ‘사용자가 알다 앱을 이용함으로써 얻을 수 있는 가치나 혜택에 대해 충분히 설득되지 않았다’ 고 문제를 정의했습니다. 다만 리뉴얼의 목적이 홈 화면의 맥락을 변경하면서 리브랜딩 요소를 반영하는 것이기 때문에, 핵심 가치를 새로 소구하는 솔루션은 고도화 단계로 두고 퍼널을 다듬는 정도로 두었습니다.
기존 시작 화면과 리뉴얼된 시작 화면어떤 화면이 있을 지 예측하기 어려운 ‘시작하기’ 버튼 대신 알림 권한 허용을 유도하는 버튼으로 교체하고, 알림을 허용했을 때 얻을 수 있는 실질적인 혜택을 바로 강조해보는 방향으로 변경했습니다.
정보 입력 단계
기존 정보 입력 단계에서 이름을 입력하지 않고 절반 가까이 이탈하고 있었어요정보 입력 단계는 본인 인증을 위한 정보를 수집하는 단계입니다. 이름을 입력해달라는 화면에서 특히 안드로이드 사용자의 이탈율이 절반 가까이 되고 있었어요. 리뉴얼 TF에서는 ‘대출이라는 민감한 서비스를 이용하면서, 이름을 입력해야 하는 이유에 대해 설명이 충분하지 않아 개인 정보가 노출되는 것이 부담스러운 건 아닐까?’ 라고 생각하고, 빠르게 시도해볼 수 있는 해결책을 제안했습니다.
개인정보가 노출되지 않는다는 문구를 추가한 리뉴얼 버전.대출 받기를 위한 지름길 제안
온보딩에서 이탈하는 지점들을 개선하는 작업들과는 별개로, ‘대출 비교를 굳이 홈 화면까지 도달한 후에 실행하게 해야할까?’ 라는 별도의 의문점이 들었어요. 온보딩이 끝나자마자 바로 대출 비교로 유도할 수 있다면 홈 화면에서 사용자가 다른 곳으로 이탈하는 것을 더 줄일 수 있지 않을까요?
기존 알다 앱에선 회원 가입이 완료되면 자동으로 홈 화면으로 이동할 수 있어요기존 서비스에서는 본인 인증 과정을 모두 거치면 회원 가입이 완료되고, 홈 화면으로 이동할 수 있었어요. 즉, 홈 화면에서 사용자가 대출 비교를 직접 눌러야 했어요. 우리가 리뉴얼에서 정의했던 문제가 홈 화면에서 대출 비교를 충분히 소구하고 있지 못하다는 것이었기 때문에, 회원 가입이 완료되면 바로 대출 비교를 실행시켜 보는 건 어떨까 궁금했어요.
기존 회원 가입 완료 화면과 리뉴얼된 회원 가입 완료 화면.리뉴얼 알다에서는 회원 가입이 완료되면 자동으로 화면이 전환되는 것은 동일하지만, 홈 화면이 아니라 대출 비교를 제안하는 화면으로 이동하도록 변경했어요. 물론 사용자는 둘러본다는 선택지를 통해 홈 화면으로 이동할 수도 있습니다. 이전 온보딩에 비해 화면이 하나가 늘어났지만, 오히려 대출 비교로 이동하는 퍼널 자체는 더 줄어든 셈이에요. 또한 홈 화면에 도착 후 다른 기능으로 이탈하는 경우를 최소화하고, 회원 가입이 완료됨과 동시에 바로 핵심 퍼널로 이동시켜주는 일종의 지름길을 만들어 주게 되었어요.
온보딩 과정은 지속적으로 관찰 및 추적이 중요한 부분인만큼, 위에서 세운 문제와 해결책들 이후로도 꾸준히 실험을 지속하고 있습니다.
온보딩 영역을 만드는 동안, 홈 화면에서 경험할 수 있는 알다의 주요 2가지 제품인 ‘대출받기' 와 ‘대출관리' 역시 본격적으로 디자인을 발전시켜보기 시작했어요. 핵심 제품 2가지의 디자인 과정에 대한 이야기는 이어지는 3편에서 바로 소개해 드릴게요.
금융의 모든 연결고리, 알다
앱 다운로드 바로 가기
