패싯 필터

항목을 갈래로 나눠 담는 방식은 한 항목이 한 자리에만 놓일 때 깔끔합니다. 문제는 실제 물건이 대개 여러 자리에 동시에 걸린다는 것입니다. 회의록 하나를 두고 팀 폴더에 둘지 프로젝트 폴더에 둘지 정하지 못하는 장면이 그것입니다. 어느 쪽에 넣어도 반대쪽에서 찾는 사람은 못 찾고, 양쪽에 복사해 두면 어느 것이 최신인지가 곧 문제가 됩니다.

항목 수가 늘면 다른 문제가 겹칩니다. 문서가 1,200개 쌓이면 메뉴를 아무리 잘 나눠도 마지막 갈래 안에 200개가 남고, 사용자는 거기서부터 스크롤로 훑어야 합니다. 검색창이 있지만 그건 찾는 것의 이름을 알 때 이야기입니다. "지난달에 민서가 쓴 기획서 중 아직 검토 안 끝난 것" 처럼 조건으로만 기억하는 대상은 검색어로 옮길 말이 없습니다.

패싯 필터는 이 둘을 한꺼번에 푸는 방식으로 자리 잡았습니다. 항목을 어느 한 자리에 넣는 대신 여러 속성을 동시에 달아 두고, 사용자가 그중 필요한 조건만 골라 겹치게 합니다. 길을 하나 정해 주는 대신 사용자가 자기 머릿속 조건으로 길을 만들게 한 것입니다.

항목마다 여러 속성을 붙여 두고, 사용자가 고른 조건을 모두 만족하는 것만 남깁니다. 화면을 만들 때 정해야 하는 것은 다섯 가지입니다.

1. 어떤 속성을 노출할지 정합니다. 문서 목록이라면 작성자, 문서 종류, 기간, 진행 상태, 소속 팀쯤이고 이 속성 하나하나를 패싯이라 부릅니다. 실제로 쓰이는 것은 대개 서넛이라 일곱 개를 넘기면 고르는 일 자체가 일이 됩니다.
2. 겹치는 규칙을 정합니다. 널리 쓰이는 방식은 같은 속성 안에서는 하나라도 맞으면 남기고, 서로 다른 속성 사이에서는 모두 맞아야 남기는 것입니다. 작성자에서 지현과 태오를 함께 고르고 상태에서 검토 중을 고르면 둘 중 누구든 쓴 것이면서 검토 중인 문서가 남습니다.
3. 값마다 남는 개수를 미리 보여 줍니다. 작성자 목록에 지현 180, 태오 64 처럼 붙여 두면 고르기 전에 결과의 크기를 압니다. 0건이 되는 값은 흐리게 두거나 감춥니다. 이게 없으면 사용자는 빈 화면을 만난 뒤에야 잘못 골랐다는 것을 알게 됩니다.
4. 지금 걸린 조건을 위쪽에 보여 주고 하나씩 또는 한 번에 풀 수 있게 합니다. 조건이 세 개 겹치면 사람은 무엇을 걸었는지 금세 잊습니다.
5. 조건을 주소에 담습니다. 그래야 결과 화면을 동료에게 링크로 보낼 수 있고, 문서를 하나 열었다가 뒤로 가기를 눌렀을 때 걸어 둔 조건이 그대로 남아 있습니다.

숫자로 보면 좁혀지는 모양이 분명합니다. 1,200개 목록에서 작성자를 고르면 180개, 거기에 지난 30일을 걸면 24개, 상태를 검토 중으로 좁히면 6개가 남습니다. 세 번 눌러 1,200개를 6개로 줄인 셈이고, 이 6개는 갈래를 짚어 내려가서는 한 화면에 모을 수 없는 조합입니다.

항목이 많고 항목마다 속성이 붙어 있는 목록이면 어디든 들어갑니다. 쇼핑몰의 상품 목록이 가장 익숙한 자리로 크기와 색과 가격대와 브랜드를 겹칩니다. 채용 사이트는 직무와 지역과 경력을, 부동산 서비스는 면적과 가격과 층수를 같은 방식으로 씁니다. 업무 툴에서는 문서 목록과 이슈 목록이 그렇습니다.

들이기 전에 확인할 것이 셋 있습니다.

1. 항목 수입니다. 오십 개 안팎이면 필터 없이 한 화면에 정렬만 붙이는 편이 빠릅니다. 조건을 고르는 동작이 훑는 동작보다 비쌉니다.
2. 속성이 실제로 채워져 있는지입니다. 이 방식이 실패하는 가장 흔한 이유가 여기 있습니다. 화면은 다 만들었는데 문서 절반에 팀 값이 비어 있으면 그 절반은 팀으로 거를 때마다 사라집니다. 값을 채우는 일은 대개 사용자 몫이라, 함께 정해야 하는 것은 필터가 아니라 값을 언제 어떻게 받을지입니다.
3. 화면 폭입니다. 왼쪽에 세로로 세우는 배치는 모바일에서 자리가 없어, 버튼을 눌렀을 때 아래에서 올라오는 창으로 바꾸는 것이 보통입니다.

내비게이션이나 검색 UX와는 경쟁하지 않고 나란히 놓입니다. 메뉴로 큰 갈래에 들어오고, 검색어로 단번에 건너뛰고, 그 안에서 조건을 겹쳐 좁히는 식입니다. 검색 결과 화면 옆에 필터가 붙는 배치가 흔한 이유도 그래서입니다.

"여기 필터를 패싯으로 갈고 작성자랑 기간만 먼저 넣죠."

한 번에 하나만 고르는 방식을 조건을 겹칠 수 있는 방식으로 바꾸자는 말입니다.

"그 패싯은 값이 안 채워져 있어서 지금 넣으면 결과가 텅 빕니다."

화면이 아니라 데이터 쪽이 준비가 안 됐다는 지적입니다.

"필터가 아홉 개인데 실제로 쓰는 건 두 개예요."

노출한 조건 대부분이 안 쓰이니 줄이자는 뜻입니다.

페이지덱에서 문서 목록을 고칠 때 이 이야기가 나왔습니다. 문서가 1,200개를 넘으면서 못 찾겠다는 문의가 늘었고, 디자이너인 민서가 작성자와 기간과 상태와 팀, 네 가지를 겹칠 수 있는 화면을 그렸습니다.

개발자인 태오가 짚은 것은 팀 값이었습니다. 팀은 문서를 만들 때 고르는 항목이 아니라 나중에 붙이는 꼬리표라 실제로 채워진 문서가 3할이었고, 그대로 내보내면 팀으로 거르는 순간 7할이 사라집니다. 두 사람이 정한 것은 팀 조건을 이번에 빼고 문서를 만들 때 팀이 자동으로 붙게 고친 다음 석 달 뒤에 다시 보는 것이었습니다.

조건을 많이 내줄수록 좋다고 보는 경우가 가장 많습니다. 사용자마다 찾는 기준이 다르니 다 열어 두는 것이 친절해 보입니다. 하지만 조건이 아홉 개 늘어선 화면에서 실제로 누르는 것은 두어 개고 나머지는 훑는 비용만 더합니다. 조건이 많을수록 0건에 닿기도 쉬워져서, 세 개쯤 겹친 사용자가 빈 목록을 만나고 처음부터 다시 거는 일이 잦아집니다. 많이 쓰이는 서넛만 펴 두고 나머지는 접어 두는 배치가 낫습니다.

화면에 붙이는 부품으로만 여기는 것도 흔합니다. 목록 옆에 상자 몇 개를 세우는 일처럼 보이기 때문입니다. 실제로 이 방식이 돌아가려면 항목마다 속성 값이 빠짐없이 붙어 있어야 하고, 그 값에는 레이블링이 정한 일관된 이름이 붙어 있어야 합니다. 같은 상태를 어떤 문서는 검토 중으로, 다른 문서는 리뷰로 적어 두면 조건 하나가 목록을 둘로 쪼개 놓습니다. 그래서 이 화면을 만드는 일의 대부분은 데이터를 정리하는 일이고, 정리가 안 된 채로 내보내면 조건을 걸 때마다 빈 상태 화면을 보게 됩니다.