한 화면에 하나만 묻는 이유

1. 긴 신청서 앞에서 한숨이 나오는 이유

스크롤을 내려도 끝나지 않는 신청서를 만나면 시작하기도 전에 지칩니다. 이름, 연락처, 주소, 선택 항목이 한 화면에 빽빽하게 늘어서 있고, 다 채워 제출을 누르면 맨 위 어딘가에 빨간 글씨가 떠 있죠. 어디가 틀렸는지 찾느라 스크롤을 다시 올리다 보면 그냥 창을 닫고 싶어집니다. 잘 만든 서비스들은 이 문제를 한 화면에 질문을 하나만 두는 방식으로 풉니다. 영국 정부 디지털 서비스(GDS)는 이 방식을 One thing per page, 한 페이지에 하나라는 이름으로 정리했습니다. 2015년 디자인 블로그에 질문을 모두 별도 페이지로 나누는 데서 시작하라는 글을 올렸고, 지금도 GOV.UK 서비스 매뉴얼의 폼 설계 원칙으로 남아 있습니다.

2. 토스가 질문을 하나씩 건네는 방식

국내에서는 토스가 가장 익숙한 예입니다. 2018년 토스 피드에 실린 인터뷰를 보면, 가입 과정의 모든 화면에서 고객이 할 일을 단 하나로 제한한다는 이야기가 나옵니다. 송금도 비슷합니다. 금액을 정하면 누구에게 보낼지 묻고, 받는 사람을 고르면 그제야 보내기 버튼이 나타나는 식이었죠. 화면마다 묻는 말이 짧은 해요체 한 문장이라 금융 앱인데도 대화를 주고받는 느낌이 듭니다. 이 방식이 편한 건 판단을 한 번에 하나만 하게 해 주기 때문입니다. 지금 무엇을 해야 하는지 화면을 훑으며 고민할 필요가 없고, 잘못 입력하면 바로 그 화면에서 고치면 됩니다. 휴대폰처럼 좁은 화면일수록 이 차이는 더 크게 느껴지고요.

3. 화면이 늘어나는 만큼 생기는 비용

다만 공짜는 아닙니다. 질문을 쪼개면 화면이 늘고, 다음 버튼을 누르는 횟수도 늘어납니다. 매일 같은 양식을 반복해서 입력하는 직원용 시스템이라면 한 화면에 다 보이는 편이 오히려 빠를 수 있죠. 앞에서 뭐라고 답했는지 다시 보기 어렵다는 문제도 있습니다. 그래서 GOV.UK는 마지막에 모든 답을 모아 보여주고 항목마다 변경 링크를 다는 확인 페이지를 함께 권합니다. 오해하기 쉬운 점도 하나 있습니다. 하나라는 게 입력란 하나를 뜻하진 않는다는 겁니다. 연, 월, 일 세 칸으로 받는 생년월일도 하나의 질문이니까요. GOV.UK 매뉴얼 역시 한 페이지에 하나로 시작하되, 언제 합쳐도 되는지는 사용자 조사가 알려 줄 거라고 적어 두었습니다.

4. 세컨드펭귄의 시선: 질문 목록부터 적습니다

우리는 신청이나 예약 화면을 만들 때 입력란을 그리기 전에 질문 목록부터 적습니다. 꼭 물어야 하는 것과 나중에 물어도 되는 것을 나누고, 앞의 답에 따라 건너뛸 수 있는 질문에 표시를 합니다. 이 단계에서 생각보다 많은 질문이 빠집니다. 화면은 Next.js에서 질문 하나씩 넘어가는 흐름으로 만들고, 답은 단계마다 저장해 중간에 창을 닫아도 이어서 할 수 있게 합니다. 그렇다고 모든 화면을 쪼개지는 않습니다. 관리자 페이지처럼 익숙한 사람이 빠르게 처리해야 하는 곳은 한 화면에 모아 두는 게 맞으니까요. 폼 작업에서 가장 많은 시간을 쓰는 건, 사용자가 그때그때 하나만 생각하면 되도록 순서를 짜는 일입니다.