빈 상태 UI 디자인 패턴: 사용자가 다음 단계로 나아가게 하기

빈 상태 화면은 콘텐츠가 없는 이유와 지금 할 수 있는 다음 행동을 알려 줘야 합니다. 새 프로젝트에는 첫 파일을 만드는 방법이, 일치 항목이 없는 검색에는 검색 조건을 바꾸는 방법이, 실패한 요청에는 복구 방법이 필요합니다. 세 상황을 모두 “아무것도 없습니다”라고 표시하면 사용자가 문제의 원인을 직접 추측해야 합니다.

애플리케이션이 실제로 알고 있는 사실부터 확인하세요. 요청이 아직 진행 중이면 진행 상태를 표시합니다. 요청이 실패했다면 오류를 실제로 비어 있는 컬렉션과 구분합니다. 관련 쿼리가 성공적으로 완료된 뒤에만 결과가 0건이라는 화면을 보여 줘야 합니다.

아래 패턴은 파일 영역, 검색, 대시보드, 공유 워크스페이스에서 사용할 수 있습니다. 안내 문구와 복구 행동부터 개발에 전달할 상태 로직까지 다루며, 내비게이션 바 디자인(영문)과 팝업 UI 디자인(영문)의 확인 패턴을 보완합니다.

사용자가 하려던 작업부터 파악하기

아이콘을 고르거나 문구를 쓰기 전에 사용자가 완료하려던 작업을 파악하세요. “파일 없음”은 팀이 아직 파일을 만들지 않았다는 뜻일 수도 있고, 필터가 모든 파일을 숨기고 있거나 파일 가져오기가 아직 진행 중이거나 사용자가 파일에 접근할 수 없다는 뜻일 수도 있습니다. 각 상태에는 서로 다른 설명과 행동이 필요합니다.

현재 상태를 짧은 문장으로 정리합니다.

“이 프로젝트에는 아직 파일이 없습니다. 프로젝트를 편집할 수 있는 멤버가 첫 파일을 만들 수 있습니다.”

이 문장은 눈에 보이는 상태와 권장 행동을 구분하고, 확인이 필요한 가정도 드러냅니다. 사용자가 “mobile”을 검색했을 뿐이라면 올바른 설명은 “이 검색과 일치하는 항목이 없습니다”입니다. “워크스페이스가 비어 있습니다”라고 말해서는 안 됩니다.

컴포넌트를 설계하기 전에 간단한 상태 기록을 만듭니다.

이 기록은 개발에 전달할 유용한 자료가 됩니다. 시각적 디자인이 제품에서 뒷받침할 수 없는 내용을 약속하지 않도록 막아 줍니다.

빈 화면을 네 가지 패턴으로 구분하기

첫 사용 상태

컬렉션이 실제로 처음 만들어진 상태입니다. 용도를 한 문장으로 설명하고, 가치를 만들어 내는 가장 작은 행동을 제안하세요. 프로젝트 보드라면 “여기에서 결정 사항과 담당자를 관리하세요”라는 문구와 “보드 만들기” 버튼을 제공할 수 있습니다. 사용자가 기능을 시도하기도 전에 긴 튜토리얼을 보여 주지 마세요. 템플릿이 도움이 된다면 유일한 시작 경로가 아니라 보조 선택지로 둡니다.

검색 결과 없음 상태

컬렉션에는 데이터가 있지만 현재 검색어나 필터에 맞는 항목이 없는 상태입니다. 검색어를 화면에 남기고 조건을 정확히 설명하며, “필터 지우기”나 “모든 프로젝트에서 검색”처럼 되돌릴 수 있는 행동을 제공합니다. 항목 생성이 해당 검색에 실제로 도움이 되는 경우에만 “만들기” 버튼을 보여 주세요. 기존 청구서를 찾는 사용자에게 중복 청구서를 만들도록 유도해서는 안 됩니다.

완료되었거나 의도적으로 비어 있는 상태

빈 상태가 긍정적인 결과일 때도 있습니다. 처리할 검토 작업이 없는 받은편지함에는 행동을 촉구하기보다 조용한 확인 문구가 적절할 수 있습니다. “이 프로젝트에 진행 중인 검토 요청이 없습니다”처럼 범위를 명시하고, 기간 조건이 있다면 그것도 알려 주세요. 다른 작업을 제공할 때는 낮은 강조의 링크로 배치해 완료된 느낌을 유지합니다.

접근 제한 또는 오류 상태

예상한 콘텐츠를 가져올 수 없거나 현재 사용자에게 열람 권한이 없는 상태입니다. 두 원인을 구분하세요. 실패한 요청에는 “다시 시도”를, 확인된 권한 제한에는 제품이 해당 경로를 지원할 때 “접근 요청”을 제공합니다. 검색어와 입력한 데이터는 보존합니다. 리소스의 존재 여부를 공개할 수 없다면 이름이나 내용을 확인해 주지 말고, 사전에 정한 중립적인 안내 문구를 사용합니다.

각 패턴은 시각적으로도 의미상으로도 구분되어야 합니다. 로딩 표시, 검색 결과 없음 일러스트, 접근 제한 자물쇠가 같은 컴포넌트 틀을 사용할 수는 있지만 문구와 버튼의 우선순위까지 같아서는 안 됩니다.

명확한 복구 행동 하나를 제시하기

주요 행동은 현재 맥락에서 이해할 수 있는 동사로 표현하세요. “프로젝트 만들기”, “필터 지우기”, “다시 시도”, “접근 요청”, “파일 가져오기”가 예입니다. 설명 가까이에 배치하고 행동 후에도 현재 위치를 유지합니다. 새로운 흐름을 여는 행동이라면 “계속” 뒤에 숨기지 말고 라벨에서 이를 알려 주세요.

보조 행동에는 “모든 프로젝트 보기”, “권한 작동 방식 알아보기”, “관리자에게 문의”처럼 안전한 대안을 둡니다. 가능한 경로 다섯 개에 같은 시각적 비중을 주지 마세요. 선택지가 너무 많으면 도움을 주려던 빈 상태 화면이 다시 선택을 요구하는 화면으로 바뀝니다.

버튼 라벨은 번역되거나 스크린 리더로 읽혀도 구체적이어야 합니다. “실행” 같은 라벨은 주변 그림이 없으면 유용한 맥락을 주지 못합니다. 간격과 서체는 제품의 기존 UI 디자인 원칙에 맞추고, 장식 패널에 넣기 위해 본문 글자를 줄이지 마세요.

검색과 필터의 맥락 보존하기

빈 상태를 잘못 처리했을 때 불필요한 작업이 가장 많이 발생하는 곳은 검색과 필터입니다. 활성 필터 칩이나 검색어를 메시지 위에 표시하고 초기화 행동을 쉽게 찾게 하세요. 날짜 범위가 설정되어 있다면 숨겨진 컨트롤 상태에만 의존하지 말고 사람이 읽을 수 있는 표현으로 다시 보여 줍니다.

필터가 여러 개 켜져 있다면 복구 행동이 정확히 무엇을 바꾸는지 보여 주세요. “보관됨” 필터를 제거하면 관련 결과가 나타나는 경우에는 “초기화”보다 “보관됨 필터 제거”가 명확합니다. 어떤 필터가 결과를 비게 했는지 애플리케이션이 알 수 없다면 개별 필터를 제거하거나 전체를 지울 수 있게 합니다. 확인하지 않은 특정 변경이 결과를 복원한다고 암시하지 마세요. 저장된 보기 이름도 남겨 “이 보기에서 결과 없음”과 “워크스페이스에 항목 없음”을 구분합니다.

표 본문이 비어 있어도 열 머리글은 유지합니다. 머리글은 사용자의 위치 파악을 돕고 어떤 데이터가 들어올지 보여 줍니다. 대시보드에서는 기간과 지표 이름을 남긴 뒤 값이 0인지, 이용할 수 없는지, 수집되지 않았는지 설명하세요. 빈 차트와 값이 0인 차트는 서로 바꿔 쓸 수 없습니다.

권한 상태에 맞는 별도의 설명 제공하기

권한 때문에 비어 보이는 화면에는 신중한 문구가 필요합니다. 접근 권한만 없는데 “프로젝트가 없습니다”라고 하면 오해를 부릅니다. 비공개 정보를 드러내지 않으면서 경계를 설명하세요. “이 보기에 있는 프로젝트에 접근할 수 없습니다”라고 알리고, 실제로 가능한 경우 “접근 요청”을 제공할 수 있습니다. 소유자 정보나 정책 설명은 제품이 정확하게 표시할 수 있을 때만 포함합니다.

파일 영역과 협업 도구에도 같은 원칙이 적용됩니다. 한 멤버에게 비어 보이는 공유 폴더가 다른 멤버에게는 채워져 있을 수 있습니다. 페이지 구조를 바꾸지 않고 역할별 행동을 표시할 수 있도록 컴포넌트를 설계하세요. 업로드 영역에는 빈 상태와 함께 실제 제약 및 복구 경로를 제공합니다. 파일 업로드 UI 디자인 패턴(영문)도 참고할 수 있습니다.

실제 콘텐츠와 다양한 조건을 견디는 컴포넌트 만들기

빈 상태는 두 줄짜리 영어 문구로 디자인하고 한 가지 폭에서만 테스트하기 쉽습니다. 컴포넌트 리뷰에 긴 번역문, 선택적 설명이 빠진 경우, 비활성 행동, 좁은 모바일 화면을 추가하세요. 높이가 짧은 화면에서 일러스트가 주요 행동을 첫 화면 아래로 밀어내지 않는지 확인합니다.

컴포넌트는 일부만 처리된 상태도 다룰 수 있어야 합니다. 목록에 카드 일부는 표시되지만 요청 하나가 실패할 수도 있고, 백그라운드 가져오기가 진행 중이라 첫 페이지가 비어 있을 수도 있습니다. 이때는 전체 페이지를 빈 패널로 바꾸지 말고 영향을 받는 범위 가까이에 인라인 상태를 표시합니다. 성공적으로 가져온 콘텐츠는 보존하고 어떤 내용이 아직 갱신 중인지 알려 주세요.

팀 대시보드에서는 비어 있는 지표가 0, 해당 없음, 대기 중, 사용 불가 중 무엇인지 정해야 합니다. 대시보드 UI 예시(영문)는 정보의 우선순위를 잡는 데 도움이 되지만 상태 정의는 제품의 데이터 계약에서 나와야 합니다. 카드가 완성되어 보이게 하려고 누락값을 안심을 주는 0으로 바꾸지 마세요.

Pixso 파일 하나에 파일이 없는 새 프로젝트, 일치 항목이 없는 검색, 검토자가 접근할 수 없는 파일의 세 가지 빈 상태를 만듭니다. 레이아웃은 일관되게 유지하되 각각 다른 설명과 행동을 제공합니다. 좁은 폭에서 카드를 비교한 뒤 동료에게 무슨 일이 일어났고 다음에 무엇을 해야 하는지 물어보세요. 개발 전달 전에 포괄적인 문구나 오해를 부르는 버튼을 발견할 수 있습니다.

Pixso에서 빈 상태 만들고 비교하기 →

개발에 전달할 상태 동작 기록하기

상태 이름, 발생 조건, 화면 문구, 행동, 분석 이벤트, 행동 후 돌아오는 방식을 기록합니다. 보통은 간단한 표로 충분합니다.

현재 화면 안에서 검색 결과를 갱신할 때는 검색 컨트롤에서 포커스를 옮기지 않고 결과 메시지를 보조기기에 전달하세요. “invoice 검색 결과가 없습니다” 같은 짧은 문구에는 적절한 상태 알림 방식을 사용할 수 있습니다. 결과 패널 전체를 실시간 알림 영역인 live region으로 만들면 안내가 반복될 수 있습니다. 포커스 이동은 대화상자를 여는 것처럼 실제로 맥락이 바뀌는 상호작용에만 사용합니다. 문구·행동 이름과 함께 이 동작을 기록하세요. W3C 상태 메시지 지침(영문)에서 차이를 설명합니다.

현실적인 시나리오로 문구 검증하기

신규 사용자, 재방문 사용자, 저장된 필터를 쓰는 사용자, 접근 권한이 제한된 사용자, 느린 연결을 쓰는 사용자에게 같은 컴포넌트를 테스트합니다. 무슨 일이 일어났다고 생각하는지, 다음에 무엇을 할지 각자 말하게 하세요. 두 시나리오가 같은 화면으로 표시되지만 필요한 설명이 다르다면 데이터 모델과 콘텐츠 모델에서 상태 차이를 명시합니다.

놓치기 쉬운 예외 상황도 검토합니다.

1. 재시도가 성공했는데 페이지에 이전 오류 메시지가 남아 있는 경우
2. 검색어의 문자가 이스케이프 처리되거나 잘려 표시되는 경우
3. 번역된 행동 라벨이 세 줄로 줄바꿈되어 버튼 폭이 바뀌는 경우
4. 빈 상태 화면을 열어 둔 동안 사용자가 권한을 잃는 경우
5. 가져오기가 아직 진행 중이라 컬렉션이 비어 있는 경우
6. 읽기 전용 멤버는 해당 행동을 사용할 수 없는 경우

이 사례들을 같은 디자인 파일에 기록하고 최종 컴포넌트를 구현 메모와 연결합니다. 개별 스크린샷을 모아 두는 것보다 일관된 흐름을 유지하는 편이 관리하기 쉽습니다. 디자인-코드 핸드오프(영문)에서도 상태와 결정을 기록하는 방법을 참고할 수 있습니다.

세 가지 실패 조건에서 컴포넌트 시험하기

개발에 전달하기 전에 연결이 느릴 때, 요청이 실패한 뒤, 실제로 일치 항목이 없는 필터를 적용했을 때 같은 쿼리를 실행합니다. 화면이 각 조건을 정확히 구분하고 복구 과정 내내 검색어를 유지해야 합니다. 이어서 읽기 전용 멤버로 검색 결과 없음 사례를 반복하세요. “만들기” 버튼은 그 사람이 해당 객체를 실제로 생성할 수 있을 때만 보여야 합니다. 이 사례를 통해 메시지가 제품 상태를 따르는지, 단지 빈 영역을 채우는지 알 수 있습니다.

추가 읽을거리

• W3C: 상태 메시지 이해(영문)
• W3C 웹 콘텐츠 접근성 지침 2.2(영문)
• MDN: 접근 가능한 이름(영문)