항목이 많아지면, 사람은 ‘찾기’를 원합니다.

예전에 자료실 페이지를 만들었는데, 문서가 처음엔 12개였습니다. 검색창이 없어도 괜찮았죠. 반년 뒤 문서가 60개가 됐는데 검색창은 그대로 없었습니다. ‘작년 보고서 어디 있냐’는 문의가 매주 들어왔습니다. 항목은 늘었는데 ‘찾는 방법’은 안 늘어난 겁니다. 그날 이후로 저는 목록을 만들 때 ‘이게 몇 개까지 늘어날까’를 먼저 묻습니다.

그래서, 직접 쳐보세요

설명보다 빠릅니다. 아래 입력창에 ‘GEO’, ‘폼’, ‘속도’ 같은 단어를 쳐보세요. 입력하는 동안 목록이 즉시 줄어듭니다. 그리고 일부러 ‘없는 단어’도 쳐보세요 — 빈 상태가 어떻게 처리되는지 보입니다.

언제 필터·검색을 넣고, 언제 빼야 할까요?

저는 ‘항목 7개’를 기준선으로 씁니다. 사람이 한눈에 비교할 수 있는 개수가 대략 거기까지입니다. 7개 이하면 검색창은 오히려 손이 한 번 더 가게 만드는 방해물입니다. 그냥 다 보여주는 게 빠릅니다. 7개를 넘기면 훑기가 힘들어지고, 10~20개를 넘어가면 검색창이 없을 때 사람이 떠납니다. 그래서 ‘지금 몇 개’가 아니라 ‘앞으로 몇 개까지 늘어날까’를 보고 미리 넣습니다.

입력하면 바로 거르는 게 왜 좋은가요?

위 위젯은 한 글자 칠 때마다 목록을 다시 그립니다. 버튼을 누를 필요가 없죠. 이게 빠른 이유는 단순합니다 — 항목이 이미 화면에 있으니 서버에 다시 물어볼 필요가 없습니다. 화면 안에서 보이고/숨기고만 합니다. 반대로 결과가 수천 건이거나 매번 서버에 요청해야 하면, 한 글자마다 호출하면 서버가 비명을 지릅니다. 그때는 입력이 멈춘 뒤 잠깐 기다렸다 한 번만 보내는 ‘디바운스’를 씁니다. 기준은 항상 ‘서버를 때리느냐’입니다.

검색 결과가 없을 때, 화면을 비워두면 안 됩니다

위 위젯에서 ‘zzz’ 같은 없는 단어를 쳐보세요. 목록이 사라지고 ‘검색 결과가 없어요 — 다른 단어로 찾아보세요’가 뜹니다. 이 한 문장이 없으면 사용자는 사이트가 고장 났다고 생각하고 새로고침을 누릅니다. 빈 상태는 ‘에러’가 아니라 ‘안내해야 할 순간’입니다. 여유가 되면 여기에 인기 항목이나 ‘전체 보기’ 버튼을 같이 둬서, 막다른 길이 아니라 갈림길로 만듭니다.

라벨에 안 보이는 키워드를 따로 넣는 이유

위 위젯에서 ‘ai’나 ‘aeo’를 쳐보면 ‘GEO/AEO 최적화’ 항목이 나옵니다. 라벨에는 ‘ai’라는 글자가 없는데도요. 비밀은 각 항목의 data-k 속성에 화면에 안 보이는 동의어·약어·영문을 같이 넣어둔 겁니다. 사용자는 라벨에 적힌 그대로 검색하지 않습니다. ‘문의 폼 설계’를 ‘form’으로, ‘속도·성능’을 ‘코어웹바이탈’로 찾습니다. 보이는 글자와 찾는 글자를 분리해야 검색이 사람의 머릿속과 맞아떨어집니다.

필터·검색도 키보드와 스크린리더를 챙겨야 합니다

입력창은 Tab만으로 닿을 수 있어야 합니다(위 위젯도 Tab으로 가보세요). 그리고 결과 개수가 바뀌면 화면을 못 보는 사용자도 알 수 있게 알려줘야 합니다. 빈 상태 문구도 이미지가 아니라 ‘텍스트’로 둬야 낭독기가 읽습니다. 어렵게 들리지만, type="text" 입력에 또렷한 placeholder를 두고 결과 영역에 적절한 안내를 텍스트로 두는 것만으로 대부분 해결됩니다.

‘필터를 잘 만든다’는 건 결국 사용자의 시간을 아끼는 일입니다

화려한 애니메이션이 들어간 필터보다, 한 글자 쳤을 때 바로 줄어드는 목록 하나가 사람을 더 오래 머물게 합니다. 항목 개수를 미리 가늠하고, 빈 상태를 챙기고, 동의어를 심어두고, 키보드를 챙기는 것 — 화려하지 않지만 이게 탐색 UX의 전부입니다. 당신의 사이트, 사용자가 원하는 걸 몇 초 만에 찾고 있나요?

제가 ‘찾기’를 설계할 때 사용자가 단어를 쳐서 원하는 항목에 닿는 동선은 이렇게 흘러갑니다.

그리고 ‘찾기’가 끊기는 자리는 늘 정해져 있습니다. 어디서 막히고, 그걸 무엇으로 푸는지 단계별로 정리했습니다.

화려한 효과보다, 이 길에서 멈칫하는 자리를 하나씩 없애는 게 탐색 UX의 전부입니다.