기능은 다 있습니다. 그런데 고객 문의의 절반이 "그 기능 어디 있어요?"입니다. 이 상황은 기능 부족이 아니라 정보 구조(IA)의 문제입니다.
제품이 작을 때는 메뉴 다섯 개로 충분했습니다. 그런데 2년 동안 기능을 붙이다 보면 메뉴가 열다섯 개가 되고, 각각은 논리적인데 전체는 아무도 설명하지 못하는 상태가 됩니다.
30초 요약
- •IA 문제는 "어디 있어요" 문의와 낮은 기능 사용률로 드러납니다.
- •원인은 대부분 조직도를 그대로 메뉴로 옮긴 것입니다. 사용자는 우리 조직을 모릅니다.
- •재설계는 화면이 아니라 사용자가 하려는 일(Job)부터 시작합니다.
- •카드 소팅과 트리 테스트면 충분합니다. 사용자 5~8명으로 대부분 드러납니다.
- •권한 구조를 IA 단계에서 함께 정해야 합니다. 나중에 붙이면 화면마다 조건문이 흩어집니다.
1. IA가 무너지는 전형적인 경로
① 조직도를 메뉴로 옮긴다
가장 흔합니다. 마케팅팀이 만든 기능은 '마케팅' 메뉴에, 영업팀 기능은 '영업' 메뉴에 들어갑니다. 회사 안에서는 자연스럽지만 사용자는 우리 회사의 팀 구성을 모릅니다. 사용자에게는 '고객에게 메일 보내기'가 마케팅인지 영업인지 알 길이 없습니다.
② 새 기능을 '기타'에 넣는다
어디에도 안 맞는 기능이 생기면 '설정'이나 '기타'로 갑니다. 한 번은 괜찮지만 이게 반복되면 '설정' 안에 제품의 절반이 들어갑니다.
③ 메뉴를 지우지 않는다
기능은 더하기만 하고 빼지 않습니다. 쓰이지 않는 메뉴가 남아 있으면 그 자체로 탐색 비용입니다. 사용률 하위 항목을 정기적으로 걷어내는 규칙이 있어야 합니다.
2. 재설계는 '할 일'에서 시작합니다
화면 목록을 펼쳐놓고 다시 배열하는 방식으로는 잘 안 됩니다. 이미 잘못된 분류를 전제로 삼기 때문입니다. 대신 이렇게 합니다.
사용자가 이 제품으로 하려는 일을 문장으로 적는다
→ 그 일을 끝내는 데 필요한 화면을 잇는다
→ 이어진 덩어리가 메뉴가 된다
예를 들어 "이번 달 미수금을 확인하고 담당자에게 알린다"가 하나의 일이라면, 조회 화면과 알림 발송이 같은 자리에 있어야 합니다. 지금 제품에서 이 둘이 다른 메뉴에 있다면 그게 바로 고쳐야 할 지점입니다.
이 작업의 결과로 메뉴 수가 줄어드는 경우가 많습니다. 기능을 뺀 게 아니라 흩어져 있던 것을 모았기 때문입니다.
3. 검증 방법 — 두 가지면 충분합니다
카드 소팅
기능 이름을 카드에 적어 사용자에게 주고 직접 묶어보게 합니다. 우리가 생각한 분류와 사용자의 분류가 어디서 갈라지는지가 바로 보입니다. 5~8명이면 패턴이 드러납니다.
트리 테스트
반대 방향입니다. 메뉴 구조만 보여주고 "미수금을 확인하려면 어디로 가시겠어요?"라고 묻습니다. 화면 디자인 없이 구조만으로 검증할 수 있어서, 개발 전에 문제를 잡아낼 수 있습니다.
둘 다 도구가 거창할 필요 없습니다. 종이와 스프레드시트로도 충분하고, 중요한 건 우리 팀이 아니라 실제 사용자에게 물어보는 것입니다.
4. 권한을 같이 설계해야 하는 이유
IA를 정하고 나서 권한을 얹으면 반드시 충돌합니다. 관리자에게만 보이는 메뉴, 특정 플랜에서만 열리는 기능이 생기면서 같은 메뉴가 사람마다 다르게 보이기 시작합니다.
그 상태가 되면 두 가지 문제가 생깁니다. 첫째, 고객 지원이 어려워집니다 — 화면을 공유받아도 상대가 뭘 보고 있는지 모릅니다. 둘째, "권한이 없어 안 보이는 것"과 "없는 기능"을 사용자가 구분하지 못합니다.
그래서 IA 단계에서 역할별로 한 번씩 구조를 그려봐야 합니다. 역할이 셋이면 트리도 셋입니다.
5. 언제 하면 좋은가
IA 재설계는 미룰수록 비싸집니다. 화면이 늘어난 만큼 바꿀 것도 늘기 때문입니다. 다만 너무 이르면 근거가 없습니다. 적절한 시점은 이렇습니다.
- •실사용 데이터가 3~6개월 쌓였을 때 — 어떤 기능이 실제로 쓰이는지 알 수 있습니다
- •메뉴가 10개를 넘어갈 때 — 사람이 한눈에 훑을 수 있는 한계입니다
- •새 기능 배치를 두고 팀이 매번 논쟁할 때 — 구조에 규칙이 없다는 신호입니다
- •큰 기능을 추가하기 직전 — 넣고 나서 바꾸면 두 배로 듭니다
자주 묻는 질문
IA만 따로 진행할 수 있나요?
가능하고, 오히려 권합니다. 화면을 그리지 않고 구조와 흐름만 정리하는 범위라 기간이 짧고, 결과물이 개발팀에 그대로 전달됩니다. 전체 고도화의 필요 여부도 이 단계가 끝나면 판단하기 쉬워집니다.
메뉴를 바꾸면 기존 사용자가 혼란스러워하지 않을까요?
일시적으로는 그렇습니다. 그래서 한 번에 바꾸고 안내를 충분히 하는 편이 낫습니다. 조금씩 나눠 바꾸면 혼란이 길게 이어지고, 그 사이 두 구조가 공존해 더 헷갈립니다.
사용자 인터뷰할 사람을 구하기 어렵습니다
기존 고객사 담당자 5명이면 충분합니다. 신규 사용자와 숙련 사용자를 섞으시면 더 좋습니다. 인원이 많은 것보다 성격이 다른 사용자가 섞이는 게 훨씬 중요합니다.
정리하면
"어디 있어요" 문의가 반복된다면 기능을 더할 때가 아니라 구조를 다시 볼 때입니다.
조직도가 아니라 사용자의 할 일에서 출발하고, 카드 소팅과 트리 테스트로 검증하고, 권한을 같은 단계에서 정하세요. 화면을 그리기 전에 끝나는 일이지만 나머지 전부를 결정합니다.
함께 읽으면 좋은 글
- •B2B SaaS UI/UX 고도화란 무엇인가 — 화면을 예쁘게 만드는 일이 아닙니다
- •SaaS 대시보드, 지표를 늘릴수록 안 쓰이는 이유
- •관리자 페이지를 나중으로 미루면 생기는 일 — 어드민 UX 설계
제품 구조부터 점검이 필요하시면 상담 신청을 남겨주세요. 범위와 예상 기간을 먼저 정리해 드립니다. 진행 방식과 포함 범위는 요금제 페이지에서 확인하실 수 있습니다.
이 글은 EasySpark 허수진 대표의 실무 내용이며, 제품 단계와 조직 구성에 따라 다를 수 있어 결과를 보장하지 않습니다. 우리 제품에 맞는 개선 방향이 궁금하시다면 편하게 상담 신청해주세요.
