TL;DR
서비스 메뉴는 회사 조직도보다 고객이 해결하려는 문제와 선택 기준으로 묶는 편이 이해하기 쉽습니다. 각 묶음의 포함 범위와 경계를 먼저 적고 실제 서비스 설명을 배치해 보면 내부 명칭 때문에 생기는 혼란을 찾을 수 있습니다.
조직명이 고객의 선택 언어인지 확인하기
사업부나 솔루션 이름은 내부에서는 명확해도 처음 방문한 사람에게는 뜻이 모호할 수 있습니다. 메뉴를 정할 때는 해당 이름만 보고 무엇을 얻을 수 있는지 설명할 수 있는지 확인합니다. 약어가 꼭 필요하다면 풀어쓴 설명을 함께 두고, 비슷한 서비스가 어디서 달라지는지도 알 수 있게 합니다. 전문성이 있다는 인상을 주는 것과 이용자가 이해하는 것은 별개입니다.
Google은 논리적으로 사이트를 구성하면 사용자와 검색엔진이 페이지 관계를 이해하는 데 도움이 된다고 설명합니다. 여러 서비스를 무작정 한 단계에 나열하기보다 관계를 설계할 이유입니다. 다만 업종에 공통으로 맞는 고정 메뉴 수가 정해져 있다는 뜻은 아닙니다. 실제 서비스와 독자의 선택 과제를 기준으로 구분해야 합니다.
분류 기준을 한 문장으로 설명하기
제작, 검색 진단, 콘텐츠 운영처럼 제공하는 결과가 다르면 서로 다른 묶음이 될 수 있습니다. 같은 서비스라도 대상에 따라 메뉴를 나누고 싶다면 실제 설명과 제공 조건이 달라지는지 확인하세요. 이름만 달라지고 본문이 같다면 페이지를 늘리는 대신 기존 설명을 다른 탐색 경로에서 연결할 수도 있습니다.
페이지원이 제안하는 분류표에는 묶음 이름, 고객 질문, 포함 서비스, 제외 서비스, 인접 묶음과의 차이를 적습니다. 어떤 서비스를 두 묶음에 모두 넣어야 한다면 복제가 필요한지보다 고객이 접근하는 이유가 두 가지인지 먼저 봅니다. 공통 상세를 유지하면서 안내 문맥을 달리하는 방식도 검토할 수 있습니다.
W3C는 일반적인 사이트 탐색 메뉴의 구조를 순서 없는 목록으로 전달할 수 있다고 설명합니다. 분류 관계가 정리되면 구현에서도 항목과 묶음을 명확하게 표현해야 합니다. 시각적으로만 줄을 나눠 놓고 보조 기술에는 하나의 긴 텍스트로 읽히게 만들지 않는지 확인하세요. 디자인의 구분과 문서의 구분을 함께 봅니다.
고객 상황을 주고 실제로 찾아보기
메뉴 이름에 대한 선호 투표만으로 분류가 작동하는지 알기 어렵습니다. 기존 사이트를 개편하려는 담당자처럼 가상 상황을 주고 어디로 들어갈지 확인해 보세요. 선택한 이유와 기대한 내용을 기록합니다. 잘못 들어간 사람이 많다면 이름이 모호한지, 서비스 경계가 겹치는지, 목록의 순서가 오해를 만드는지 나눠 검토합니다.
Google은 설명적인 링크 텍스트가 사용자와 Google이 연결된 내용을 이해하는 데 도움이 된다고 안내합니다. 서비스 이름뿐 아니라 상세로 가는 링크도 어느 내용을 볼 수 있는지 드러내야 합니다. 모든 항목을 자세히 보기로만 끝내면 문맥에서 떨어져 읽을 때 목적지를 구별하기 어렵습니다. 설명을 길게 복사하기보다 연결될 내용을 짧게 붙여 보세요.
새 서비스가 생겼을 때의 규칙도 남기기
추가 서비스가 기존 묶음에 들어가는 기준을 적어 두면 메뉴가 매번 임의로 늘어나는 것을 막을 수 있습니다. 한 묶음에 설명이 너무 많아졌다면 고객의 선택 질문이 갈라졌는지 확인합니다. 내부 담당 조직이 바뀌었다는 이유만으로 고객이 익힌 탐색 구조를 반드시 바꿔야 하는 것은 아닙니다.
마무리
분류 검수에는 서비스명을 이미 아는 직원만 참여시키지 않는 편이 좋습니다. 처음 보는 사람에게 제공 범위를 간단히 설명하고 원하는 정보를 찾게 해 보세요. 안내를 받은 뒤에만 찾을 수 있었다면 이름 자체가 충분히 설명하지 못했을 수 있습니다. 시행 중인 서비스와 앞으로 제공할 예정인 서비스도 같은 상태처럼 섞지 말고 공개할 수 있는 사실만 메뉴에 반영해야 합니다.
서비스 분류의 결과물은 정돈된 메뉴 이름만이 아닙니다. 고객 질문과 각 묶음의 경계를 설명하는 분류표가 있어야 다음 서비스 추가와 메뉴 검수에도 같은 판단을 이어갈 수 있습니다.