안에서부터 구축하는 SaaS 웹사이트: 가격과 문서가 먼저인 이유

요약

SaaS 웹사이트에 대한 대부분의 조언은 홈페이지에서 시작하고 가격, 문서, FAQ는 부차적인 것으로 남겨둔다. 그래서 그 페이지들이 서로 모순되는 결과를 낳는다. 이 글은 안에서부터 구축하는 것을 주장한다: 제품의 실제 제약 조건이 담긴 가격 페이지와 API 문서에서 시작해 그로부터 모든 것을 도출하라는 것이다. 6단계 프레임워크를 제시한다: 제약 조건 수집, 가격 페이지를 골격으로 구축, API 문서를 제품 표면으로 취급, 워크플로에서 기능 쇼케이스 도출, 실제 대화에서 FAQ 수집, 일관성 검사로 마무리. 이 접근법은 서로 다른 클라이언트에게 반복 가능한 프로세스가 필요한 에이전시를 위해 설계되었다. 또한 프레임워크가 과한 경우와 클라이언트 기대를 관리하는 방법에 대한 주의사항도 포함한다.

SaaS 웹사이트 구축에 대한 대부분의 조언은 거꾸로 되어 있다. 홈페이지(히어로, 헤드라인, 제품 스크린샷)에서 시작하고, 가격, 문서, FAQ는 디자인이 승인된 후에 채우는 페이지로 취급하라고 말한다. 그러다 몇 주 후에는 "모든 것이 무제한"이라는 헤드라인의 약속과 가격 페이지의 실제 사용량 상한을 조정해야 하고, 기능 섹션은 API 문서에조차 언급되지 않은 베타 기능을 자랑스럽게 소개하고 있다. 그 순서는 제품이 조정이 필요 없을 만큼 단순할 때만 작동하는데, 그런 경우는 드물다. 실제로 작동하는 방법은 — 특히 완전히 다른 클라이언트에게 반복적으로 이 작업을 할 때 — 사이트를 안에서부터 구축하는 것이다: 가장 제약이 많고 가장 화려하지 않은 페이지(가격 및 API 문서)에서 시작해 그 페이지들이 홈페이지, 기능 쇼케이스, FAQ를 생성하게 하라. 그렇게 하기 위한 6단계 프레임워크가 여기 있으며, 그 과정에서 불편해지는 부분을 지적하겠다. 왜냐하면 실제로 불편하기 때문이다.

차이점을 빠르게 지도처럼 보여주겠다. 전체 논증이 그것에 기대기 때문이다:

	페이지 우선(가장 일반적)	제약 우선(이 프레임워크)
시작 지점	홈페이지 히어로와 비주얼	가격 페이지와 API 문서
카피를 결정하는 것	브랜드 스토리와 디자인	제품의 실제 한계와 워크플로
기능 쇼케이스	제품이 하는 모든 것을 나열	실제 사용자가 이용하는 경로를 따름
FAQ	마지막에 추측으로 작성	지원 및 영업에서 수집
출시 시 결과	일관성 없는 주장, 숨은 갈등	페이지가 하나의 제품으로 읽힘

1단계 — 한 단어도 쓰기 전에 가격 페이지부터 읽어라.

클라이언트가 기능 목록, 브랜드 덱, 데모 링크를 건네주며 홈페이지를 요청한다. 첫 번째 통화가 끝날 무렵이면 히어로 카피와 색상 구성을 논의하고 있다. 속도를 늦춰 보라. 가격 페이지와 요금제 한도를 요청하라 — 그것이 메모가 적힌 Google 문서에 불과하더라도 — 그러면 프로젝트 전체가 바뀌는 것을 발견하게 될 것이다.

찾아야 할 것은 확고한 제약 조건이다: 시트가 무엇을 의미하는지, 데이터 사용량이 어떻게 계산되는지, 어떤 기능이 어떤 요금제 수준에 존재하는지, API가 있는지 그리고 실제로 무엇을 할 수 있는지. 이러한 제약 조건이 근본 진실이다. 나중에 하는 모든 마케팅 주장은 이 제약 조건과 맞닥뜨려도 버텨야 한다.

전형적인 시나리오가 있다. 클라이언트가 시간 추적 도구를 만들고 있다: 무료 요금제, 프로 요금제, 엔터프라이즈 요금제. 영업 자료에는 "어떤 팀에도 확장 가능"이라고 되어 있다. 프로 페이지에는 "무제한 프로젝트"라고 적혀 있다. 그러나 지원 팀은 프로 계정이 실제로 워크스페이스당 활성 프로젝트 10개로 제한된다고 확인하고, API 문서에는 프로젝트당 최대 50명의 멤버가 있다고 나와 있다. 누군가 이 문제를 해결하기 전에는 홈페이지가 작성되지 않는다. 왜냐하면 "무제한 프로젝트"는 이제 카피 문제가 아니라 법적 문제이기 때문이다. 홈페이지부터 시작했다면 히어로에 "무제한 프로젝트"라고 썼을 것이고, 디자인이 승인된 후 2주가 지나서야 갈등을 발견했을 것이다. 제약 조건에서 시작한다는 것은 갈등이 수정 비용이 없는 1주차에 드러난다는 뜻이다.

이 단계에서 정확히 무엇을 모아야 할까? 요금제 정의와 요금제별 기능 비교 표. API 문서 또는 최소한 API가 할 수 있는 것과 할 수 없는 것의 목록. 지원 팀의 가장 흔한 질문(5단계에서 더 자세히). 영업 자료 — 단, 영업 자료는 판타지가 사는 곳이라는 주의사항을 염두에 둘 것. 그리고 실제 제품 — 한도가 적용되는 설정 페이지를 볼 수 있도록 열어보라. 제품 자체가 최종 권위자이기 때문이다. "최대 10개 프로젝트"라고 표시된 설정 화면은 어떤 스프레드시트보다 우선한다.

이 단계는 산출물을 만들지 않는다. 다른 모든 페이지를 대조할 사실 목록(한계, 정의, 예외)을 만든다. 에이전시에게 이 단계는 반복 가능한 작업과 불끄기를 구분하는 단계이기도 하다. 제약 조건을 공유 문서에 적어 두면 앞으로의 모든 페이지 업데이트가 참조할 진실의 원천이 구축된다.

2단계 — 가격 페이지를 사이트 전체의 골격으로 구축하라.

가격 페이지는 시작 지점처럼 느껴지지 않는다. 숫자와 요금제 이름이 있는 표 — 사이트에서 가장 화려하지 않은 페이지다. 그러나 가격 페이지는 제품과 사용자 간의 계약이며, 사이트 전체의 정보 구조가 결정되는 곳이다. 사이트의 역할이 방문자가 가입할 준비가 될 때까지 교육하는 것이라면, 가격 페이지는 그 교육이 수렴되는 지점이다. 구매 결정에 중요한 모든 기능이 그곳에 이름을 갖고 있고, 중요한 모든 한도가 명시되거나 링크되어 있다.

시간 추적 도구를 예로 들어 보자. 무료, 프로, 엔터프라이즈의 세 가지 요금제가 있다. 표에는 제품이 실제로 어떻게 분할되는지 반영하는 열(프로젝트 수, 통합, 보고 깊이)이 필요하다. 각 셀에는 이상적인 값이 아니라 정직한 값이 필요하다. 프로에 활성 프로젝트 10개가 포함된다면 셀에는 활성 프로젝트 10개라고 표시하고, "활성"이 무엇을 의미하는지와 한도에 도달하면 어떻게 되는지 설명하는 가격 FAQ에 링크한다. 여기서 더 어려운 결정 중 하나는 방문자에게 가장 구매를 원하는 요금제에 대해 무엇을 말할지다. 많은 가격 페이지는 앵커 요금제를 분명하게 만든다 — 강조 표시하고 "가장 인기 있음" 배지를 붙인다 — 그리고 그 주변 카피는 왜 그 요금제가 이 방문자에게 적합한지 설명한다. 시간 추적 도구의 경우 프로가 앵커다: 통합과 보고 깊이가 실제로 시작되는 지점이므로, 방문자가 표를 읽고 스스로 결론을 내릴 것이라고 가정하지 말고 페이지가 그 이유를 명시적으로 제시해야 한다.

또한 이 단계에서 사이트 전체에 걸쳐 표준이 될 용어를 결정한다. 제품이 그룹을 가격 페이지에서 "워크스페이스"라고 부르는데 마케팅 카피가 "팀"이라고 한다면, 이후의 모든 페이지가 그 불일치를 물려받는다. 가격 페이지를 먼저 쓰면 어휘를 선택할 수밖에 없으며, 제품 자체가 사용하는 어휘를 선택해야 한다 — 제품과 문서가 일치해야 하고 마케팅 사이트가 굴복할 수 있는 쪽이기 때문이다.

가격 페이지에는 자체 FAQ도 필요하다. 거기에 속한 질문은 요금제의 특정 작동 방식과 관련된 것들이다: 무엇이 시트로 간주되는지, 다운그레이드 시 어떻게 되는지, 청구가 연간인지 월간인지, 프로젝트에서 "활성"이 무엇을 의미하는지. 전환을 위한 가격 페이지 구조에 대한 잘 정립된 관행이 있으며, 그 작동 방식을 공부할 가치가 있다. 그러나 이 프레임워크 안에서 가격 페이지의 역할은 단지 전환만이 아니다 — 다른 모든 페이지가 따를 사실적 결정을 고정하는 것이다. 더 깊은 작동 방식을 원한다면 SaaS 가격 페이지를 수정하는 이 가이드에서 자세히 다룬다.

3단계 — API 문서를 매뉴얼이 아닌 제품 표면으로 취급하라.

개발자가 시간 추적 도구를 평가하고 있다. 그들의 회사는 타임시트를 급여 시스템으로 자동으로 가져와야 한다. 문서는 엔드포인트별로 알파벳순으로 정리되어 있다: /projects, /reports, /timesheets, /users. 개발자는 어떤 호출로 시작해야 할지 전혀 모르고, "인증" 섹션은 그들이 가지고 있지 않은 지식을 가정한다 — 문서는 설정 페이지의 "통합"에서 API 키를 생성한다는 것을 설명하지 않는다. 개발자는 제품이 깔끔하게 통합되지 않을 것이라고 확신하며 탭을 닫는다. 그런데 필요한 모든 정보가 문서에 존재했다; 단지 참조 매뉴얼이 사용할 순서로 정리되어 있었을 뿐, 사람이 사용할 순서가 아니었다.

워크플로로 구성된 문서라면 결과가 달라졌을 것이다: "빠른 시작", "인증", "타임시트 가져오기", "프로젝트 만들기", "웹훅 및 동기화". 각 섹션은 작업을 먼저 제시한 다음 엔드포인트를 보여준다. 빠른 시작은 5분이면 따라 할 수 있고 성공적인 API 호출을 만들어 낼 수 있다 — 이는 무료 체험에 해당하는 문서다. 개발자 우선 제품에게 이 페이지는 사이트에서 가장 설득력 있는 페이지다.

API가 있는 SaaS라면, 계획하지 않았어도 문서는 웹사이트의 한 페이지다. Stripe, GitHub, Twilio 같은 곳이 세운 업계 벤치마크는 제품처럼 읽히는 문서다: 사용 가능한 엔드포인트뿐 아니라 개발자가 하려는 작업을 설명한다. 원칙은 API 문서가 제품 경험의 일부이며 사이트의 나머지 부분과 동일한 안에서부터의 논리를 따라야 한다는 것이다: 개발자가 수행할 수 있는 작업에서 시작해 그 다음에 작동 방식을 드러내라.

에이전시에게 얻는 보너스는 이런 방식으로 문서를 작성하면 제약 조건 목록이 표면으로 드러난다는 것이다 — API가 실제로 무엇을 할 수 있는지, 속도 제한이 어디 있는지, 어떤 엔드포인트가 누락되었는지 — 그리고 마케팅 페이지에 나타나기 전에 그 갈등을 발견할 수 있다. API 문서가 이 클라이언트 사이트의 주요 부분이라면 개발자가 실제로 사용하는 문서 작성에 대한 더 심층 가이드가 있다.

4단계 — 기능 목록이 아닌 워크플로에서 기능 쇼케이스를 도출하라.

클라이언트가 40개의 기능이 담긴 스프레드시트를 이메일로 보내며 기능 페이지를 요청한다. 쉬운 대답은 그리드다: 아이콘과 캡션이 있는 40개 항목. 결과는 철저해 보이지만 소음으로 읽힌다. 그리드에는 이야기가 없기 때문이다. 아무도 모든 기능을 배우기 위해 SaaS 웹사이트를 방문하지 않는다. 그들은 이 제품이 자신이 찾아온 바로 그 작업을 수행하는지 알아보기 위해 방문한다. 따라서 쇼케이스는 기능 목록이 아닌 워크플로에서 구축되어야 한다.

예를 들어 보자. 시간 추적 도구에서 가장 흔한 성공 경로는 클라이언트의 지원 팀에 따르면, 팀 리드가 가입하고 동료 세 명을 초대하고 프로젝트를 만들고 주말에 보고서를 실행하는 것이다. 그것이 워크플로다. 기능 쇼케이스는 그 흐름을 따라야 한다: 팀 초대에 관한 섹션(시트와 역할 다루기), 프로젝트 설정에 관한 섹션(템플릿과 프로젝트 설정 다루기), 보고 대시보드에 관한 섹션(차트와 내보내기 옵션 다루기). 각 섹션은 제품의 그 정확한 순간의 스크린샷을 보여준다. 자주 사용되지 않는 설정 패널의 잘린 스크린샷이 아니라. 방문자는 자신의 경로를 보게 되고, 그 과정에서 보게 되는 기능은 자신에게 중요한 기능들이다.

약간 다른 방문자를 위한 후속 워크플로는 도구를 직접 사용하지 않는 임원이다: 그들은 타임시트를 승인하고 주간 보고서를 검토한다. 쇼케이스는 이야기를 깨지 않고 마지막에 그 방문자를 위한 섹션 — "관리자용" — 을 추가할 수 있다. 보통 두 개의 워크플로로 시작하면 충분하다; 모든 페르소나에 대해 하나씩 필요하지 않다.

주의사항 — 진짜 주의사항 — 은 워크플로 기반 쇼케이스는 일반적인 워크플로가 실제로 무엇인지 알아야 한다는 것이다. 이를 위해서는 PM만이 아니라 지원 및 영업과 대화해야 한다. 클라이언트가 사람들이 제품을 사용하는 상위 세 가지 방식을 말해줄 수 없다면, 그것이 가장 먼저 고쳐야 할 것이다. 웹사이트가 그렇지 않으면 추측할 것이기 때문이다. 이 단계는 종종 제품에 명확한 기본 워크플로가 없다는 것을 드러낸다 — 이는 웹사이트 문제가 아니라 제품 문제다. 솔직하게 지적하라; 웹사이트는 존재하지 않는 워크플로를 만들어낼 수 없다. 이러한 워크플로를 체계적으로 정렬하려면 전환을 위한 기능 쇼케이스 구조에 관한 이 글이 결정 순서를 안내한다.

5단계 — 상상이 아닌 지원 및 영업에서 FAQ를 수집하라.

사이트 출시가 이틀 남았는데 FAQ가 여전히 비어 있다. 직관은 오후에 10개의 질문을 쓰는 것이다 — 보통 실제 고객이 묻는 질문이 아니라 제품이 답하길 원하는 질문들이다. 그것은 거꾸로다. FAQ는 특정한 임무가 있다: 방문자와 가입 사이의 마지막 망설임을 제거하는 것이다. HubSpot, Slack, Zendesk에서 볼 수 있는 것과 같은 효과적인 FAQ 페이지는 실제 쿼리를 중심으로 구성되고, 검색 가능하며, 간결하기 때문에 작동한다. 그것은 듣기의 산물이지 발명의 산물이 아니다.

현실적인 시나리오: 가격 페이지에 있고, 시간 추적 도구의 가장 큰 걸림돌이 통합이라는 것을 알고 있다: "QuickBooks와 호환되나요?" 지원 로그를 검토해 보면 그것이 가장 흔한 사전 판매 질문이다. 그 질문과 답변은 가격 페이지 FAQ에 속한다. 판매 전화에서 두 번째로 흔한 질문은 "취소하면 내 타임시트는 어떻게 되나요?"이다. 그것도 거기에 속한다. 각 답변은 판매 주기를 단축하고 지원 부담을 줄인다. 답변을 글로 본 방문자는 직접 물어야 하는 방문자보다 제품을 더 신뢰하기 때문이다.

에이전시를 위한 규칙: 지원 티켓, 판매 통화 메모, 온보딩 이메일을 살펴보기 전에는 단 하나의 FAQ 답변도 쓰지 마라. 실제로 반복되는 질문은 무엇인가? 그것들만 넣어라. 그 외의 것은 기능 페이지에 넣거나 넣지 마라. 그리고 사이트가 발전함에 따라 FAQ를 다시 방문하라 — 새로운 가격 변경이나 기능 출시는 매번 새로운 질문을 만들고, FAQ는 그것들을 잡아내는 가장 저렴한 장소다.

콘텐츠뿐만 아니라 FAQ 구조에 대해서도 생각할 이유가 있다. 길게 스크롤되는 질문 목록은 훑어보기 어렵다. 카테고리(청구, 통합, 계정 관리)로 그룹화하고 맨 위에 목차를 두면 실제로 사용할 수 있게 된다. 목록이 어느 정도 커지면 검색 기능이 도움이 된다 — 이 부분은 카피만큼 디자인이 중요한 페이지의 요소다. 검색할 수 없는 FAQ는 읽히지 않는 FAQ이기 때문이다.

한 가지 더, 불편한 부분이다: FAQ는 종종 사이트에서 가장 정직한 페이지다. 방문자가 묻기를 두려워하는 질문에 답하는 유일한 페이지이기 때문이다. 질문에 답하는 것이 불편하게 느껴진다면 — "정말 언제든 취소할 수 있나요?" "무료 요금제에는 광고가 표시되나요?" — 그 불편한 느낌은 그것이 그곳에 속한다는 증거이지, 빼야 할 이유가 아니다. 방문자는 당신이 답하든 안 하든 그 질문을 가지고 있다; 당신이 답하지 않으면 그들은 답을 추론할 것이고, 그들이 추론하는 답은 진실보다 더 나쁠 것이다.

6단계 — 클라이언트에게 보여주기 전에 모든 페이지를 통합하고 QA하라.

완성된 사이트를 클라이언트에게 보여주려고 한다. 그 전에 가격 페이지와 기능 페이지를 나란히 열어 보아라. 모든 기능 이름을 확인하라: 일치하는가? 모든 숫자를 확인하라: 가격 페이지에 "프로젝트 10개"라고 되어 있고 기능 페이지에 "최대 10개 프로젝트"라고 되어 있으며 API 참조에 "최대 10"이라고 되어 있는가 — 모두 같은가? 모든 약속을 확인하라: "무제한 프로젝트"가 사이트 어디에 있는가, 있다면 그것이 사실인가? 그런 다음 제품 자체의 어휘를 검색하라: 모든 곳에서 "워크스페이스"라고 말하는가, 아니면 "팀"으로 빠져드는가? 여기서 홈페이지에 "신용카드 필요 없음"이라고 되어 있지만 실제 가입 흐름이 무료 체험에서 신용카드를 요구하는 경우를 잡아낸다 — 신뢰를 죽이는 바로 그 불일치 유형이다.

안에서부터의 순서의 보상은 여기서 온다. 모든 페이지가 동일한 제약 조건에서 파생되었기 때문에 일관성 작업은 구조 임무가 아니라 검증 통과다. 그러나 건너뛰지 마라. 살아남는 모순은 미묘한 것들이다 — 가격 페이지에서는 "승인"이라고 불리지만 API 문서에서는 "검토 흐름"이라고 불리는 기능, 제품이 제공하지 않는 다크 모드 대시보드를 보여주는 홈페이지의 스크린샷, 브랜드 덱에서 나온 것으로 클라이언트의 실제 고객 목록과 일치하지 않는 "원격 팀이 신뢰하는" 제품이라는 주장.

실용적인 기법: 제약 조건 목록을 QA 패스의 스크립트로 삼으라. 모든 페이지를 돌아다니며 각 사실을 목록과 대조하라. 이것은 제약 조건 목록이 페이지가 존재하기 전인 1주차에 작성되었으므로 진정으로 독립적인 출처이기 때문에 작동한다. 디자인이나 기억에서 QA를 시작하면 구축하는 동안 변경된 사실을 놓칠 것이다.

이 시점에서 작업을 순서대로 수행해야 하는 이유가 분명해진다. 페이지가 서로 다른 출처에서 병렬로 구축될 때 이 QA 패스는 매번 갈등을 발견하고, 모든 갈등은 완성된 것처럼 보이는 페이지에서 재작업을 의미한다. 페이지가 하나의 제약 조건 목록에서 순차적으로 구축될 때 QA 패스는 오타를 찾는다. 그것이 반복 가능한 프로세스와 끊임없는 위기의 차이다. 출시 후에도 전체 사이트가 하나의 이야기를 하게 하려면 — 새로운 기능, 새로운 팀, 새로운 카피라이터 — 동일한 규율의 유지 관리 버전이 필요하며, 페이지 전반에 걸쳐 SaaS 웹사이트의 이야기를 통합하는 프레임워크가 자연스러운 다음 단계다.

이것을 정직하게 유지하는 주의사항들.

이 프레임워크가 주장하지 않는 세 가지가 있다. 첫째, API가 없고, 단일 요금제이며, 하나의 명확한 사용 사례가 있는 초기 단계 SaaS의 경우 순서는 훨씬 덜 중요하다; 그런 사이트는 어떤 순서로 구축해도 조정 작업은 사소할 것이다. 이 프레임워크는 실제 복잡성 — 여러 요금제, API, 많은 기능, 여러 사용자 — 이 있을 때 그 가치를 증명한다. 본질적으로 가입 버튼이 있는 랜딩 페이지에 불과한 제품에 교리처럼 적용하지 마라.

둘째, 안에서부터 구축하면 처음에는 눈에 띄는 진행이 느리다. 클라이언트는 홈페이지를 요청했는데, 당신은 가격 표와 제약 조건 문서를 전달한다. 그들은 반발할 것이다. 홈페이지는 투자자와 자신의 팀에게 보여줄 수 있는 것이기 때문이다. 그 기대를 관리하는 것 — 가격 페이지 결정이 하위의 모든 것을 어떻게 형성하는지 보여주는 것 — 은 작업의 일부이지 실패가 아니다. 추진력을 유지하는 한 가지 방법은 초기에 대략적인 홈페이지 목업을 만들고, 그것이 콘텐츠를 기다리는 컨테이너라는 것을 분명히 표시하는 것이다. 그러면 골격을 구축하는 동안 클라이언트가 목적지를 볼 수 있다.

셋째, 제약 조건 목록은 변한다. 가격이 바뀌고, API가 성장하고, 요금제가 늘어난다. 프레임워크는 출시 후에도 제약 조건 문서를 업데이트된 상태로 유지한다고 가정한다. 웹사이트는 제품의 실제 한계를 반영하지 않는 순간 쇠퇴하기 때문이다. 이것이 안에서부터 접근법의 유지 관리 비용이다: 진실의 원천은 누군가가 그것을 소유할 때만 진실이다.

결론.

SaaS 웹사이트 프로젝트에서 가장 흔한 실패는 약한 카피나 나쁜 디자인이 아니라 서로 동의하지 않는 페이지다. 잘못된 순서로 구축되었기 때문이다. 제품의 실제 제약 조건이 있는 가격 페이지와 API 문서에서 시작하라; 실제 워크플로에서 기능 쇼케이스를 도출하라; 실제 대화에서 FAQ를 수집하라; 그리고 구조하는 것이 아니라 검증하는 일관성 검사로 마무리하라. 서로 다른 몇몇 클라이언트에게 이렇게 하면 그것이 창의적인 과정이라기보다 조립 라인에 가깝다는 것을 발견하게 될 것이다 — 에이전시에서는 그것이 정확히 원하는 것이다. 창의적인 작업은 여전히 존재한다; 단지 가장 큰 영향력을 발휘하는 곳에 적용될 뿐이다.