사용자 흐름

화면이 아니라 흐름

4장에서 정보를 어떻게 나누고 이름 붙일지 정했다. 정보 구조가 서비스의 지도라면, 이 장에서 다룰 것은 그 지도 위를 걷는 길이다. 사용자가 어떤 목표를 이루기 위해 서비스 안에서 지나가는 화면과 행동의 순서를 사용자 흐름(User flow)이라고 한다. 같은 말을 조금 좁게 써서, 특정한 과업 하나("찾는 책을 맡겨 두기")를 끝내는 데 필요한 단계만 그린 것을 과업 흐름(Task flow)이라고 부르기도 한다. 이 장에서는 둘을 크게 구별하지 않고, 그린 그림을 과업 흐름도라고 부른다.

흐름을 따로 그리는 이유는 단순하다. 화면을 한 장씩 그리면 각 화면은 잘 만들어져 보인다. 하지만 사용자는 화면 한 장을 보러 오지 않는다. 책을 맡기러 온다. 그 목표에 닿기까지 화면을 몇 장 넘겨야 하는지, 어디서 무엇을 결정해야 하는지, 결정이 틀렸을 때 어디로 돌아가는지는 화면을 나란히 놓아야 보인다. 3장의 여정 지도가 서비스 바깥까지 포함한 사람의 하루를 그렸다면, 과업 흐름도는 서비스 안쪽의 길을 단계 하나하나까지 그린다.

흐름도에서 가장 먼저 그리는 길은 모든 일이 순조로울 때의 길이다. 검색하면 결과가 있고, 책이 그 책방에 있고, 주인이 바로 확인하고, 손님이 약속한 날에 찾으러 온다. 이런 길을 행복한 경로(Happy path)라고 한다. 처음에는 행복한 경로 하나만 그린다. 단계가 몇 개인지, 단계마다 사용자가 무엇을 알아야 하고 무엇을 결정해야 하는지가 보인다. 그 다음에 마름모마다 "만약 아니라면?"을 붙여 가며 다른 길을 그린다. 이 장의 뒷부분에서 다룰 예외 경로다.

화면 스케치를 흐름도의 네모 자리에 작게 붙여 놓은 그림을 와이어플로(Wireflow)라고 부르기도 한다. 와이어플로는 개발자와 이야기할 때 특히 쓸모가 있다. "이 버튼을 누르면 어느 화면으로 가요?"라는 질문에 그림 하나로 답할 수 있기 때문이다. 하지만 첫 단계에서는 화면을 그리지 않는 편이 낫다. 화면을 그리기 시작하면 단계의 수와 순서보다 버튼의 색과 글자 크기에 눈이 가기 쉽다.

단계마다 조금씩 빠진다: 퍼널

흐름의 첫 단계에 들어온 사람이 모두 마지막 단계까지 가지는 않는다. 단계마다 몇 사람씩 떠난다. 단계별로 남은 사람 수를 위에서 아래로 막대로 그리면 깔때기 모양이 되어서, 이것을 퍼널(Funnel, 깔때기)이라고 부른다. 한 단계에 들어온 사람 가운데 다음 단계로 넘어간 사람의 비율을 그 단계의 계속 비율(Step continuation rate)이라고 하고, 떠난 사람의 비율을 이탈률(Drop-off rate)이라고 한다. 둘을 더하면 1이다.

첫 단계에 들어온 사람 중 끝까지 간 사람의 비율은 단계별 계속 비율을 모두 곱한 값이다. 1,000명이 들어와 첫 단계에서 90%가 넘어가면 900명, 다음 단계에서 80%가 넘어가면 720명이 남는다. 더하거나 평균 내는 것이 아니라 곱한다는 점이 퍼널의 핵심이다.

아래 시뮬레이터는 "맡아 두기"의 첫 흐름안이다. 서윤이 처음 그린 흐름에는 검색부터 요청 확인까지 아홉 단계가 있고, 그 가운데 회원 가입과 본인 확인이 끼어 있다. 각 단계의 계속 비율은 가상의 값이다. 단계 이름을 누르면 그 단계를 흐름에서 빼거나 다시 넣는다. 막대의 끝(손잡이)을 끌면 그 단계의 계속 비율이 바뀐다. 1,000명이 들어왔을 때 각 단계에 몇 명이 남는지 본다.

처음안에서 가장 많은 사람이 떠나는 곳은 회원 가입이다. 찾는 책이 있는지 보러 온 손님에게 아이디와 비밀번호를 만들라는 요구는 목표와 상관없는 숙제처럼 느껴진다. 본인 확인도 마찬가지다. 이 두 단계를 빼면 끝까지 가는 사람이 두 배 넘게 늘어난다. 단, 이것은 "빼도 다른 단계는 그대로"라는 가정 아래의 계산이다. 가입을 빼면 가게 쪽에서는 손님이 누구인지 어떻게 아느냐는 문제가 남는다. 단계를 빼는 결정은 그 단계가 하던 일(손님을 알아보고, 연락하고, 약속을 지키게 하기)을 다른 방법으로 해낼 수 있을 때만 할 수 있다.

시뮬레이터의 "가입 없는 안"은 그 질문에 대한 서윤의 첫 답이다. 회원 가입, 본인 확인, 연락처 입력, 약관 동의를 전화번호 인증 한 단계로 묶는다. 전화번호로 문자를 받아 여섯 자리 숫자를 넣으면, 가게는 연락할 번호를 얻고 손님은 아이디를 만들지 않아도 된다. 4장에서 결과를 책 단위로 묶고 책방을 그 아래에 두기로 했으니, 책방 고르기도 결과 화면 안에서 책방 줄 옆의 "맡아 두기"를 누르는 일로 합쳐진다.

곱셈의 무서움

퍼널이 곱셈이라는 것은 단계 수가 지수로 작용한다는 뜻이다. 모든 단계의 계속 비율이 같은 값 \(p\)라고 단순하게 두면 \(n\)단계 뒤에 남는 비율은 \(p^n\)이다. 계속 비율이 90%인 단계는 하나만 보면 훌륭하다. 하지만 일곱 개가 이어지면 \(0.9^7 \approx 0.48\)로 절반이 떠난다. 남은 사람이 절반이 되는 단계 수를 반감 단계라고 부르면 다음처럼 쓸 수 있다.

아래 그래프의 굵은 곡선이 \(p^n\)이다. 슬라이더로 \(p\)를 바꾸고, 그래프 위를 끌어 단계 수 \(n\)을 고른다. 오른쪽 아래 두 칸은 같은 흐름에서 할 수 있는 두 가지 개선을 비교한다. 단계 하나를 아예 없애는 것과, 모든 단계를 조금씩(계속 비율을 2%포인트씩) 낫게 다듬는 것이다.

단계 하나를 없애면 그 단계의 이탈이 통째로 사라진다. 그래서 약한 단계가 하나 있는 흐름에서는 그 단계를 없애는 것이 가장 큰 개선이 된다. 반면 단계가 많고 모두 비슷하게 괜찮은 흐름에서는 하나를 없애도 조금 나아질 뿐이고, 모든 단계를 조금씩 다듬는 일이 큰 차이를 낸다. 어느 쪽이 나은지는 흐름의 모양에 달렸다. 퍼널을 그려 놓으면 그 모양이 보인다.

퍼널을 잴 때

실제 서비스의 퍼널은 사용 기록에서 센다. 각 단계에 들어온 사람의 수를 세고 나누면 계속 비율이 나온다. 간단해 보이지만 함정이 있다. 첫째는 표본이 적을 때의 흔들림이다. 하루에 스무 명이 들어오는 작은 서비스에서 어느 단계의 계속 비율이 80%로 나왔다면, 그 값은 70%일 수도 90%일 수도 있다. 같은 흐름을 같은 사람들이 다른 날 지나가도 숫자는 달라진다.

아래 시뮬레이터는 가입 없는 안(다섯 단계)의 참값을 정해 두고, 가상의 손님을 여러 명 지나가게 해서 퍼널을 "측정"한다. 막대가 이번에 잰 값이고, 가는 세로선이 참값이다. 회색 띠는 같은 인원으로 퍼널을 200번 다시 쟀을 때 가운데 90%의 값이 들어온 범위다.

작은 서비스일수록 퍼널 숫자 하나에 일희일비하기 쉽다. 하루치 숫자로 "이번 주에 인증 단계가 나빠졌다"고 판단하기 전에, 그 단계에 몇 명이 들어왔는지부터 본다. 숫자의 흔들림을 어떻게 다루는지, 차이가 우연인지 아닌지 어떻게 판단하는지는 9장에서 자세히 다룬다.

행복한 경로와 예외 경로

행복한 경로만 그린 흐름도는 서비스가 하는 약속의 절반만 담는다. 나머지 절반은 일이 틀어졌을 때 무슨 일이 일어나는가다. 이 길들을 예외 경로(Exception path, Unhappy path)라고 한다. 예외 경로를 그리지 않으면 실제로는 그 길이 없는 것이 아니라, 아무도 설계하지 않은 길이 생긴다. 손님은 요청 완료 화면을 본 뒤 아무 소식도 듣지 못하고, 가게에 갔다가 책이 없다는 말을 듣는다. 화면에는 오류가 하나도 없는데 서비스는 실패한 것이다.

"맡아 두기"에는 적어도 세 가지 예외가 있다. 서윤과 하린은 2장의 인터뷰와 관찰 기록에서 이 셋을 골랐다.

흐름도에서 나가는 화살표가 없는 상자를 막다른 길(Dead end)이라고 한다. 사용자가 그 상태에 들어가면 다음에 무엇을 할 수 있는지 알 수 없다. 예외 경로를 설계하는 기본 원칙은 단순하다. 모든 상태에는 출구가 있어야 하고, 그 출구는 사용자에게 보여야 한다. 출구는 대개 셋 중 하나다. 다시 시도하기, 다른 길로 가기(다른 책방), 깔끔하게 그만두기. 그리고 어느 쪽이든 사용자는 지금 무슨 일이 일어났는지 알아야 한다.

아래 시뮬레이터는 맡아 두기 요청 1,000건이 세 예외를 지나 어떤 결말에 이르는지 계산한다. "처리 없음"은 처음 흐름안 그대로다. 주인은 확인 버튼만 누를 수 있고, 손님에게는 요청 완료 뒤 아무 소식이 가지 않는다. "처리 있음"은 예외마다 출구를 낸 안이다. 처리 있음에서는 주인이 일정 시간 안에 확인하지 않으면 손님에게 "아직 확인 전"이라고 알리고 선택지를 준다. 그 시간 한도를 슬라이더로 바꾼다. 선의 굵기는 요청 수에 비례한다.

"처리 있음"에서도 책을 받은 손님 수가 크게 늘지는 않는다. 예외 처리는 마술이 아니다. 팔린 책은 팔렸고, 안 오는 손님은 안 온다. 바뀌는 것은 실패의 모양이다. 헛걸음은 손님에게 서비스 전체를 다시 쓰지 않을 이유가 되고, 흐지부지는 가게에게 책이 서가 밖에 묶여 팔 기회를 잃는 일이 된다. 반면 "그 책은 오늘 오전에 팔렸어요. 작은 숲에 같은 책이 있어요"라는 알림을 받은 손님은 실패를 겪었지만 서비스를 믿을 수 있다.

시간 한도는 정답이 없는 저울질이다. 한도가 짧으면 손님은 빨리 소식을 듣지만, 주인은 조금 늦었을 뿐인 요청까지 "확인 전" 알림이 나가 재촉받는 느낌을 받는다. 한도가 길면 손님이 기다린다. 이 저울질에는 네 책방의 사정이 들어간다. 주인 혼자 운영하는 한 줄은 손님을 응대하는 동안 휴대폰을 보지 못한다. 그래서 한도는 화면이 아니라 사람들과 합의해서 정할 값이다.

되돌리기와 확인

사용자가 마음을 바꾸거나 잘못 누르는 것도 흐름의 일부다. 손님은 맡겨 둔 책을 취소할 수 있어야 한다. 그런데 취소 버튼을 실수로 누르면, 헌책방 나무처럼 재고가 한 권뿐인 가게에서는 그 사이 다른 손님이 책을 맡길 수도 있다. 실수를 막는 흔한 방법은 두 가지다. 누르기 전에 묻는 확인 대화상자(Confirmation dialog)와, 누른 뒤에 되돌릴 수 있게 하는 되돌리기(Undo)다.

야코프 닐센의 사용성 휴리스틱 열 가지(Nielsen 1994) 가운데 "사용자 통제와 자유"는 실수로 들어간 상태에서 빠져나올 비상구, 즉 되돌리기와 다시 하기를 갖추라고 권한다. 인터페이스 설계자 제프 래스킨(Jef Raskin)은 『인간적인 인터페이스』(The Humane Interface, 2000)에서 확인 대화상자의 약점을 지적했다. 늘 같은 질문이 나오면 사람은 곧 질문을 읽지 않고 "예"를 누르는 습관을 들이고, 그러면 대화상자는 실수를 막지 못하면서 매번 한 번 더 누르게만 한다는 것이다. 래스킨은 그 대신 되돌리기를 권했다.

아래 시뮬레이터는 맡김 취소 100건을 점 100개로 그린다. 그 가운데 일부는 실수로 누른 것이다. 보호 방식을 바꾸면 실수 가운데 몇 건을 되찾는지, 그 대가로 사람들이 몇 번을 더 누르는지가 달라진다.

되돌리기가 늘 정답은 아니다. 되돌릴 수 없는 일에는 되돌리기를 붙일 수 없다. 문자 메시지를 이미 보냈거나, 다른 손님이 그 책을 이미 맡겼다면 시간을 되돌릴 수 없다. 이럴 때는 되돌리기 대신 일을 조금 늦추는 방법을 쓴다. 취소를 누르면 바로 책을 풀지 않고, 화면 아래에 "맡김을 취소했어요 · 되돌리기"를 몇 초 동안 띄운 뒤에야 실제로 처리한다. 그리고 확인 대화상자는 드물고 무거운 일, 되돌릴 수 없고 대가가 큰 일에 아껴 쓴다. 대화상자가 드물게 나올수록 사람들은 그것을 읽는다.

끊겨도 이어지게

흐름도는 사용자가 한 번에, 처음부터 끝까지 지나간다고 그리기 쉽다. 실제 휴대폰 사용은 끊김의 연속이다. 버스에서 내리고, 전화가 오고, 아이가 부른다. 특히 전화번호 인증은 흐름 안에 스스로 끊김을 만든다. 인증 번호를 보려고 문자 앱으로 갔다가 돌아오면, 휴대폰 브라우저가 메모리를 아끼느라 페이지를 새로 불러오는 일이 있다. 그러면 입력해 둔 것이 사라지고 손님은 검색부터 다시 해야 한다. 휴대폰 운영체제가 문자로 온 인증 번호를 키보드 위에 제안해 주는 기능도 있지만, 모든 기기와 브라우저에서 되는 것은 아니다.

끊긴 흐름을 지키는 방법은 임시 저장(Draft saving)과 이어 하기(Resume)다. 사용자가 입력하거나 고른 것을 그때그때 기기나 서버에 남겨 두고, 돌아왔을 때 떠난 자리에서 다시 시작하게 한다. 아래 시뮬레이터는 다섯 단계 흐름에서 두 종류의 끊김을 둔다. 단계마다 일정한 확률로 일어나는 일상의 끊김, 그리고 인증 단계에서 문자 앱을 다녀오는 동안 페이지가 처음으로 돌아가는 일이다.

이어 하기의 비용은 크지 않다. 고른 책과 책방, 입력한 전화번호를 기기에 잠시 남겨 두는 것으로 대부분 해결된다. 다만 무엇을 얼마나 오래 남길지는 신중하게 정한다. 전화번호 같은 개인정보를 기기에 오래 남기면, 같은 휴대폰을 쓰는 다른 사람이 볼 수 있다. 임시 저장은 흐름을 이어 줄 만큼만, 짧게 남긴다. 무엇을 모으고 얼마나 보관할지는 12장에서 다시 다룬다.

처음부터 손에 든 책까지

퍼널의 끝을 어디에 두느냐도 설계다. 처음안의 퍼널은 "요청 확인" 화면에서 끝났다. 그런데 손님이 원한 것은 요청 완료 화면이 아니라 손에 든 책이다. 요청을 많이 받는 서비스와 책을 많이 건네는 서비스는 같지 않다. 아래 종합 시뮬레이터는 이 장에서 본 모형을 이어 붙인다. 검색을 시작한 손님 1,000명이 흐름(퍼널)을 지나 요청을 남기고, 예외를 지나 결말에 이른다. 흐름안, 예외 처리, 이어 하기를 바꿔 가며 마지막 칸이 어떻게 달라지는지 본다.

어느 하나의 개선도 혼자서 모든 것을 바꾸지 않는다. 단계를 줄이면 들어오는 요청이 늘고, 예외 처리는 요청 뒤의 실패를 정직한 실패로 바꾸고, 이어 하기는 끊긴 사람을 데려온다. 흐름을 설계한다는 것은 이 셋을 한 그림 위에 놓고 보는 일이다. 그리고 그 그림의 마지막 칸은 화면이 아니라 사람의 결말이어야 한다. "요청 수"를 목표로 삼으면 요청만 늘리는 설계(예를 들어 재고가 불확실한 책도 일단 요청을 받기)가 좋아 보이게 된다. 무엇을 목표 숫자로 삼을지는 9장에서 다시 본다.

서윤의 서비스 노트