스테퍼

입력 칸 스무 개가 한 화면에 깔린 폼이 흔했습니다. 스크롤을 다섯 번 내려야 제출 버튼이 나오는 화면을 열면 사람은 먼저 길이를 재고, 길다고 판단하면 시작하지 않습니다. 사업자 정보를 받는 폼에서 절반쯤 채우다가 "이거 언제 끝나요" 하고 창을 닫는 일이 반복됐습니다.

그래서 화면을 나누기로 했습니다. 스무 칸을 다섯 칸씩 네 화면으로 쪼개면 한 화면은 가벼워집니다. 그런데 나누기만 하면 더 나빠지는 경우가 있었습니다. 다음을 눌러 넘어가도 앞으로 몇 번을 더 눌러야 하는지 알 수 없으니, 끝이 보이지 않는 통로를 걷는 느낌이 됩니다. 스무 칸을 한 번에 보는 것보다 불안이 큽니다.

나누는 일과 위치를 알려 주는 일이 한 묶음이어야 했습니다. 스테퍼가 그 묶음의 이름입니다. 과정을 끊어 주면서 전체가 몇 칸이고 지금 몇 번째이며 어디를 지나왔는지를 같은 화면에 함께 둡니다.

과정을 몇 개의 단계로 끊고, 화면 위쪽에 단계 목록을 깔아 지금 위치를 표시합니다. 만들 때 정해야 하는 것은 다섯 가지입니다.

1. 단계 수를 정합니다. 셋에서 다섯이 보통입니다. 둘이면 나눌 이유가 없고, 일곱을 넘으면 목록이 화면 폭에 들어가지 않아 위치 표시가 제 역할을 못 합니다. 칸이 모자라면 비슷한 것끼리 묶어 줄입니다.
2. 단계마다 이름을 붙입니다. "1단계" 가 아니라 "회사 정보", "결제 수단" 처럼 무엇을 하는 칸인지 적습니다. 이름이 있으면 사용자가 뒤에 무엇이 남았는지 미리 알고, 필요한 서류를 먼저 준비합니다.
3. 세 가지 상태를 다르게 그립니다. 지나온 단계에는 체크 표시를, 현재 단계는 강조해서, 아직 오지 않은 단계는 흐리게 둡니다. 세 상태가 같은 모양이면 목록이 있어도 위치를 읽을 수 없습니다.
4. 되돌아갈 수 있는지 정합니다. 지나온 단계는 눌러서 돌아갈 수 있게 열어 두고, 돌아갔을 때 이미 넣은 값이 남아 있어야 합니다. 값이 지워지면 사용자는 두 번째 단계를 고치려다 첫 단계를 다시 채우게 됩니다.
5. 단계마다 저장합니다. 마지막 제출에서만 저장하면 3단계에서 창을 닫은 사용자는 처음부터 다시 시작합니다.

검증 시점도 이 요소의 규칙에 들어갑니다. 값이 맞는지는 다음 버튼을 누를 때 그 단계 안에서만 봅니다. 마지막에 몰아서 검사하면 오류 목록에 3단계 항목이 섞여 나오고, 사용자는 어디로 돌아가야 하는지 찾아 헤맵니다.

접근성에서는 단계가 바뀔 때 포커스를 새 단계의 첫 입력 칸으로 옮겨 주는 처리가 필요합니다. 포커스는 키보드로 선택된 상태를 말하는데, 이 처리를 빼면 다음 버튼을 누른 뒤에도 선택된 자리가 이전 화면에 남아 키보드만 쓰는 사용자는 새 단계에 닿지 못합니다.

순서를 반드시 지켜야 하고 끝이 정해진 과정에 씁니다. 가입과 초기 설정, 주소에서 배송 방법을 거쳐 결제로 가는 흐름, 사업자 인증처럼 앞 단계의 답에 따라 뒤 단계의 내용이 달라지는 절차가 대표적입니다. 개인 사업자인지 법인인지를 1단계에서 고르면 2단계에서 받을 서류가 달라지는 식입니다.

안 쓰는 자리가 더 분명합니다. 순서 없이 아무 데나 먼저 봐도 되는 내용은 탭으로 갈아 끼웁니다. 설정 화면의 일반·알림·보안은 서로 앞뒤가 없으니 단계로 만들면 안 됩니다. 항목이 많아 길기만 한 목록은 페이지네이션으로 쪽을 나누고, 평소에는 접어 두어도 되는 보조 정보는 아코디언으로 접습니다.

작은 화면에서는 단계 이름을 다 보여 줄 폭이 없습니다. 이름을 잘라 붙이면 무슨 단계인지 알 수 없으니, 대개 현재 단계의 이름만 크게 쓰고 나머지는 "2/4" 처럼 숫자로 줄입니다. 숫자만 남겨도 전체 길이와 현재 위치는 전달됩니다.

"단계가 일곱 개예요. 비슷한 걸 묶어서 넷으로 줄이죠."

단계 수 자체가 부담이니 개수를 줄이자는 제안입니다.

"마지막에 몰아서 검사하니까 오류 하나 때문에 3단계로 돌아가야 해요."

검증을 단계별로 옮겨야 한다는 지적입니다.

"이 셋은 순서가 없는데요. 탭으로 하는 게 맞습니다."

과정이 아니라 분류이니 다른 요소를 쓰자는 말입니다.

페이지덱은 기업 고객의 초기 설정을 스테퍼로 만들었습니다. 회사 정보, 구성원 초대, 권한 규칙, 결제 수단 네 단계입니다. 처음 만들 때는 일곱 단계였는데 민서가 사용성 테스트에서 3단계에서 그만두는 사람이 절반이라는 결과를 받고 넷으로 묶었습니다.

태오가 구현할 때 단계마다 저장하는 처리를 넣었고, 그 덕에 수아가 고객과 통화하면서 "지금 2단계까지 되어 있네요" 라고 확인할 수 있게 됐습니다. 중간에 멈춘 고객에게 어디서 멈췄는지 물어볼 필요가 없어진 셈입니다.

잘게 쪼갤수록 좋다고 보는 경우가 가장 많습니다. 한 화면에 칸이 적어지니 부담이 줄어 보이고, 실제로 화면 하나만 떼어 놓고 보면 그렇습니다. 그런데 사용자가 재는 것은 화면 하나의 길이가 아니라 남은 단계 수입니다. 스무 칸을 일곱 단계로 쪼개면 각 화면은 가벼워지지만 목록에 일곱 칸이 보이고, 세 번째 칸에서 아직 절반도 안 왔다는 사실이 눈에 들어옵니다. 단계를 늘려 이탈률이 오르는 일이 드물지 않고, 그래서 개수를 줄이는 쪽이 대개 먼저 시도할 일입니다.

되돌아가지 못하게 막는 편이 낫다고 보는 시각도 자주 나옵니다. 앞 단계 값이 뒤 단계 내용을 정하는 구조라면 뒤에서 앞을 고치는 것이 복잡해지니, 막아 두면 데이터가 깨끗해질 것 같습니다. 실제로는 사용자가 오타 하나를 고치려고 전체를 포기합니다. 사업자 번호를 한 자 잘못 넣은 사람이 돌아갈 방법을 못 찾으면 창을 닫고 다시 시작하거나 아예 그만둡니다. 앞 단계를 고치면 뒤 단계를 다시 확인하게 만드는 편이, 고치는 길을 막는 것보다 언제나 적게 잃습니다. 앞을 고쳤을 때 영향을 받는 뒤 단계만 비워 두고 다시 채우게 하는 처리가 그 방법입니다.