처음 쓰는 사람에게 기능 설명보다 첫 결과가 먼저다

새 서비스를 열면 소개 화면, 기능 목록, 사용법 안내가 차례로 나오는 경우가 있습니다. 만드는 사람은 친절하게 설명했다고 생각할 수 있지만, 방문자는 아직 자신이 하려던 일을 시작하지도 못했습니다. 설명이 필요하더라도 첫 화면에서 모두 읽게 해야 하는지는 따로 판단해야 합니다.

종이배 접기를 배우러 온 사람에게 종이의 역사와 접는 방식 열 가지를 먼저 읽히는 장면을 떠올려 보세요. 작은 배 하나를 실제로 접어 본 뒤 필요한 부분을 다시 배우면 다음 설명의 뜻이 선명해집니다. 웹서비스에서도 첫 유용한 결과를 이 종이배 한 척처럼 정할 수 있습니다.

첫 결과는 가입 완료와 다르다

첫 결과는 사용자가 해결하려던 문제에서 처음으로 쓸 만한 답을 얻은 순간입니다. 회원가입 버튼을 누르거나 모든 소개 화면을 넘긴 것만으로 그 순간이 오지는 않습니다. 장보기 목록 도구라면 목록을 입력해 중복 품목이 합쳐진 화면을 보는 일이 첫 결과가 될 수 있습니다. 저장 기능이나 팀 공유는 그다음 이야기입니다.

처음부터 거창한 성과를 약속할 필요는 없습니다. 사용자가 자기 입력과 출력의 관계를 눈으로 이해할 수 있는 작은 단위면 충분합니다. 반대로 결과가 실제로 쓰기 어려운 장식용 미리 보기라면 단계만 짧아도 가치 확인이라고 부르기 어렵습니다. 시작 화면을 설계하기 전에 “사용자는 무엇을 한 번 끝내고 나서 이 도구를 이해했다고 말할까”를 한 문장으로 적어 봅니다.

시작 화면은 할 일과 첫 행동을 보여 준다

GOV.UK Design System은 서비스 시작 지점에서 이용자가 무엇을 할 수 있는지와 자기 필요에 맞는지 알 만큼만 설명하고, 실제 행동과 맞는 버튼 이름을 쓰도록 안내합니다. 이 원칙을 작은 웹서비스에 옮기면 첫 화면에는 대상, 해결할 일, 시작 버튼이 먼저 보입니다. 사용 전에 꼭 알아야 할 비용이나 준비물도 있다면 숨기지 않고 함께 적습니다.

“모든 기능 살펴보기”보다 “장보기 목록 정리하기”가 첫 행동을 더 분명하게 말합니다. 버튼을 눌렀을 때 곧바로 목록을 적을 수 있어야 문장과 행동이 이어집니다. 버튼 뒤에 다시 긴 소개와 같은 내용의 동의 화면이 반복된다면 방문자가 실제로 가야 할 길은 아직 시작되지 않은 셈입니다.

첫 결과까지의 단계를 종이에 그려 본다

현재 화면을 예쁘게 다시 그리기 전에 방문자의 이동을 짧은 문장으로 적어 봅니다. 예를 들어 “첫 화면 열기 → 소개 넘기기 → 계정 만들기 → 메일 확인 → 설정 고르기 → 목록 입력 → 결과 보기”입니다. 각 단계가 결과를 만드는 데 정말 필요한지 물으면 없애거나 뒤로 옮길 수 있는 과정이 보입니다.

가입이 저장과 동기화에 필요하더라도, 임시 입력으로 결과를 먼저 보여 준 뒤 저장할 때 가입하게 만들 수 있는지는 검토할 만합니다. 다만 개인정보나 결제 상태를 다루는 서비스라면 인증을 무조건 뒤로 미루면 안 됩니다. 해당 기능의 접근 권한, 보관 정책, 실제 비용을 확인한 뒤 안전한 순서를 정해야 합니다. 짧은 길이 항상 좋은 길은 아니며, 사용자가 예상하는 결과와 안전 조건을 함께 지키는 길이어야 합니다.

빈 화면에는 다음 입력과 예상 결과를 붙인다

아무 데이터도 없는 첫 화면에 빈 표와 여러 메뉴만 있으면 무엇부터 해야 할지 알기 어렵습니다. 설명용 큰 창을 띄우는 대신 그 자리에서 넣을 값과 다음에 보일 결과를 한 문장으로 알려 줍니다. 다음은 실제 개인 정보를 요구하지 않는 화면 문구 예시입니다.

입력 안내: 장볼 품목을 한 줄에 하나씩 적어 보세요.
예시 입력: 사과, 우유, 사과
버튼: 목록 정리하기
예시 결과: 사과 2개, 우유 1개

예시를 눌러 시험할 수 있다면 사용자는 입력 형식을 외우지 않고도 첫 결과를 볼 수 있습니다. 다만 예시 결과가 실제 계산 결과인 것처럼 오해되지 않게 예시임을 표시합니다. 도구가 처리하지 못하는 입력이나 제한도 결과 가까이에 알려 줘야 다음 행동을 판단할 수 있습니다.

설명은 막힌 지점에서 다시 찾을 수 있게 둔다

온보딩은 처음 쓰는 사람의 시작을 돕는 안내 과정입니다. Nielsen Norman Group은 사용자가 일하려는 순간 나타나는 긴 튜토리얼이 작업을 끊고 기억에도 오래 남지 않을 수 있다고 설명합니다. 필요한 순간에 열 수 있는 맥락 도움말, 쉽게 닫고 다시 찾을 수 있는 안내를 권합니다.

예를 들어 입력 형식이 틀렸다면 첫 방문 때 모든 형식을 외우게 하기보다 해당 칸 옆에서 올바른 예를 보여 줍니다. 결과를 저장하려는 순간에는 그때 필요한 계정 설명을 꺼낼 수 있게 합니다. 도움말을 숨기거나 제거한다는 뜻은 아닙니다. 지금 하는 일과 이어지는 자리에 두고, 지나간 뒤에도 다시 열 수 있어야 합니다.

완료 버튼보다 결과 화면을 확인한다

시작 흐름의 길이는 화면 수만 세면 오해하기 쉽습니다. 한 화면 안에 낯선 선택이 열 개라면 여러 화면보다 더 어려울 수 있습니다. 첫 행동을 시작했는지, 결과가 실제로 나타났는지, 사용자가 결과를 이해했는지 차례로 살펴봅니다. 사용자가 멈춘 위치와 그때 본 문장을 함께 보면 무엇을 줄여야 하는지 알 수 있습니다.

측정할 때는 결과를 본 사람과 단순히 가입한 사람을 섞지 않습니다. 결과가 표시됐어도 오류가 많거나 기다림이 길다면 성공이라고 단정하지 않습니다. 사람 수가 적을 때는 비율 하나로 결론을 내리기보다 화면을 함께 보고 어떤 표현과 단계에서 멈췄는지 기록합니다. 이후 화면을 바꿔 비교할 때도 질문과 변화는 한 가지씩 정합니다.

편리한 시작에도 안전 경계가 있다

예시 기능을 만들 때 실제 고객 목록, 비밀번호, API 비밀키를 견본 입력으로 넣지 않습니다. 기록과 화면 캡처에도 이런 값이 남지 않게 합니다. 결과를 먼저 보여 주려는 이유로 결제 동의를 생략하거나 실제 요금과 환불 조건을 뒤로 숨겨서는 안 됩니다. 삭제나 외부 전송처럼 되돌리기 어려운 행동도 첫 경험을 짧게 만든다는 이유로 자동 실행하면 안 됩니다.

개발 도구가 제안한 명령을 이해하지 못했다면 따라 입력하지 말고 현재 폴더, 대상 파일, 변경 범위를 먼저 확인합니다. 사용 흐름을 바꿀 때도 시험용 자료에서 시작하고, 로그인·결제·삭제가 얽힌 실제 계정은 담당자와 확인한 뒤 다룹니다. 사용자가 빨리 도착하는 길과 사용자가 안전하게 도착하는 길이 같은지 보는 것이 중요합니다.

오늘 바로 해볼 작은 실습

코드를 고치거나 실제 결제를 진행하지 않고, 지금 있는 서비스의 첫 사용 흐름을 10분 동안 종이에 적어 봅니다.

1. 처음 방문한 사람이 해결하려는 일을 한 문장으로 씁니다.
2. 그 일을 끝냈다고 볼 작은 첫 결과를 한 문장으로 정합니다.
3. 첫 화면부터 그 결과까지 누르거나 입력하는 단계를 순서대로 적습니다.
4. 각 단계 옆에 결과 전에 꼭 필요한 이유가 있는지 표시합니다.
5. 처음 보는 버튼 이름이 다음 화면의 행동과 같은 뜻인지 읽어 봅니다.
6. 빈 화면에서 무엇을 입력할지와 어떤 결과를 받을지 보이는지 확인합니다.
7. 설명이 필요한 곳과 나중에 다시 찾을 도움말 위치를 표시합니다.
8. 비밀 정보, 실제 결제, 삭제가 끼어 있다면 실습을 멈추고 시험 환경과 담당자를 확인합니다.

첫 결과가 정해지면 안내 문구의 역할도 달라집니다. 기능을 많이 소개하는 대신 지금 할 일 한 가지를 시작하게 하고, 필요한 설명을 바로 그 길 위에 놓으면 됩니다.