검색 UX

검색창을 입력칸 하나로만 보던 시절이 있었습니다. 글자를 받아 데이터베이스에 넘기고 걸린 것을 목록으로 뿌리면 검색 기능이 있는 제품이 됐습니다. 만든 쪽에서 보면 작업이 끝난 상태였습니다.

쓰는 쪽에서는 자주 막혔습니다. 반년 전 회의록을 찾으려고 회의록이라고 쳤는데 결과가 0건으로 나옵니다. 그 문서는 미팅 노트라는 제목으로 저장돼 있었고, 검색은 제목의 글자가 정확히 일치하는 것만 찾고 있었습니다. 화면에는 검색 결과가 없습니다라는 회색 글자 한 줄만 남고, 사용자는 문서가 지워진 줄 알고 옆 사람에게 물어봅니다.

분류를 잘 짜 놓은 제품에서도 같은 일이 벌어졌습니다. 메뉴를 업무 종류별로 정갈하게 나눠 두면 만든 사람 머릿속에서는 모든 문서에 자리가 있지만, 사용자는 그 분류에 동의하지 않은 채 들어옵니다. 자기가 기억하는 단어를 검색창에 치는 쪽이 메뉴 다섯 칸을 짚어 내려가는 쪽보다 빠르기 때문입니다. 검색이 우회로가 아니라 주된 길이 되는데, 그 길이 위처럼 생겨 있으면 사용자는 제품 안에 있는 것을 못 찾고 나갑니다.

검색 UX 는 질의 한 번이 아니라 다섯 구간의 흐름으로 설계됩니다. 어느 한 구간이 비면 나머지 넷이 잘 돌아도 사용자는 목적지에 닿지 못합니다.

1. 입력 — 검색창을 어디에 두고 안에 어떤 안내 문구를 넣을지 정합니다. 문서를 검색하세요라는 문구보다 제목이나 내용으로 검색이라는 문구가 무엇까지 찾아 주는지를 미리 알려 줍니다. 입력 중에 후보를 띄우는 자동완성과 최근에 찾은 말을 보여 주는 목록이 이 구간에 붙습니다.
2. 해석 — 사용자가 적은 말을 제품이 가진 말로 옮깁니다. 오타를 바로잡고, 같은 뜻으로 쓰는 말을 한 묶음으로 등록해 둡니다. 회의록과 미팅 노트를 같은 묶음에 넣어 두면 어느 쪽을 쳐도 같은 결과가 나옵니다.
3. 범위 — 제목만 볼지 본문까지 볼지, 댓글과 첨부 파일까지 넣을지 정합니다. 여기에 권한이 함께 걸립니다. 내가 볼 수 없는 문서가 결과에 뜨면 그 자체로 정보가 새어 나가고, 제목만 보이고 열 수 없는 결과가 뜨면 사용자는 제품이 고장 난 줄 압니다.
4. 결과 표시 — 순서와 한 줄의 구성을 정합니다. 관련도로 정렬할지 최근 수정 순으로 정렬할지는 제품에 따라 다르고, 자기가 쓴 문서를 다시 찾는 제품에서는 최근 순이 대체로 낫습니다. 한 줄에는 제목만 두지 않고 어디에 있는 문서인지, 누가 마지막으로 고쳤는지, 검색어가 본문 어디에 걸렸는지를 함께 보여 줍니다. 걸린 이유가 보이면 사용자는 열어 보지 않고도 고를 수 있습니다.
5. 결과 없음 — 0건 화면이 이 설계의 시험대입니다. 검색 결과가 없습니다 한 줄로 끝내지 않고, 오타로 짐작되는 말을 되물고, 범위를 넓혀 찾은 결과를 대신 보여 주고, 걸려 있는 조건을 끄는 버튼을 붙입니다.

좁히는 일도 같은 흐름에 들어갑니다. 결과가 800건이면 사용자는 다시 검색어를 바꾸는 대신 조건을 겹쳐 줄이는 쪽을 씁니다. 속성별 조건을 겹쳐 범위를 좁히는 패싯 필터를 결과 화면에 붙여 두는 이유입니다.

가장 먼저 필요해지는 자리는 항목이 늘어나 메뉴로는 못 찾게 된 제품입니다. 쓰이는 방식은 넷으로 갈립니다.

1. 항목이 많은 제품 — 문서가 500개를 넘기면 화면 사이를 이동하게 해 주는 장치인 내비게이션만으로는 한 건을 집어내기 어렵습니다.
2. 분류에 동의하지 않는 사용자 — 만든 쪽이 나눈 갈래가 사용자 머릿속의 갈래와 다를 때 쓰는 우회로입니다. 분류를 다시 짜는 일은 몇 달이 걸리는데 검색은 그 사이를 버티게 해 줍니다.
3. 제품을 읽는 창구 — 0건으로 끝난 검색어 목록이 무엇이 없는지와 어떤 이름이 어긋나 있는지를 알려 줍니다. 회의록이 매달 40번 검색되고 매번 0건이면, 갈래에 이름을 붙이는 일인 레이블링을 고칠 근거가 됩니다.
4. 좁은 화면 — 모바일에서는 메뉴를 깊게 쌓을 자리가 없어 검색에 더 기댑니다.

같은 검색어라도 사용자가 원하는 결과의 성격이 다릅니다. 그 성격을 따로 다루는 말이 검색 의도이고, 결과 화면을 짤 때 함께 봅니다.

"0건 화면부터 고칩시다. 지금은 회색 글자 한 줄이 끝이에요."

검색이 실패했을 때 사용자가 다음에 할 일이 화면에 없다는 지적입니다.

"회의록이 이번 달에 40번 검색됐는데 전부 0건이에요. 동의어에 넣어 주세요."

사용자가 쓰는 말과 제품에 적힌 말이 어긋난 자리를 찾아낸 보고입니다.

"결과 한 줄에 위치랑 수정일도 같이 보여 줘야 해요. 제목만으론 못 고릅니다."

결과를 고르는 데 필요한 정보가 한 줄에 빠져 있다는 요청입니다.

페이지덱에서는 민서가 검색 결과 화면을 다시 그릴 때 0건 화면부터 손댔습니다. 검색어를 되묻는 줄과 범위를 넓혀 찾은 결과 세 건, 그리고 걸린 필터를 끄는 버튼을 넣었습니다. 지현은 0건으로 끝난 검색어를 달마다 모아 보는 표를 만들어 두고, 같은 말이 스무 번 넘게 올라오면 동의어 사전에 넣거나 그 이름으로 항목을 바꿉니다.

검색을 응답 속도 문제로 읽는 경우가 가장 많습니다. 느리다는 민원이 가장 먼저 들어오고 그 민원은 숫자로 확인되기 때문입니다. 하지만 사용자가 검색을 못 쓰겠다고 느끼는 지점은 대개 속도가 아니라 원하는 것이 안 나오는 순간입니다. 응답 시간을 200밀리초에서 80밀리초로 줄여 놓고도 0건 화면이 그대로면 그 화면을 만난 사용자의 이탈은 그대로입니다. 속도는 이미 맞는 결과가 나오는 제품에서 체감을 올리는 요소입니다.

검색이 있으면 분류를 덜 신경 써도 된다고 읽는 것도 흔합니다. 사용자가 어차피 검색창으로 온다면 메뉴를 다듬는 일이 뒤로 밀려도 될 것처럼 보입니다. 그런데 검색이 찾아 주는 것은 제목과 본문에 적힌 말입니다. 같은 자리를 워크스페이스라고도 부르고 팀 공간이라고도 부르는 상태에서는 사용자가 무엇을 쳐도 절반만 걸립니다. 이름이 제각각인 제품에서 검색을 강화하는 일은 어긋난 사전을 더 빠르게 훑는 것에 가깝습니다. 분류와 이름이 먼저 정리돼야 검색이 그 위에서 제 몫을 합니다.