리뉴얼 전에 고객이 멈추는 이유부터 확인해야 합니다

리뉴얼의 가장 큰 위험은 답보다 화면을 먼저 만드는 것입니다

팀은 현재 사이트의 불편을 오래 경험했기 때문에 원인을 알고 있다고 느끼기 쉽습니다. 그러나 내부 사용자는 메뉴 구조와 용어를 이미 알고 있고, 고객은 처음 보는 정보로 짧은 시간 안에 판단합니다. 내부 의견을 그대로 새 화면에 옮기면 시각적 완성도는 높아져도 같은 이해 문제가 반복될 수 있습니다.

리뉴얼 전에 ‘현재 디자인이 낡았다’는 평가를 관찰 가능한 문제로 바꿔야 합니다. 예를 들어 신규 방문자가 30초 안에 대상 고객과 제공 범위를 설명하지 못하거나, 상담 전 가격과 진행 기간을 찾지 못하거나, 모바일에서 필수 입력을 완료하지 못한다는 식입니다. 문제를 행동으로 정의하면 리서치 방법과 성공 기준을 선택할 수 있습니다.

리뉴얼의 첫 산출물은 새 시안이 아니라, 무엇을 왜 바꿔야 하는지 설명하는 증거여야 합니다.

• 누가: 신규 고객, 기존 고객, 운영자 중 누구의 문제인가
• 상황: 어떤 목적과 기기, 유입 경로에서 발생하는가
• 과업: 사용자가 무엇을 이해하거나 완료하려 하는가
• 실패: 어디에서 멈추고 어떤 잘못된 판단을 하는가
• 영향: 문의, 구매, 지원 비용에 어떤 손실을 만드는가

먼저 리뉴얼로 내려야 할 결정을 적습니다

리서치 목표가 ‘고객을 이해한다’이면 자료는 많아져도 설계 결정으로 이어지지 않습니다. 어떤 고객군을 우선할지, 메뉴를 과업 중심으로 바꿀지, 가격 정보를 어디까지 공개할지, 상담 단계를 줄일지처럼 실제로 선택해야 할 결정을 먼저 적습니다.

각 결정에는 현재 가정과 필요한 증거를 붙입니다. ‘고객은 상세 기능보다 결과 사례를 먼저 본다’는 가정이라면 분석에서 사례 페이지로 이동하는 경로를 보고, 인터뷰에서 비교 기준을 묻고, 사용성 테스트에서 현재 정보 순서를 관찰합니다. 하나의 방법에 모든 답을 기대하지 않는 것이 중요합니다.

• 결정: 메인 내비게이션을 서비스 기준과 고객 과업 기준 중 무엇으로 구성할 것인가
• 가정: 신규 고객은 내부 서비스 명칭을 이해하지 못한다.
• 증거: 검색어와 사이트 검색, 첫 클릭 테스트, 인터뷰의 고객 표현
• 판정: 주요 과업의 첫 선택 성공률과 설명 가능 여부

분석은 어디에서 멈췄는지, 인터뷰는 왜 망설였는지 보여줍니다

웹 분석은 많이 본 페이지, 다음 경로, 폼 시작과 제출, 기기별 오류를 보여줍니다. 하지만 페이지에서 나간 이유가 정보를 찾았기 때문인지 찾지 못했기 때문인지는 알 수 없습니다. 반대로 인터뷰는 판단 기준과 불안을 설명하지만 실제로 얼마나 많은 고객에게 같은 문제가 있는지는 보여주지 못합니다.

두 증거를 같은 고객 여정 위에 놓으십시오. 예를 들어 모바일에서 가격 페이지 이후 문의 이동이 낮고, 인터뷰에서도 포함 범위와 추가 비용을 알 수 없었다는 말이 반복된다면 신뢰도 높은 병목 후보가 됩니다. 숫자와 발언이 다를 때는 어느 쪽이 틀렸다고 결론 내리기보다 측정 정의, 인터뷰 대상, 실제 맥락이 다른지 조사합니다.

• 정량: 어디에서, 얼마나 자주, 어떤 집단에게 발생하는가
• 정성: 왜 그렇게 판단했고 무엇을 기대했는가
• 운영: 문제 때문에 어떤 문의와 수작업이 반복되는가
• 종합: 두 종류 이상의 증거가 같은 설계 문제를 가리키는가

고객 인터뷰는 의견보다 최근 행동을 복기합니다

‘새 사이트에 어떤 기능이 필요하세요’라고 물으면 사용자는 미래 행동을 정확히 예측하기 어렵고 눈에 띄는 기능을 제안하기 쉽습니다. 최근 서비스를 알아본 계기, 처음 한 행동, 비교한 대안, 찾지 못한 정보, 문의 직전의 우려를 시간 순서대로 묻는 편이 설계에 더 유용합니다.

대상은 성공 고객만 고르지 않습니다. 최근 구매 고객, 문의 후 미구매 고객, 지원 요청이 많았던 기존 고객을 포함하면 서로 다른 단계의 문제를 볼 수 있습니다. 인터뷰 중에는 해결안을 설득하지 말고 고객이 실제 사용한 단어를 기록합니다. 이 표현은 메뉴, 제목, 설명 문구를 고객의 언어로 바꾸는 근거가 됩니다.

• 이 문제를 해결해야겠다고 느낀 구체적인 순간은 언제였나요
• 처음 어디에서 무엇을 검색하거나 물어봤나요
• 우리 사이트에서 가장 먼저 확인하려던 것은 무엇이었나요
• 비교할 때 중요했던 기준과 불안했던 조건은 무엇이었나요
• 문의하거나 구매하기로 결정한 마지막 계기는 무엇이었나요

사용성 테스트는 실제 과업과 성공 기준으로 설계합니다

참여자에게 사이트가 마음에 드는지 묻는 것만으로는 문제를 찾기 어렵습니다. ‘우리 회사가 다음 달 데이터 분석을 맡길 수 있는지 판단하고, 예상 진행 방식과 문의 방법을 찾아보세요’처럼 현실적인 상황과 목적을 제시합니다. 정답 위치를 알려주는 메뉴 이름을 과업 문장에 넣지 않습니다.

진행자는 참여자가 말없이 막힐 때 바로 도와주지 말고 무엇을 찾는지 생각을 말해 달라고 요청합니다. 첫 선택, 완료 여부, 걸린 시간, 잘못 이해한 내용, 확신 정도를 기록합니다. 소수의 정성 테스트는 통계적 전환율을 추정하는 도구가 아니라 반복되는 심각한 문제를 발견하고 수정 방향을 이해하는 도구입니다.

• 과업 성공: 도움 없이 올바른 정보와 행동까지 도달했는가
• 첫 선택: 처음 고른 메뉴나 링크가 의도한 경로였는가
• 이해: 대상 고객, 제공 범위, 조건을 자신의 말로 설명하는가
• 마찰: 멈춤, 되돌아감, 반복 조회, 오류가 어디에서 발생하는가
• 확신: 결정을 내릴 만큼 정보가 충분하다고 느끼는가

발견한 문제를 화면 목록이 아니라 고객 여정으로 묶습니다

리서치 결과를 ‘버튼이 작다’, ‘메뉴가 어렵다’처럼 화면별 문제 목록으로만 정리하면 우선순위를 잃습니다. 발견, 이해, 비교, 행동, 사후 운영의 여정에 문제와 근거를 배치하면 같은 원인에서 나온 여러 증상을 묶을 수 있습니다.

각 문제에 빈도, 심각도, 사업 영향, 증거 강도를 표시합니다. 자주 발생하지 않아도 결제 오류나 개인정보 노출처럼 치명적인 문제는 우선합니다. 반대로 여러 사람이 언급했지만 핵심 과업과 관계없는 취향 차이는 전체 개편의 근거로 사용하지 않습니다. 발견된 문제와 제안된 해결안을 분리해 두면 한 문제에 여러 대안을 검토할 수 있습니다.

• 관찰: 사용자가 가격 페이지와 FAQ를 세 번 오갔습니다.
• 문제: 기본 범위와 추가 비용을 한곳에서 판단할 수 없습니다.
• 영향: 상담 전 이탈 또는 반복 문의가 발생합니다.
• 해결 후보: 가격 구조 요약, 포함·제외 표, 견적 예시, 상담 전 질문 안내
• 검증: 정보 이해도와 상담 이동, 반복 질문 변화를 확인합니다.

닷새만 있어도 ‘예쁜 사이트’ 요청을 검증 가능한 문제로 바꿀 수 있습니다

월요일에는 사업 책임자와 영업·고객지원 담당자를 만나 리뉴얼로 내려야 할 결정을 적습니다. ‘디자인을 젊게 만든다’가 아니라 ‘첫 방문자가 30초 안에 서비스 대상과 예상 비용 범위를 이해하게 할 것인가’, ‘상담 전에 어떤 신뢰 정보를 제공할 것인가’처럼 고객 행동으로 바꿉니다. 동시에 기존 사이트의 상위 유입 페이지, 핵심 경로, 상담 전환, 검색 유입을 보존 목록으로 만듭니다.

화요일에는 분석 데이터와 상담 기록을 봅니다. 수요일에는 최근 구매 고객 세 명과 이탈 고객 두 명에게 당시 무엇을 찾고 누구와 비교했는지 묻습니다. 목요일에는 새로운 디자인을 보여주지 않고 기존 사이트에서 ‘우리 회사에 맞는 서비스와 진행 기간을 찾아 상담을 시작해 달라’는 과업을 수행하게 합니다. 금요일에는 관찰한 문제를 고객 여정에 붙이고, 전체 리뉴얼·부분 개선·운영 수정 중 어떤 범위가 맞는지 결정합니다.

참여자가 다섯 명이라고 모든 고객을 대표하지는 않습니다. 이 짧은 과정의 목적은 통계적으로 완벽한 답을 만드는 것이 아니라, 내부 추측만으로 화면 전체를 바꾸는 위험을 줄이고 다음 조사와 설계의 우선순위를 찾는 것입니다. 서로 다른 자료에서 같은 문제가 반복되면 설계 근거가 강해지고, 결과가 엇갈리면 고객군을 나누거나 추가 조사를 계획합니다.

한 고객의 상담 과정을 따라가면 화면 목록이 여정으로 바뀝니다

예를 들어 제조업 마케팅 담당자가 검색으로 서비스 페이지에 들어왔다고 가정해 보겠습니다. 첫 화면에서 ‘데이터 기반 성장’이라는 문장을 봤지만 자신이 받을 구체적인 서비스는 알지 못했습니다. 사례 페이지에서는 결과 수치가 있었지만 회사 규모와 프로젝트 기간이 없어 자기 상황과 비교하기 어려웠습니다. 상담 폼에 도착한 뒤에는 예산을 입력해야 했지만 가격 범위가 없어서 창을 닫았습니다.

이 과정을 페이지별 문제로 나누면 메인 문구, 사례 디자인, 폼 개선이라는 세 개의 작업이 됩니다. 고객 여정으로 묶으면 ‘적합성 이해 → 유사 상황 확인 → 위험 판단 → 상담 준비’라는 하나의 의사결정 문제입니다. 해결안도 메인에 서비스 대상과 범위를 명시하고, 사례에 조건·기간·과정을 추가하고, 상담 전에 가격 결정 방식을 설명하는 연결된 구조가 됩니다.

이때 시각 디자인은 문제 해결을 돕는 수단으로 사용됩니다. 핵심 대상과 범위를 첫 화면의 위계로 드러내고, 사례의 전후 조건을 비교하기 쉽게 만들며, 상담 단계와 준비 자료를 읽기 쉽게 정리합니다. 색상과 타이포그래피의 변화는 이 정보가 더 빨리 이해되고 신뢰되도록 도울 때 의미가 있습니다.

리서치 결과에 따라 전체 리뉴얼을 하지 않을 수도 있습니다

핵심 문제의 원인이 첫 화면의 메시지와 서비스 정보 순서라면 템플릿 전체를 바꾸지 않고도 개선할 수 있습니다. 반대로 메뉴 구조, 콘텐츠 모델, 운영 도구가 모두 내부 조직 기준으로 묶여 있다면 부분 수정이 문제를 옮길 뿐일 수 있습니다. 리서치는 리뉴얼을 정당화하는 절차가 아니라 필요한 범위를 결정하는 절차입니다.

범위는 유지, 수정, 재설계, 제거로 나눠 결정합니다. 잘 작동하고 고객이 익숙한 부분은 유지하고, 근거가 있는 문제만 수정합니다. 새 기능은 고객 과업과 운영 책임이 분명할 때만 추가합니다. 콘텐츠 소유자와 갱신 절차가 없는 페이지는 새로 만드는 대신 통합하거나 제거하는 편이 장기 품질에 유리합니다.

• 유지: 사용자가 잘 찾고 이해하며 사업에도 필요한 부분
• 수정: 문제와 해결 범위가 특정된 정보·상호작용
• 재설계: 여러 과업을 막는 구조적 내비게이션·콘텐츠 모델
• 제거: 사용 근거, 소유자, 갱신 필요가 없는 기능과 페이지

출시 전후에 같은 과업과 지표로 효과를 검증합니다

리뉴얼 전 기준값이 없으면 출시 후 ‘깔끔해졌다’는 평가만 남습니다. 핵심 과업별 완료율과 이해도, 문의 퍼널, 오류율, 반복 문의를 리뉴얼 전에 기록합니다. 새 디자인의 프로토타입에서도 같은 과업을 테스트해 큰 문제를 출시 전에 수정합니다.

출시 후에는 유입 구성과 캠페인 변화를 함께 확인하며 같은 지표를 비교합니다. 초기에 검색 색인, 이벤트 누락, 링크 오류가 결과를 왜곡할 수 있으므로 데이터 품질을 먼저 검수합니다. 성과가 기대와 다르면 디자인 전체를 실패로 규정하지 말고 어떤 가정이 틀렸는지 리서치 기록과 다시 대조합니다.

• 이해 지표: 대상 고객과 제공 범위를 정확히 설명한 비율
• 과업 지표: 핵심 정보 탐색과 문의 완료 성공률
• 행동 지표: 서비스 상세 → 상담 시작 → 제출 전환
• 품질 지표: 오류, 접근성, 페이지 속도, 모바일 이탈
• 운영 지표: 반복 문의, 응답 시간, 잘못 들어온 문의 비율

참고 자료

사용자 요구를 조직 내부의 가정과 구분하고 실제 사용자 관찰로 검증하는 원칙은 GOV.UK 서비스 매뉴얼과 Nielsen Norman Group의 리서치 방법 자료를 참고했습니다.

• GOV.UK Service Manual: Learning about users and their needs
• GOV.UK: Government Design Principles
• Nielsen Norman Group: A Guide to Using User-Research Methods
• Google Analytics 공식 가이드: Path exploration