서비스를 만드는 사람에게 소개 페이지는 마지막에 붙이는 설명처럼 보일 수 있습니다. 하지만 고객 입장에서는 실제 서비스를 만나기 전의 첫 인터페이스입니다. 버튼이 눌리는 것만큼, 무엇을 누르고 어떤 결과를 기대할 수 있는지도 중요합니다.
기능 목록보다 사용자의 과제부터
기획, 제작, 자동화라는 단어만 나열하면 고객은 자신의 상황을 기능 이름으로 번역해야 합니다. ‘누구의 어떤 일을 돕는가’를 먼저 적으면 그 부담을 줄일 수 있습니다. 이것은 이해하기 쉬운 안내를 위한 편집 제안이며 성과 측정 결과는 아닙니다.
가상의 서비스 예시로 ‘반복되는 상담 안내를 정리하려는 1인 사업자를 위해, 상담 절차와 준비 사항을 담은 문구 초안을 작성한다’를 생각해 보세요. 무엇을 맡길 수 있는지 드러납니다. 실제 상품의 기능이나 고객 사례를 설명하는 문장은 아닙니다.
완료 상태를 문장으로 표현하기
개발할 때 작업 완료 조건을 정하듯, 소개에서도 고객이 받는 결과를 정합니다. ‘페이지 제작’ 뒤에 편집 가능한 파일 전달인지, 공개 주소까지 제공하는지 적습니다. 파일 형식이나 관리 범위가 달라진다면 확인이 필요한 항목으로 구분하세요.
- 고객이 준비할 자료
- 전달할 결과물
- 포함하지 않는 작업
- 검토와 수정이 이루어지는 단계
이 네 가지가 모호하면 화면은 완성돼도 기대는 서로 다를 수 있습니다. 범위를 숨기고 문의를 받는 대신 실제 제공하는 기준을 보여 주는 편이 정확합니다.
문의 폼의 빈 상태도 설계하기
희망 일정과 요구사항을 필수 입력으로 받으면서 아직 모르는 고객은 고려하지 않는 경우가 있습니다. 필요한 항목만 요청하고 ‘미정’이라는 답을 허용할 수 있는지 확인하세요. 필요하지 않은 개인정보나 비밀번호를 첫 문의 폼에 요구하지 않습니다.
‘무엇을 만들고 싶은지와 희망 일정을 적어 주세요. 아직 정하지 못한 항목은 미정이라고 남겨도 됩니다.’ 같은 문구가 입력을 시작하는 단서가 됩니다. 실제 운영 방식에 맞게 수정할 작성용 예시입니다.
페이지 밖의 설명 없이 확인하기
소개를 처음 보는 사람이 대상, 결과물, 문의 방법을 페이지 안의 문장만으로 찾을 수 있는지 확인합니다. 설명을 덧붙여야 한다면 그 내용을 적절한 구역에 넣습니다. 첫 화면에는 대상과 결과물, 다음 구역에는 범위와 진행, 문의 구역에는 준비 정보를 배치할 수 있습니다.
이 테스트는 안내의 이해도를 보는 작은 점검이며 구매 의사를 검증하지 않습니다. 소개 페이지도 상세 견적이나 계약 조건을 대신하지 않습니다.
더 긴 예시와 작성용 틀은 고객의 다섯 질문으로 서비스 소개를 구성하는 원문 가이드에서 확인할 수 있습니다. 제품 화면을 다 만든 다음에야 소개를 쓰기보다, 제공할 결과와 책임 경계를 먼저 문장으로 적어 보면 어떨까요?
