디자이너가 피해야 할 유저 온보딩 함정
원문: Inside Design by Invision
이 글은 Invision에서 운영하는 Inside Design에 게시된 글을 직접 번역한 글입니다.
전문 번역가가 아니므로 대량의 오역 및 의역이 있을 수 있습니다.
원문: 3 user onboarding pitfalls every designer should avoid
다른 프로덕트에서는 잘만 동작하던 사용자 온보딩 프로세스. 내 프로덕트에서 유사하게 구현하니 왜 생각처럼 안되는지 궁금했던 적이 있나요?
이런 상황은 벤치마킹한 인터페이스 패턴이 내 프로덕트의 핵심 컨셉에 적용될 수 있는지, 혹은 핵심 컨셉을 훼손할 수 있는지를 생각해보지 않고 단순 모방했을 때 일어납니다. UI 구성요소는 언제나 바뀔 수 있지만, 그 바탕에 있는 프로덕트 자체의 컨셉은 그렇지 않죠. 프로덕트의 본질을 잘 이해하지 못한 온보딩 경험은 완전히 실패하곤 합니다.
이 글의 목차:
일반적인 사용자 온보딩 함정
액티브 유저(활성 사용자)의 역설
이중 과제 간섭
프런트 로딩
좋은 디자인 의사결정을 통해 함정을 피하는 방법
1. 액티브 유저(활성 사용자)의 역설
“액티브 유저의 역설”은 1980년대에 IBM 연구원 John Carrol과 Mary Beth Rosson에 의해 처음으로 소개되었습니다. 그들은 데스크톱 PC에서 특정 소프트웨어를 처음 사용하는 사람을 관찰하다가 뜻밖의 행동을 발견했습니다. 관찰 결과, 사용자들은 가이드를 전혀 읽지 않고 있었습니다. 대신 소프트웨어를 바로 사용하기 시작했습니다. 이로 인해 불가피한 오류가 발생하고 결국 막다른 골목에 갇혀버리게 되더라도 말입니다.
연구원들은 새로운 사용자들이 가이드를 읽을 경우 소프트웨어에 대해 더 많은 가치를 얻을 수 있을 걸 알고 있었음에도 불구하고 그걸 ‘이상적인 상태’로 설정하지 않았습니다. 그건 대부분의 사람들이 행동하는 방식이 아니었으니까요. 새로운 사용자들은 매뉴얼(사용자 가이드)을 읽느라 시간을 낭비하는 대신에 즉시 사용해봄으로써 뭔가 의미 있는 것을 해보길 원했습니다. 이게 바로 액티브 유저의 역설입니다.
대부분의 사용자들이 프로덕트를 사용하면서 능동적으로 배우기를 원한다는 것을 알았다면, 우리는 더 이상 입문자용 슬라이드나 튜토리얼 비디오와 같은 수동적인 형태의 콘텐츠에 의존하지 말아야 합니다. 대신 유저들이 프로덕트를 직접 탐구해나가는 시점에 사용자가 필요로 하는 정보를 주고, 사용자가 프로덕트와 상호작용할 수 있도록 이끌어야 합니다.
액티브 유저의 역설을 피하는 방법
액티브 유저의 역설을 해결하려면 사용자 저니(User’s Journey)의 콘텍스트 안에 가이드를 녹여야 합니다. 그래야 사용자가 실제로 프로덕트를 사용해보는 과정에서 쏟아지는 정보들에 대한 부담감 없이, 자신의 페이스에 맞춰 프로덕트를 익힐 수 있습니다.
(1) 기본값을 활용하세요
훌륭한 기본값을 설정하는 것은 사용자를 안착시킬 수 있는 간단하면서도 매우 강력한 방법입니다. 언어 학습용 프로덕트인 Duolingo의 사이트 첫 화면은 사용자가 사이트를 바로 사용해 볼 수 있도록 만듭니다. 사용자는 이 첫 화면에서 바로 기초 실력 테스트를 하거나, 첫 수업을 듣기 시작할 수 있습니다.
기초 실력 테스트를 해봄으로써 신규 사용자는 본인의 학습 목표에 즉각 다가가는 동시에 Duolingo가 어떻게 작동하는지 빠르게 경험할 수 있습니다. 이런 방법은 새로운 언어를 배우려고 안달 난 사용자에게 사이트 작동법에 대한 글 혹은 비디오를 늘어놓는 것보다 훨씬 효과적입니다.
(2) 사용 흐름 속에 학습 도구를 녹이세요
상호작용하는 온보딩 경험을 제공하는 또 다른 방법으로는 프로덕트를 사용하는 과정에서 자연스럽게 교육하는 것입니다. 다른 디바이스와 연결할 수 있는 애플릿(다른 프로그램 내에서 실행되는 프로그램, [출처] 네이버 지식백과)을 사용할 수 있도록 하는 앱 IFFTTT는 새로운 사용자에게 애플릿이 어떻게 작동하는지를 장황하게 설명하기보다는 사용자들이 흥미를 가질만한 애플릿을 직접 발견하도록 합니다.
아래의 예시를 볼까요. 우선 사용자는 자신이 이전에 찾아본 상품과 일치하는 상품이 나타나면 ebay로부터 알람을 받도록 하는 애플릿을 발견합니다. 그가 애플릿을 동작하는 순간, IFTTT는 이 애플릿이 어떻게 동작하는 지를 보여줍니다.
사용자들이 여러분의 프로덕트를 사용함과 동시에 온보딩하게 만들어서 액티브 유저의 역설을 해결해보세요. 사용자를 위한 가이드를 쌍방향적인 기본 값과 같은 형태로 설계할 수 있다면, 우리는 더 이상 튜토리얼이나 비디오를 만들기 위해 애쓰지 않아도 됩니다.
2. 이중 과제 간섭
“이중 과제 간섭”이란 사람들은 알람이나 공지 등 자신의 작업 중에 나타나는 메시지를 무시하는 경향이 있다는 이론입니다. 이때 이중(dual)은 사람이 한 번에 두 가지 일을 처리해야 함을 의미합니다.
“More Harm Than Good? How Messages That Interrupt Can Make Us Vulnerable”로 명명되는 연구 중, 구글 크롬의 엔지니어들과 파트너를 맺은 Brignham Young Universitiy의 연구원들은 사람들이 보안 알림에 어떻게 대처하는지를 관찰했습니다. 실험 참가자 중 74%가 인터넷 창을 끌 때 나타나는 보안 알림을 무시했으며, 비디오를 보거나 정보를 보내는 중에 나타나는 보안 메시지는 더 많이 무시했습니다. 이처럼 사람들은 어떤 일을 하던 중에 나타나는 메시지를 쉽게 무시합니다.
반면 비디오가 로딩되기를 기다리는 것처럼 자연스러운 멈춤(pauses) 상태에서는 보안 알림을 무시하는 수가 50%나 줄어들었습니다.
온보딩 경험을 설계할 때 우리는 본능적으로 입문자용 자료들을 가장 잘 보이게 두고 싶어 합니다. 하지만 신규 사용자는 처음 앱을 열었을 때 나타나는 안내 슬라이드는 재빨리 넘겨버리고, 새로운 웹사이트에 처음 방문한 사람은 자동 재생되는 비디오를 꺼버리는 데다가, 기존 사용자조차 늘 하던 행동 루틴 중 갑자기 신규 기능 안내 메시지가 튀어나오면 바로 꺼버립니다. 안타깝게도 우리는 이런 실패한 방법을 자주 사용하고 있습니다.
사용자의 행동을 막아서고 메시지를 띄우는 것은 중요한 정보를 보여주기 위한 최고의 방법처럼 보이지만, 이중 과제 관섭 이론에 의하면 이런 팝업성 메시지는 대부분의 경우 무시당하면서 끝이 납니다.
이중 과제 간섭을 피하는 방법
“More Harm Than Good?”의 연구원들은 자연스러운 휴식의 순간에 등장한 중요한 메시지가 가장 주목받는다는 사실을 확인했습니다. 메시지 설계할 때 이 관점에서 시작해야 합니다. 우리는 이중 과제 간섭이 작동하는 것을 막기 위해서 온보딩 가이드를 언제, 어디에 설치할지 철저하게 고심해야 합니다.
(1) 학습 메시지는 액션이 끝난 뒤에 보여주세요
The Commonwealth Bank of Austraila는 사용자가 Siri 명령어를 설정하도록 만들기 위해 사용자가 결제를 완료할 때까지 기다립니다.
(2) 메시지를 오버레이 하지 말고 맥락 안에(Inline) 넣으세요
우리가 온보딩 UX 설계 시 사용하는 방법은 종종 UX가 제공하는 정보를 방해물로 인식되게 만들기도 합니다. 유저 온보딩 단계에서 자주 쓰이는 오버레이(overlay) 기법은 사실 인터페이스 최상단에 등장하는 방해물에 불과합니다. 새로운 기능을 알려주고 싶다면 오버레이를 사용하지 말고, 제품 본연의 상태 화면 속에 가이드를 살짝 녹여보세요.
아래는 인스타그램이 신기능인 Story를 소개할 때 사용했던 인라인(Inline) 가이드입니다. 인스타그램은 공지문 등으로 사용자의 활동을 방해하지 않고, 다른 Story 사이에 “New”라는 제목의 Story 형태로 가이드를 녹여 두었습니다. 덕분에 아주 자연스럽게 새로운 기능을 보여줄 수 있었죠.
자연스러운 멈춘 상태에서 메시지 보여주기, 또 과중한 오버레이에 의존하지 않기를 통해 이중 작업 과제 현상에서 탈피해보세요. 사용자가 여러분이 보여주고자 하는 중요한 메시지를 무시하지 않고 주목하게 만들 수 있습니다.
3. 프런트 로딩(Front Loading)
"프런트 로딩"은 모든 교육이나 안내 과정이 새로운 프로덕트 경험의 초기 단계에서 시작되는 것을 말합니다. 이런 프런트 로딩 방식은 다양한 산업군에서 활용되고 있습니다. 비즈니스에서는 장차 생길 수 있는 모든 위험 요소를 제거하기 위해 가능한 모든 경우의 수에 대비한 계약서를 사전에 작성합니다. 예비 선거는 후보자 선출을 촉진하기 위해 선거 사이클 시작과 동시에 진행됩니다. 비즈니스나 선거에서는 이러한 프런트 로딩 방식이 유용할지 몰라도, 사람들이 새로운 것을 배우는 데는 그다지 효과가 없습니다. 특히 새로운 프로덕트의 경우에는요.
자전거 타기를 어떻게 배우는지 생각해보세요. 누구도 자전거에 처음으로 올라타자마자 번잡한 시내를 달리지 않습니다. 다음 단계로 갈 수 있을 정도로 실력을 연마할 때까지 안전한 지역에서 바퀴 굴리는 연습을 합니다.
많은 디자이너들이 모든 온보딩 과정을 한 번만 보여주기만 하면 새로운 사용자가 자신의 산출물을 완벽히 마스터할 수 있을 거라고 생각합니다. 불행히도 이런 오해는 사용자를 압도당하게 하고, 온보딩이 지난 단계에서는 사용자에게 어떤 도움도 주지 않는 실수를 불러옵니다.
프런트 로딩을 피하는 법
프런트 로딩을 피하기 위해서는 신규 사용자가 익혀야 하는 각 작업을 세분화하고 그 작업들에 대한 교육을 점진적으로 적용해야 합니다.
교육 전략 기초(Instructional scaffolding) 작법은 교수 혹은 선생님이 어떻게 학생이 특정 개념을 이해하도록 단계적으로 지도할 수 있는지를 명시합니다. “Sign Um Forms Must Die”라는 기사에서 Luke Wroblewski는 사인 업(가입이나 등록) 단계를 사용자가 부담 없이 입력할 수 있는 정도로 나누는 “점진적 참여” 접근법을 소개했습니다.
위 두 예시는 공통적으로 ‘신규 사용자를 효과적으로 온보딩 시키고 싶다면, 가이드를 한 번이 아닌 여러 번에 나눠서 제공하라’고 조언합니다.
(1) 핵심 Setup activities를 3 단계로 나누기
신규 사용자가 꼭 익혔으면 하는 핵심 셋업 활동들을 정의해보세요. 그다음 그 액션들을 다음의 세 가지 파트로 분류해봅니다: 트리거(Trigger), 활동(Activity), 팔로업(Follow-up). 이 세 가지 파트에 따라 교육이나 가이드를 제공하는 것은 온보딩 플로우를 보다 점진적이고 효과적으로 만들어줍니다.
Slack의 “계정 만들기” 과정은 사인 업 과정을 어떻게 간단하면서 효과적으로 트리거, 활동, 팔로업에 맞춰 세분화할 수 있는지 보여줍니다.
먼저 우리는 새 계정을 만드는 과정을 시작하게 하는(Trigger) 가이드를 볼 수 있습니다. 마치 동료가 초대하는 듯한 형태를 취하고 있죠. 이 가이드는 초대에 응하는 것이 얼마나 좋은지를 간결하게 설명하고, 이후 사인 업 절차가 이어질 것이라는 기대를 심어줍니다.
‘가입하기(Join now)’를 누르면 사용자는 슬랙 웹사이트의 사인 업 양식으로 이동하는데, 이는 계정 생성 활동(Activity)에 해당합니다. 이 단계에서 가이드 텍스트는 사용자가 합류하려는 (슬랙의) 워크플레이스를 다시 한번 확인시키고, 각 입력창 아래의 텍스트로 사용자가 완료해야 할 과제들을 적절히 안내합니다.
‘계정 만들기(Create Account)’를 누르면 이 과정이 종료되고, 사용자는 이제 팔로업(Follow-up) 단계에 진입합니다. 이때 가입 완료 메시지는 잠깐 등장하고, 더 심화된 단계, 즉 더 많은 동료를 초대하는 단계를 시작하도록 요청합니다.
단계별로 가이드를 주는 것은 설치나 사인 업 과정에만 효과적인 것은 아닙니다. 사용자가 특정 피쳐에 온보딩 할 수 있도록 돕는 데도 도움이 되죠.
트위터는 사용자에게 인 앱 카메라 기능을 소개하는 과정에서 트리거, 활동, 팔로업으로 세분화된 가이드를 제공합니다. 트리거 가이드는 트윗들을 불러오는 동안 이 새로운 기능을 소개하는 툴팁 형태로 나타납니다. 활동을 위한 가이드에서는 시스템 접근 권한 설정 방법과 사진을 찍는 법을 소개합니다. 팔로업 가이드는 트윗을 완료한 사용자를 다시 스트림으로 이동시켜 계속해서 최근 게시물을 볼 수 있도록(즉, 이탈하지 않도록) 합니다.
이 전략에 대한 더 자세한 내용이 궁금하다면 아래 사이트를 방문해보세요.
https://www.kryshiggins.com/long-term-guidance/
액티브 유저의 역설, 이중 과제 간섭, 프런트 로딩과 같은 일반적인 온보딩 디자인 함정들에 대해 이해하는 것은 우리가 그것들을 피할 수 있도록 도와줍니다. 이 세 가지 함정 중 하나라도 해결할 수 있다면 우리는 더 나은 온보딩 환경을 구축할 수 있습니다.
이 글을 처음 읽었을 때는 찾아 헤매던 드래곤볼을 발견한 기분이었습니다. 마침 사용자 온보딩 속도를 빠르게 하는 작업을 집중해서 하고 있을 때였는데, 그때 제가 생각했던 전략이 바로 정확히 '2. 이중 과제 간섭'이었던 겁니다. 중요하다고 생각하는 메시지를 오버레이 하고, 팝업을 띄우고, 결국에는 한 트럭 분량의 매뉴얼과 지침서를 던져 넣는(...) 짓을 하고 있었죠. 물론 결국 이런 모순을 모두 피하지는 못했습니다만(그리고 당연히 성과가 크게 좋지 못했습니다만), 이 글이 주었던 깨달음과 쓰라린 실패의 경험을 자양분 삼아 다음번 프로젝트를 기획하는 중입니다. 부디 빠른 시일 내에 보다 나은 성과를, 훌륭한 유저 온보딩 성공 케이스를 만들어 내기를 기대해봅니다.
