UX/UI
필터 UX, 조건을 고르는 순간부터 해제할 때까지
필터 UX, 조건을 고르는 순간부터 해제할 때까지
필터를 선택할 수 있어도 어떤 조건이 적용됐는지 알기 어렵다면 탐색은 계속 끊깁니다. 조건 조합과 개별 해제, 모바일의 임시 선택과 적용, 상세 화면에서 돌아오는 흐름까지 필터 UX를 설계하는 기준을 살펴봅니다.
필터를 선택할 수 있어도 어떤 조건이 적용됐는지 알기 어렵다면 탐색은 계속 끊깁니다. 조건 조합과 개별 해제, 모바일의 임시 선택과 적용, 상세 화면에서 돌아오는 흐름까지 필터 UX를 설계하는 기준을 살펴봅니다.
필터를 골랐는데 무엇이 바뀌었는지 모르겠다면
업무 목록에서 상태와 담당자를 고른 뒤 필터 창을 닫습니다. 목록은 짧아졌지만 어떤 조건이 적용됐는지 보이지 않습니다. 원하는 항목이 없어서 다시 창을 열고 선택을 확인합니다. 조건을 고르는 순간만 설계하면 사용자는 결과를 읽을 때부터 기억에 의존하게 됩니다.
필터는 선택 화면과 결과 목록을 오가는 기능입니다. 어디까지 선택했고 무엇이 실제로 반영됐는지, 조건을 어떻게 고치고 되돌리는지까지 연결해야 합니다. 사용자가 현재 보고 있는 목록의 범위를 설명할 수 있어야 합니다. 선택 항목이 예쁘게 정리돼 있어도 이 질문에 답하기 어렵다면 사용 흐름을 살펴볼 필요가 있습니다.
가상의 프로젝트 관리 서비스를 예로 들어보겠습니다. 사용자는 상태, 담당자, 기간으로 업무를 좁힙니다. 진행 중이거나 검토 중인 업무 중에서 본인이 담당하고 이번 주에 마감되는 항목을 찾으려는 상황입니다. 이 글의 화면과 문구는 이 가상 서비스를 위한 설계 예시입니다.
검색과 필터, 정렬의 역할도 구분합니다. 검색은 입력한 단어나 검색식으로 대상을 찾고 필터는 속성값으로 결과 범위를 좁힙니다. 정렬은 남은 결과를 마감일순이나 최근 수정순으로 배치합니다. 사용자는 세 기능을 함께 쓰므로 화면과 정책에서도 관계를 설명해야 합니다. 필터를 지웠는데 검색어 때문에 결과가 적다면 전체 목록으로 돌아왔다고 오해할 수 있습니다.
선택지를 많이 보여주는 것이 목표는 아닙니다. 이 서비스를 쓰는 사람이 실제로 구분하는 상태와 기간이 무엇인지 먼저 확인합니다. 내부 데이터의 상태 코드나 팀만 아는 줄임말을 그대로 내놓으면 정확한 값을 골라도 의미를 알기 어렵습니다. NN/G 필터 분류와 값의 이름 안내
적용된 조건을 목록 가까이에서 읽고 고치게 합니다
선택 규칙은 화면을 만들기 전에 문장으로 적습니다
상태를 두 개 고르면 둘 중 하나만 해당해도 나오는지, 두 상태가 동시에 해당해야 하는지부터 정합니다. 같은 분류 안의 선택과 서로 다른 분류의 조합을 구분해 정의합니다. 이번 예시에서는 상태의 진행 중 또는 검토 중을 OR로 묶고 담당자와 기간은 AND로 결합합니다. 모든 서비스에 적용하는 보편 규칙이 아니라 이 목록의 정책입니다.
이 정책대로라면 진행 중인 다른 사람의 업무는 나오지 않고 본인이 담당한 검토 중 업무는 나옵니다. 기간이 마감일을 뜻하는지도 분명히 적습니다. 생성일인지 마감일인지 모르는 이번 주 필터로는 결과를 확인하기 어렵습니다.
필터 버튼의 숫자만으로는 조건을 설명하기 어렵습니다
목록 위에 상태: 진행 중, 상태: 검토 중, 담당자: 나, 마감일: 이번 주처럼 적용된 조건을 짧은 칩으로 표시할 수 있습니다. 목록을 읽는 자리에서 조건을 확인하고 하나만 해제할 수 있도록 합니다. 여러 조건을 함께 지우는 버튼도 개별 해제와 구분합니다.
Baymard의 전자상거래 연구는 적용된 필터를 요약해 보여주고 개별적으로 해제하게 하는 방법을 다룹니다. 업무 도구에서도 검토할 만한 원칙이지만 동일한 효과가 보장된다고 단정할 수는 없습니다. 실제 업무 목록에서 조건을 읽고 수정하는 흐름으로 확인해야 합니다. Baymard 적용된 필터 설계 연구
확인할 상황 | 모호한 설계 | 이번 예시의 개선안 |
|---|---|---|
적용 상태 확인 | 필터 버튼에 숫자만 표시 | 목록 위에 적용된 조건 노출 |
조건 하나 해제 | 필터 창을 다시 열어 선택 취소 | 해당 조건 칩에서 바로 해제 |
전체 초기화 | 무엇이 지워지는지 알 수 없음 | 상태·담당자·기간만 해제한다고 안내 |
결과 없음 | 항목이 없습니다로 종료 | 조건을 유지하고 해제 경로 제공 |
전체 초기화가 무엇을 지우는지 팀이 같은 뜻으로 이해해야 합니다. 이번 예시에서는 상태·담당자·기간만 해제하고 검색어와 정렬은 유지합니다. 검색어까지 지우는 설계도 가능하지만 그때는 버튼 이름과 안내가 해당 범위를 드러내야 합니다.
다음은 이 가상 서비스에서 사용할 수 있는 안내 문구입니다.
필터를 모두 해제합니다. 검색어와 정렬은 유지됩니다.
조건 칩도 무한히 늘어놓지 않습니다. 모바일에서 두 줄 이상 길어질 때 접을지 가로로 탐색할지 정하고 숨은 조건이 있다는 사실을 알려줍니다. 축약된 칩만 보여준다면 전체 조건을 확인하는 경로가 필요합니다.
모바일에서는 고르는 중인 값과 적용된 값을 나눕니다
즉시 반영과 적용 버튼은 맥락에 따라 고릅니다
데스크톱 목록 옆에서 조건을 하나씩 바꾸며 결과를 비교한다면 즉시 반영이 자연스러울 수 있습니다. 반면 모바일에서 필터 화면이 목록을 덮고 여러 조건을 한꺼번에 고른다면 마지막에 적용하는 방식이 더 적합할 수 있습니다. 선택 하나마다 긴 요청을 보내거나 화면이 크게 움직이는 경우도 고려합니다. NN/G 필터 적용 방식 안내
적용 버튼이 있는 화면에서는 임시 선택과 실제 적용값을 구분합니다. 이번 모바일 예시에서는 창을 열 때 적용값을 임시 선택으로 가져오고 사용자가 바꾸는 동안 목록의 조건은 그대로 둡니다. 적용을 눌렀을 때만 선택을 확정합니다. 임시 선택인데 목록 위 칩까지 바뀌면 이미 반영됐는지 헷갈립니다.
적용 전에 X나 바깥 영역, 기기의 뒤로 가기로 닫았을 때의 동작도 통일합니다. 이번 예시에서는 미적용 변경을 버리고 기존 조건을 유지합니다. 다시 열면 마지막 적용값을 보여줍니다. 미적용 선택을 보관하는 서비스라면 보관 중임을 알려야 하며 이번 예시처럼 처리할 필요는 없습니다.
반영 중에도 현재 상황을 알 수 있어야 합니다
조건을 확정한 뒤 결과를 받는 시간이 걸린다면 반영 중이라는 표시를 둡니다. 기존 항목을 남겨둘 경우 아직 이전 결과라는 사실을 구분하고 새 결과처럼 읽히지 않게 합니다. 선택을 빠르게 바꾸면 이전 요청의 응답이 늦게 도착할 수 있습니다. 이 응답이 최신 결과를 덮어쓰지 않는지도 개발에서 확인해야 합니다.
조건 표시와 결과 목록은 같은 적용 상태를 가리켜야 합니다. 상태 칩은 검토 중인데 목록은 직전 진행 중 요청의 결과라면 사용자는 잘못된 업무를 보고 있다고 생각하지 못할 수 있습니다. 로딩의 모양보다 상태가 서로 어긋나지 않는지가 먼저입니다.
결과가 없다고 선택을 자동으로 지우지는 않습니다. 무엇을 골라서 결과가 없어졌는지 확인할 수 있도록 조건을 남겨두고 개별 해제나 전체 초기화로 돌아가게 합니다. 검색어도 함께 적용돼 있다면 어느 범위를 해제하는지 구분합니다. 빈 화면을 장식하기보다 다음 수정 행동을 바로 시작할 수 있게 만드는 데 집중합니다.
상세에서 돌아왔을 때도 목록의 맥락을 이어갑니다
업무 하나를 열어 확인한 뒤 돌아왔는데 필터가 풀리고 목록 맨 위로 이동하면 다시 찾는 일이 생깁니다. 같은 탐색을 계속하는 상황이라면 조건과 정렬, 스크롤 위치를 유지하는 것을 우선 검토합니다. 새로고침이나 새 세션에서도 유지할지는 별도 정책입니다.
기간도 해석을 정합니다. 이번 주처럼 현재 날짜에 따라 범위가 달라지는 값과 사용자가 직접 고른 고정 날짜는 다릅니다. 오래 열어둔 화면을 다시 볼 때 어떤 날짜 범위가 적용되는지 사용자에게 설명할 수 있어야 합니다.
완료 기준은 선택창이 아니라 실제 탐색 시나리오입니다
출시 전에는 조건을 선택하는 화면만 눌러보지 말고 찾기부터 해제까지 이어서 확인합니다. 정상적으로 결과가 나오는 조합 하나로 테스트를 끝내면 개별 해제나 재진입처럼 자주 쓰는 동작이 빠지기 쉽습니다.
진행 중과 검토 중, 담당자 나, 마감일 이번 주를 선택합니다. 예시 정책의 OR와 AND 조합대로 결과가 나오는지 확인합니다.
상태 한 개만 해제합니다. 다른 상태와 담당자, 기간이 남고 목록도 그에 맞게 바뀌는지 봅니다.
모바일 필터에서 값을 바꾼 뒤 적용하지 않고 닫습니다. 목록은 그대로인지, 다시 열었을 때 기존 적용값이 보이는지 확인합니다.
조건을 빠르게 바꾸고 응답을 기다립니다. 최신 선택과 조건 칩, 결과가 일치하는지 봅니다.
상세를 열었다 돌아옵니다. 정한 정책대로 조건·정렬·스크롤 위치가 유지되는지 확인합니다.
전체 초기화를 실행합니다. 지우기로 한 값만 사라지고 검색어와 정렬의 유지 여부도 안내와 같은지 봅니다.
마우스로 고를 수 있다는 사실만으로 사용성을 확인했다고 보기는 어렵습니다. 키보드로 필터를 열고 선택하고 적용하거나 닫는 경로도 점검합니다. 칩의 X에는 담당자 필터 해제처럼 무엇을 지우는 버튼인지 알 수 있는 이름을 제공합니다. 필터 화면을 닫은 뒤 어디로 포커스가 돌아가는지도 확인합니다.
기획 검토에서는 다음 질문을 함께 남기면 좋습니다.
기간과 상태의 이름을 처음 보는 사람도 같은 뜻으로 이해할까요?
지금 선택한 값과 이미 적용된 값을 구분할 수 있나요?
결과가 없을 때 어떤 조건부터 바꿀지 판단할 수 있나요?
초기화와 닫기, 뒤로 가기의 동작을 팀이 같은 문장으로 설명하나요?
필터의 완성도는 선택지 개수보다 사용자가 탐색을 얼마나 쉽게 이어가는지에서 드러납니다. 고르고 적용하고 결과를 읽고 하나를 해제하는 동안 조건과 화면이 같은 상태를 유지하도록 설계해 보세요.
4PS와 목록이 많은 서비스를 준비한다면 사용자가 찾아야 하는 항목과 실제 업무 순서를 함께 알려주세요. 필터 이름과 조합 규칙부터 모바일 적용 방식, 돌아오기와 초기화 정책까지 정리하고 디자인과 개발이 같은 기준으로 구현하도록 함께 설계하겠습니다.
Latest Blogs
UX/UI
필터 UX, 조건을 고르는 순간부터 해제할 때까지
필터 UX, 조건을 고르는 순간부터 해제할 때까지
필터를 선택할 수 있어도 어떤 조건이 적용됐는지 알기 어렵다면 탐색은 계속 끊깁니다. 조건 조합과 개별 해제, 모바일의 임시 선택과 적용, 상세 화면에서 돌아오는 흐름까지 필터 UX를 설계하는 기준을 살펴봅니다.
필터를 선택할 수 있어도 어떤 조건이 적용됐는지 알기 어렵다면 탐색은 계속 끊깁니다. 조건 조합과 개별 해제, 모바일의 임시 선택과 적용, 상세 화면에서 돌아오는 흐름까지 필터 UX를 설계하는 기준을 살펴봅니다.
필터를 골랐는데 무엇이 바뀌었는지 모르겠다면
업무 목록에서 상태와 담당자를 고른 뒤 필터 창을 닫습니다. 목록은 짧아졌지만 어떤 조건이 적용됐는지 보이지 않습니다. 원하는 항목이 없어서 다시 창을 열고 선택을 확인합니다. 조건을 고르는 순간만 설계하면 사용자는 결과를 읽을 때부터 기억에 의존하게 됩니다.
필터는 선택 화면과 결과 목록을 오가는 기능입니다. 어디까지 선택했고 무엇이 실제로 반영됐는지, 조건을 어떻게 고치고 되돌리는지까지 연결해야 합니다. 사용자가 현재 보고 있는 목록의 범위를 설명할 수 있어야 합니다. 선택 항목이 예쁘게 정리돼 있어도 이 질문에 답하기 어렵다면 사용 흐름을 살펴볼 필요가 있습니다.
가상의 프로젝트 관리 서비스를 예로 들어보겠습니다. 사용자는 상태, 담당자, 기간으로 업무를 좁힙니다. 진행 중이거나 검토 중인 업무 중에서 본인이 담당하고 이번 주에 마감되는 항목을 찾으려는 상황입니다. 이 글의 화면과 문구는 이 가상 서비스를 위한 설계 예시입니다.
검색과 필터, 정렬의 역할도 구분합니다. 검색은 입력한 단어나 검색식으로 대상을 찾고 필터는 속성값으로 결과 범위를 좁힙니다. 정렬은 남은 결과를 마감일순이나 최근 수정순으로 배치합니다. 사용자는 세 기능을 함께 쓰므로 화면과 정책에서도 관계를 설명해야 합니다. 필터를 지웠는데 검색어 때문에 결과가 적다면 전체 목록으로 돌아왔다고 오해할 수 있습니다.
선택지를 많이 보여주는 것이 목표는 아닙니다. 이 서비스를 쓰는 사람이 실제로 구분하는 상태와 기간이 무엇인지 먼저 확인합니다. 내부 데이터의 상태 코드나 팀만 아는 줄임말을 그대로 내놓으면 정확한 값을 골라도 의미를 알기 어렵습니다. NN/G 필터 분류와 값의 이름 안내
적용된 조건을 목록 가까이에서 읽고 고치게 합니다
선택 규칙은 화면을 만들기 전에 문장으로 적습니다
상태를 두 개 고르면 둘 중 하나만 해당해도 나오는지, 두 상태가 동시에 해당해야 하는지부터 정합니다. 같은 분류 안의 선택과 서로 다른 분류의 조합을 구분해 정의합니다. 이번 예시에서는 상태의 진행 중 또는 검토 중을 OR로 묶고 담당자와 기간은 AND로 결합합니다. 모든 서비스에 적용하는 보편 규칙이 아니라 이 목록의 정책입니다.
이 정책대로라면 진행 중인 다른 사람의 업무는 나오지 않고 본인이 담당한 검토 중 업무는 나옵니다. 기간이 마감일을 뜻하는지도 분명히 적습니다. 생성일인지 마감일인지 모르는 이번 주 필터로는 결과를 확인하기 어렵습니다.
필터 버튼의 숫자만으로는 조건을 설명하기 어렵습니다
목록 위에 상태: 진행 중, 상태: 검토 중, 담당자: 나, 마감일: 이번 주처럼 적용된 조건을 짧은 칩으로 표시할 수 있습니다. 목록을 읽는 자리에서 조건을 확인하고 하나만 해제할 수 있도록 합니다. 여러 조건을 함께 지우는 버튼도 개별 해제와 구분합니다.
Baymard의 전자상거래 연구는 적용된 필터를 요약해 보여주고 개별적으로 해제하게 하는 방법을 다룹니다. 업무 도구에서도 검토할 만한 원칙이지만 동일한 효과가 보장된다고 단정할 수는 없습니다. 실제 업무 목록에서 조건을 읽고 수정하는 흐름으로 확인해야 합니다. Baymard 적용된 필터 설계 연구
확인할 상황 | 모호한 설계 | 이번 예시의 개선안 |
|---|---|---|
적용 상태 확인 | 필터 버튼에 숫자만 표시 | 목록 위에 적용된 조건 노출 |
조건 하나 해제 | 필터 창을 다시 열어 선택 취소 | 해당 조건 칩에서 바로 해제 |
전체 초기화 | 무엇이 지워지는지 알 수 없음 | 상태·담당자·기간만 해제한다고 안내 |
결과 없음 | 항목이 없습니다로 종료 | 조건을 유지하고 해제 경로 제공 |
전체 초기화가 무엇을 지우는지 팀이 같은 뜻으로 이해해야 합니다. 이번 예시에서는 상태·담당자·기간만 해제하고 검색어와 정렬은 유지합니다. 검색어까지 지우는 설계도 가능하지만 그때는 버튼 이름과 안내가 해당 범위를 드러내야 합니다.
다음은 이 가상 서비스에서 사용할 수 있는 안내 문구입니다.
필터를 모두 해제합니다. 검색어와 정렬은 유지됩니다.
조건 칩도 무한히 늘어놓지 않습니다. 모바일에서 두 줄 이상 길어질 때 접을지 가로로 탐색할지 정하고 숨은 조건이 있다는 사실을 알려줍니다. 축약된 칩만 보여준다면 전체 조건을 확인하는 경로가 필요합니다.
모바일에서는 고르는 중인 값과 적용된 값을 나눕니다
즉시 반영과 적용 버튼은 맥락에 따라 고릅니다
데스크톱 목록 옆에서 조건을 하나씩 바꾸며 결과를 비교한다면 즉시 반영이 자연스러울 수 있습니다. 반면 모바일에서 필터 화면이 목록을 덮고 여러 조건을 한꺼번에 고른다면 마지막에 적용하는 방식이 더 적합할 수 있습니다. 선택 하나마다 긴 요청을 보내거나 화면이 크게 움직이는 경우도 고려합니다. NN/G 필터 적용 방식 안내
적용 버튼이 있는 화면에서는 임시 선택과 실제 적용값을 구분합니다. 이번 모바일 예시에서는 창을 열 때 적용값을 임시 선택으로 가져오고 사용자가 바꾸는 동안 목록의 조건은 그대로 둡니다. 적용을 눌렀을 때만 선택을 확정합니다. 임시 선택인데 목록 위 칩까지 바뀌면 이미 반영됐는지 헷갈립니다.
적용 전에 X나 바깥 영역, 기기의 뒤로 가기로 닫았을 때의 동작도 통일합니다. 이번 예시에서는 미적용 변경을 버리고 기존 조건을 유지합니다. 다시 열면 마지막 적용값을 보여줍니다. 미적용 선택을 보관하는 서비스라면 보관 중임을 알려야 하며 이번 예시처럼 처리할 필요는 없습니다.
반영 중에도 현재 상황을 알 수 있어야 합니다
조건을 확정한 뒤 결과를 받는 시간이 걸린다면 반영 중이라는 표시를 둡니다. 기존 항목을 남겨둘 경우 아직 이전 결과라는 사실을 구분하고 새 결과처럼 읽히지 않게 합니다. 선택을 빠르게 바꾸면 이전 요청의 응답이 늦게 도착할 수 있습니다. 이 응답이 최신 결과를 덮어쓰지 않는지도 개발에서 확인해야 합니다.
조건 표시와 결과 목록은 같은 적용 상태를 가리켜야 합니다. 상태 칩은 검토 중인데 목록은 직전 진행 중 요청의 결과라면 사용자는 잘못된 업무를 보고 있다고 생각하지 못할 수 있습니다. 로딩의 모양보다 상태가 서로 어긋나지 않는지가 먼저입니다.
결과가 없다고 선택을 자동으로 지우지는 않습니다. 무엇을 골라서 결과가 없어졌는지 확인할 수 있도록 조건을 남겨두고 개별 해제나 전체 초기화로 돌아가게 합니다. 검색어도 함께 적용돼 있다면 어느 범위를 해제하는지 구분합니다. 빈 화면을 장식하기보다 다음 수정 행동을 바로 시작할 수 있게 만드는 데 집중합니다.
상세에서 돌아왔을 때도 목록의 맥락을 이어갑니다
업무 하나를 열어 확인한 뒤 돌아왔는데 필터가 풀리고 목록 맨 위로 이동하면 다시 찾는 일이 생깁니다. 같은 탐색을 계속하는 상황이라면 조건과 정렬, 스크롤 위치를 유지하는 것을 우선 검토합니다. 새로고침이나 새 세션에서도 유지할지는 별도 정책입니다.
기간도 해석을 정합니다. 이번 주처럼 현재 날짜에 따라 범위가 달라지는 값과 사용자가 직접 고른 고정 날짜는 다릅니다. 오래 열어둔 화면을 다시 볼 때 어떤 날짜 범위가 적용되는지 사용자에게 설명할 수 있어야 합니다.
완료 기준은 선택창이 아니라 실제 탐색 시나리오입니다
출시 전에는 조건을 선택하는 화면만 눌러보지 말고 찾기부터 해제까지 이어서 확인합니다. 정상적으로 결과가 나오는 조합 하나로 테스트를 끝내면 개별 해제나 재진입처럼 자주 쓰는 동작이 빠지기 쉽습니다.
진행 중과 검토 중, 담당자 나, 마감일 이번 주를 선택합니다. 예시 정책의 OR와 AND 조합대로 결과가 나오는지 확인합니다.
상태 한 개만 해제합니다. 다른 상태와 담당자, 기간이 남고 목록도 그에 맞게 바뀌는지 봅니다.
모바일 필터에서 값을 바꾼 뒤 적용하지 않고 닫습니다. 목록은 그대로인지, 다시 열었을 때 기존 적용값이 보이는지 확인합니다.
조건을 빠르게 바꾸고 응답을 기다립니다. 최신 선택과 조건 칩, 결과가 일치하는지 봅니다.
상세를 열었다 돌아옵니다. 정한 정책대로 조건·정렬·스크롤 위치가 유지되는지 확인합니다.
전체 초기화를 실행합니다. 지우기로 한 값만 사라지고 검색어와 정렬의 유지 여부도 안내와 같은지 봅니다.
마우스로 고를 수 있다는 사실만으로 사용성을 확인했다고 보기는 어렵습니다. 키보드로 필터를 열고 선택하고 적용하거나 닫는 경로도 점검합니다. 칩의 X에는 담당자 필터 해제처럼 무엇을 지우는 버튼인지 알 수 있는 이름을 제공합니다. 필터 화면을 닫은 뒤 어디로 포커스가 돌아가는지도 확인합니다.
기획 검토에서는 다음 질문을 함께 남기면 좋습니다.
기간과 상태의 이름을 처음 보는 사람도 같은 뜻으로 이해할까요?
지금 선택한 값과 이미 적용된 값을 구분할 수 있나요?
결과가 없을 때 어떤 조건부터 바꿀지 판단할 수 있나요?
초기화와 닫기, 뒤로 가기의 동작을 팀이 같은 문장으로 설명하나요?
필터의 완성도는 선택지 개수보다 사용자가 탐색을 얼마나 쉽게 이어가는지에서 드러납니다. 고르고 적용하고 결과를 읽고 하나를 해제하는 동안 조건과 화면이 같은 상태를 유지하도록 설계해 보세요.
4PS와 목록이 많은 서비스를 준비한다면 사용자가 찾아야 하는 항목과 실제 업무 순서를 함께 알려주세요. 필터 이름과 조합 규칙부터 모바일 적용 방식, 돌아오기와 초기화 정책까지 정리하고 디자인과 개발이 같은 기준으로 구현하도록 함께 설계하겠습니다.
Latest Blogs
UX/UI
필터 UX, 조건을 고르는 순간부터 해제할 때까지
필터 UX, 조건을 고르는 순간부터 해제할 때까지
필터를 선택할 수 있어도 어떤 조건이 적용됐는지 알기 어렵다면 탐색은 계속 끊깁니다. 조건 조합과 개별 해제, 모바일의 임시 선택과 적용, 상세 화면에서 돌아오는 흐름까지 필터 UX를 설계하는 기준을 살펴봅니다.
필터를 선택할 수 있어도 어떤 조건이 적용됐는지 알기 어렵다면 탐색은 계속 끊깁니다. 조건 조합과 개별 해제, 모바일의 임시 선택과 적용, 상세 화면에서 돌아오는 흐름까지 필터 UX를 설계하는 기준을 살펴봅니다.
필터를 골랐는데 무엇이 바뀌었는지 모르겠다면
업무 목록에서 상태와 담당자를 고른 뒤 필터 창을 닫습니다. 목록은 짧아졌지만 어떤 조건이 적용됐는지 보이지 않습니다. 원하는 항목이 없어서 다시 창을 열고 선택을 확인합니다. 조건을 고르는 순간만 설계하면 사용자는 결과를 읽을 때부터 기억에 의존하게 됩니다.
필터는 선택 화면과 결과 목록을 오가는 기능입니다. 어디까지 선택했고 무엇이 실제로 반영됐는지, 조건을 어떻게 고치고 되돌리는지까지 연결해야 합니다. 사용자가 현재 보고 있는 목록의 범위를 설명할 수 있어야 합니다. 선택 항목이 예쁘게 정리돼 있어도 이 질문에 답하기 어렵다면 사용 흐름을 살펴볼 필요가 있습니다.
가상의 프로젝트 관리 서비스를 예로 들어보겠습니다. 사용자는 상태, 담당자, 기간으로 업무를 좁힙니다. 진행 중이거나 검토 중인 업무 중에서 본인이 담당하고 이번 주에 마감되는 항목을 찾으려는 상황입니다. 이 글의 화면과 문구는 이 가상 서비스를 위한 설계 예시입니다.
검색과 필터, 정렬의 역할도 구분합니다. 검색은 입력한 단어나 검색식으로 대상을 찾고 필터는 속성값으로 결과 범위를 좁힙니다. 정렬은 남은 결과를 마감일순이나 최근 수정순으로 배치합니다. 사용자는 세 기능을 함께 쓰므로 화면과 정책에서도 관계를 설명해야 합니다. 필터를 지웠는데 검색어 때문에 결과가 적다면 전체 목록으로 돌아왔다고 오해할 수 있습니다.
선택지를 많이 보여주는 것이 목표는 아닙니다. 이 서비스를 쓰는 사람이 실제로 구분하는 상태와 기간이 무엇인지 먼저 확인합니다. 내부 데이터의 상태 코드나 팀만 아는 줄임말을 그대로 내놓으면 정확한 값을 골라도 의미를 알기 어렵습니다. NN/G 필터 분류와 값의 이름 안내
적용된 조건을 목록 가까이에서 읽고 고치게 합니다
선택 규칙은 화면을 만들기 전에 문장으로 적습니다
상태를 두 개 고르면 둘 중 하나만 해당해도 나오는지, 두 상태가 동시에 해당해야 하는지부터 정합니다. 같은 분류 안의 선택과 서로 다른 분류의 조합을 구분해 정의합니다. 이번 예시에서는 상태의 진행 중 또는 검토 중을 OR로 묶고 담당자와 기간은 AND로 결합합니다. 모든 서비스에 적용하는 보편 규칙이 아니라 이 목록의 정책입니다.
이 정책대로라면 진행 중인 다른 사람의 업무는 나오지 않고 본인이 담당한 검토 중 업무는 나옵니다. 기간이 마감일을 뜻하는지도 분명히 적습니다. 생성일인지 마감일인지 모르는 이번 주 필터로는 결과를 확인하기 어렵습니다.
필터 버튼의 숫자만으로는 조건을 설명하기 어렵습니다
목록 위에 상태: 진행 중, 상태: 검토 중, 담당자: 나, 마감일: 이번 주처럼 적용된 조건을 짧은 칩으로 표시할 수 있습니다. 목록을 읽는 자리에서 조건을 확인하고 하나만 해제할 수 있도록 합니다. 여러 조건을 함께 지우는 버튼도 개별 해제와 구분합니다.
Baymard의 전자상거래 연구는 적용된 필터를 요약해 보여주고 개별적으로 해제하게 하는 방법을 다룹니다. 업무 도구에서도 검토할 만한 원칙이지만 동일한 효과가 보장된다고 단정할 수는 없습니다. 실제 업무 목록에서 조건을 읽고 수정하는 흐름으로 확인해야 합니다. Baymard 적용된 필터 설계 연구
확인할 상황 | 모호한 설계 | 이번 예시의 개선안 |
|---|---|---|
적용 상태 확인 | 필터 버튼에 숫자만 표시 | 목록 위에 적용된 조건 노출 |
조건 하나 해제 | 필터 창을 다시 열어 선택 취소 | 해당 조건 칩에서 바로 해제 |
전체 초기화 | 무엇이 지워지는지 알 수 없음 | 상태·담당자·기간만 해제한다고 안내 |
결과 없음 | 항목이 없습니다로 종료 | 조건을 유지하고 해제 경로 제공 |
전체 초기화가 무엇을 지우는지 팀이 같은 뜻으로 이해해야 합니다. 이번 예시에서는 상태·담당자·기간만 해제하고 검색어와 정렬은 유지합니다. 검색어까지 지우는 설계도 가능하지만 그때는 버튼 이름과 안내가 해당 범위를 드러내야 합니다.
다음은 이 가상 서비스에서 사용할 수 있는 안내 문구입니다.
필터를 모두 해제합니다. 검색어와 정렬은 유지됩니다.
조건 칩도 무한히 늘어놓지 않습니다. 모바일에서 두 줄 이상 길어질 때 접을지 가로로 탐색할지 정하고 숨은 조건이 있다는 사실을 알려줍니다. 축약된 칩만 보여준다면 전체 조건을 확인하는 경로가 필요합니다.
모바일에서는 고르는 중인 값과 적용된 값을 나눕니다
즉시 반영과 적용 버튼은 맥락에 따라 고릅니다
데스크톱 목록 옆에서 조건을 하나씩 바꾸며 결과를 비교한다면 즉시 반영이 자연스러울 수 있습니다. 반면 모바일에서 필터 화면이 목록을 덮고 여러 조건을 한꺼번에 고른다면 마지막에 적용하는 방식이 더 적합할 수 있습니다. 선택 하나마다 긴 요청을 보내거나 화면이 크게 움직이는 경우도 고려합니다. NN/G 필터 적용 방식 안내
적용 버튼이 있는 화면에서는 임시 선택과 실제 적용값을 구분합니다. 이번 모바일 예시에서는 창을 열 때 적용값을 임시 선택으로 가져오고 사용자가 바꾸는 동안 목록의 조건은 그대로 둡니다. 적용을 눌렀을 때만 선택을 확정합니다. 임시 선택인데 목록 위 칩까지 바뀌면 이미 반영됐는지 헷갈립니다.
적용 전에 X나 바깥 영역, 기기의 뒤로 가기로 닫았을 때의 동작도 통일합니다. 이번 예시에서는 미적용 변경을 버리고 기존 조건을 유지합니다. 다시 열면 마지막 적용값을 보여줍니다. 미적용 선택을 보관하는 서비스라면 보관 중임을 알려야 하며 이번 예시처럼 처리할 필요는 없습니다.
반영 중에도 현재 상황을 알 수 있어야 합니다
조건을 확정한 뒤 결과를 받는 시간이 걸린다면 반영 중이라는 표시를 둡니다. 기존 항목을 남겨둘 경우 아직 이전 결과라는 사실을 구분하고 새 결과처럼 읽히지 않게 합니다. 선택을 빠르게 바꾸면 이전 요청의 응답이 늦게 도착할 수 있습니다. 이 응답이 최신 결과를 덮어쓰지 않는지도 개발에서 확인해야 합니다.
조건 표시와 결과 목록은 같은 적용 상태를 가리켜야 합니다. 상태 칩은 검토 중인데 목록은 직전 진행 중 요청의 결과라면 사용자는 잘못된 업무를 보고 있다고 생각하지 못할 수 있습니다. 로딩의 모양보다 상태가 서로 어긋나지 않는지가 먼저입니다.
결과가 없다고 선택을 자동으로 지우지는 않습니다. 무엇을 골라서 결과가 없어졌는지 확인할 수 있도록 조건을 남겨두고 개별 해제나 전체 초기화로 돌아가게 합니다. 검색어도 함께 적용돼 있다면 어느 범위를 해제하는지 구분합니다. 빈 화면을 장식하기보다 다음 수정 행동을 바로 시작할 수 있게 만드는 데 집중합니다.
상세에서 돌아왔을 때도 목록의 맥락을 이어갑니다
업무 하나를 열어 확인한 뒤 돌아왔는데 필터가 풀리고 목록 맨 위로 이동하면 다시 찾는 일이 생깁니다. 같은 탐색을 계속하는 상황이라면 조건과 정렬, 스크롤 위치를 유지하는 것을 우선 검토합니다. 새로고침이나 새 세션에서도 유지할지는 별도 정책입니다.
기간도 해석을 정합니다. 이번 주처럼 현재 날짜에 따라 범위가 달라지는 값과 사용자가 직접 고른 고정 날짜는 다릅니다. 오래 열어둔 화면을 다시 볼 때 어떤 날짜 범위가 적용되는지 사용자에게 설명할 수 있어야 합니다.
완료 기준은 선택창이 아니라 실제 탐색 시나리오입니다
출시 전에는 조건을 선택하는 화면만 눌러보지 말고 찾기부터 해제까지 이어서 확인합니다. 정상적으로 결과가 나오는 조합 하나로 테스트를 끝내면 개별 해제나 재진입처럼 자주 쓰는 동작이 빠지기 쉽습니다.
진행 중과 검토 중, 담당자 나, 마감일 이번 주를 선택합니다. 예시 정책의 OR와 AND 조합대로 결과가 나오는지 확인합니다.
상태 한 개만 해제합니다. 다른 상태와 담당자, 기간이 남고 목록도 그에 맞게 바뀌는지 봅니다.
모바일 필터에서 값을 바꾼 뒤 적용하지 않고 닫습니다. 목록은 그대로인지, 다시 열었을 때 기존 적용값이 보이는지 확인합니다.
조건을 빠르게 바꾸고 응답을 기다립니다. 최신 선택과 조건 칩, 결과가 일치하는지 봅니다.
상세를 열었다 돌아옵니다. 정한 정책대로 조건·정렬·스크롤 위치가 유지되는지 확인합니다.
전체 초기화를 실행합니다. 지우기로 한 값만 사라지고 검색어와 정렬의 유지 여부도 안내와 같은지 봅니다.
마우스로 고를 수 있다는 사실만으로 사용성을 확인했다고 보기는 어렵습니다. 키보드로 필터를 열고 선택하고 적용하거나 닫는 경로도 점검합니다. 칩의 X에는 담당자 필터 해제처럼 무엇을 지우는 버튼인지 알 수 있는 이름을 제공합니다. 필터 화면을 닫은 뒤 어디로 포커스가 돌아가는지도 확인합니다.
기획 검토에서는 다음 질문을 함께 남기면 좋습니다.
기간과 상태의 이름을 처음 보는 사람도 같은 뜻으로 이해할까요?
지금 선택한 값과 이미 적용된 값을 구분할 수 있나요?
결과가 없을 때 어떤 조건부터 바꿀지 판단할 수 있나요?
초기화와 닫기, 뒤로 가기의 동작을 팀이 같은 문장으로 설명하나요?
필터의 완성도는 선택지 개수보다 사용자가 탐색을 얼마나 쉽게 이어가는지에서 드러납니다. 고르고 적용하고 결과를 읽고 하나를 해제하는 동안 조건과 화면이 같은 상태를 유지하도록 설계해 보세요.
4PS와 목록이 많은 서비스를 준비한다면 사용자가 찾아야 하는 항목과 실제 업무 순서를 함께 알려주세요. 필터 이름과 조합 규칙부터 모바일 적용 방식, 돌아오기와 초기화 정책까지 정리하고 디자인과 개발이 같은 기준으로 구현하도록 함께 설계하겠습니다.