많은 기업이 공식 홈페이지를 준비할 때 웹사이트 구축 프로세스 문서를 작성합니다. 하지만 문서에 전문 용어나 개발 세부 사항만 가득하다면 고객은 오히려 혼란스러워하고, 반복적인 설명이 필요해집니다. 프로세스를 고객이 이해하기 쉽게 만드는 핵심은 고객이 익숙한 언어를 사용하여 구축 과정을 '먼저 무엇을 하고, 그다음 무엇을 하며, 마지막에 무엇을 얻는지'라는 명확한 로드맵으로 전환하는 것입니다. 아래에서는 고객의 관점에서 고객에게 보여주기에 적합한 웹사이트 구축 프로세스 작성법을 정리합니다.
단계를 고객이 인지할 수 있는 지점으로 나누기
고객은 백엔드에서 어떤 프레임워크를 사용하는지, 데이터베이스가 어떻게 설계되었는지 신경 쓰지 않습니다. 그들은 '언제 초안을 볼 수 있는지', '언제 콘텐츠를 채울 수 있는지', '얼마나 빨리 출시할 수 있는지'에 관심이 있습니다. 따라서 프로세스는 내부 작업 순서가 아닌 인도 지점을 기준으로 나누어야 합니다. 일반적으로 다음과 같은 단계로 나눌 수 있습니다:
- 요구사항 확인 및 방안 확정: 양측이 웹사이트 목표, 메뉴 구조, 기능 요구사항을 논의하고, 양측이 확인한 방안 문서를 출력합니다.
- 디자인 시안 출력 및 확인: 디자이너가 방안에 따라 홈페이지 및 내부 페이지 효과도를 제작하고, 고객이 시각적 스타일을 본 후 수정 의견을 제시하여 확인할 때까지 진행합니다.
- 프론트엔드 및 백엔드 개발: 개발자가 디자인 시안을 클릭 가능한 페이지로 만들고 백엔드 관리 시스템을 구축합니다. 이 단계에서 고객은 눈에 띄는 변화를 보지 못할 수 있지만, 정기적으로 진행 상황을 공유받을 수 있습니다.
- 콘텐츠 채우기 및 자료 업로드: 고객이 회사 소개, 제품 이미지, 사례 글 등의 콘텐츠를 제공하면 운영자나 개발자가 웹사이트에 업로드합니다.
- 테스트 및 수정: 양측이 함께 페이지 표시, 링크 이동, 양식 제출 등의 기능을 확인하고 문제를 발견하면 즉시 수정합니다.
- 출시 및 공개: 웹사이트를 실제 서버에 배포하고 도메인을 연결하며, 등록 또는 관련 심사를 완료한 후 외부에서 접속할 수 있도록 합니다.
기술 설명 대신 타임라인 사용
프로세스 문서에서 각 단계에는 대략적인 시간 범위를 포함하는 것이 좋습니다. 예를 들어 '요구사항 확인 단계는 일반적으로 3~5영업일이 소요됩니다', '디자인 시안 수정은 보통 2회 이내로 제한됩니다'와 같이 말입니다. 이렇게 하면 고객이 전체 기간에 대해 합리적인 기대를 가지게 되어 중간 단계에서 자주 재촉하지 않게 됩니다. 타임라인은 간단한 표나 간트 차트로 표시할 수 있지만, '절대', '보장'과 같은 약속성 단어는 쓰지 말고 '예상', '일반적으로'라고 작성하는 것이 좋습니다.
양측이 각각 해야 할 일 명확히 하기
많은 고객이 프로세스를 봐도 자신이 무엇을 협력해야 하는지 잘 모릅니다. 따라서 각 단계 아래에 두 개의 열로 나누는 것이 좋습니다: 한 열은 서비스 제공자(웹사이트 구축 회사 또는 내부 팀)의 책임(예: 디자인 방안 제시, 페이지 개발)이고, 다른 열은 고객이 해야 할 일(예: 요구사항 확인, 텍스트 및 이미지 자료 제공, 디자인 시안 검토)입니다. 이렇게 하면 고객이 자료를 준비할 때 대조해 볼 수 있으며, 언제 무엇을 해야 하는지 알 수 있습니다.
일상적인 비유로 전문적인 부분 설명
일부 부분은 고객에게 생소할 수 있습니다. 예를 들어 '등록', '서버 배포', '프론트엔드 상호작용' 등이 있습니다. 비유를 사용하여 이해를 돕는 것이 좋습니다:
- 등록: 웹사이트에 신분증을 발급하는 것과 같아서, 자료를 제출하여 심사를 받아야 하며 일반적으로 몇 영업일이 소요됩니다.
- 서버 배포: 지은 집을 24시간 전기가 공급되는 장소에 배치하여 방문객이 언제든지 열 수 있도록 하는 것과 같습니다.
- 프론트엔드 개발: 디자인 도면을 브라우저에서 클릭할 수 있는 페이지로 만드는 것으로, 인테리어 도면에 따라 빈 집을 거주 가능한 상태로 꾸미는 것과 같습니다.
이러한 비유를 매번 쓸 필요는 없지만, 고객이 자주 묻는 부분에 적절히 추가할 수 있습니다.
피드백 및 수정에 대한 설명 남겨두기
고객이 가장 걱정하는 것은 '마음에 들지 않으면 어떻게 하나요'입니다. 따라서 프로세스에 수정 메커니즘을 설명해야 합니다: 디자인 시안 확인 전에는 수정 의견을 제시할 수 있습니다. 개발 완료 후 기능 문제가 있으면 수정할 수 있습니다. 하지만 구조 대폭 변경이나 새로운 기능 추가는 시간과 비용에 영향을 미칠 수 있습니다. 규칙을 명확히 하면 오히려 후반 다툼을 줄일 수 있습니다. '무제한 수정', '만족 보장'과 같은 약속을 쓰지 말고 '합리적인 범위 내에서 수정', '실제 상황에 따라 협의하여 조정'이라고 작성하세요.
마지막에 고객을 위한 체크리스트 제공
프로세스 문서 끝에 간단한 출시 전 체크리스트를 첨부하는 것이 좋습니다. 예를 들어:
- 모든 페이지가 정상적으로 열리는가?
- 연락처, 주소, 지도가 올바른가?
- 제품 이미지가 선명한가?
- 뉴스/사례 메뉴에 데모 콘텐츠가 있는가?
이 체크리스트는 고객이 출시 전에 적극적으로 확인에 참여하게 하여 출시 후 문제가 발견될 확률을 줄여줍니다. 또한 서비스 제공자의 세심함과 전문성을 보여줄 수 있습니다.
팁: 프로세스 문서는 너무 상세할 필요가 없습니다. 중소기업의 경우 프로세스를 6~8개 지점으로 제어하고, 평이한 언어로 각 지점의 산출물과 협력 사항을 설명하는 것만으로도 고객이 이해하고 신뢰할 수 있습니다. 고객이 기술적 세부 사항에 관심이 있다면 별도의 부록이나 구두 설명을 제공하고, 본문 프로세스에 전문 콘텐츠를 너무 많이 쌓지 마세요.