가상의 서비스 홈페이지 상단에 회사 소개, 연혁, 팀 소개, 서비스, 이용 절차, 준비 사항, 문의가 나란히 있다고 하자. 화면이 좁다는 이유로 뒤쪽 항목부터 감추면 이용자가 필요한 정보를 놓칠 수 있다. 먼저 회사가 어떤 곳인지 알아보는 세 항목과 실제 이용에 필요한 항목을 나눠 두 가지 구조를 만들어 본다. 메뉴 수를 먼저 정하지 않고 옮긴 뒤의 경로를 함께 적는다.
첫 번째 안은 회사 소개 아래에 연혁과 팀 소개를 넣고, 이용 안내 아래에 이용 절차와 준비 사항을 둔다. 서비스와 문의는 상단에 남긴다. 두 번째 안은 더 줄이기 위해 문의까지 이용 안내 아래로 옮긴다. 두 안 모두 첫 방문자가 준비 사항을 찾는 경로는 이용 안내를 거치므로, 그 과제만 시험하면 차이가 작게 보일 수 있다.
이번에는 사용 중 오류가 생겨 담당자에게 연락하려는 상황을 따라가 본다. 두 번째 안에서 이용 안내라는 이름을 보고 절차 설명만 있을 것으로 예상한다면 문의를 찾기 어렵다. 이런 반응이 실제 검수에서 나오면 메뉴 하나를 더 줄인 이익보다 필요한 창구가 숨은 문제가 크다. 반대로 사용자가 그 묶음에서 문의까지 자연스럽게 찾는다면 무조건 상단에 남겨야 한다는 규칙을 만들 필요는 없다.
선택한 안은 하위 이름을 실제 화면에 넣고 휴대전화에서 펼쳐 본다. 회사 소개를 누르면 연혁과 팀 소개가 구별되는지, 이용 안내를 펼친 상태에서도 문의로 갈 수 있는지 확인한다. 첫 선택뿐 아니라 잘못 고른 뒤 되돌아가는 위치도 기록한다. 수정 요청에는 ‘일곱 개를 네 개로 줄임’만 적기보다 어떤 글들을 묶었고 어떤 이용 과제 때문에 문의 위치를 정했는지 남겨야 이후 메뉴가 늘 때 판단을 이어 갈 수 있다.