Empty State는 빈 화면이 아니라 다음 행동을 설계하는 화면이다

먼저 던질 질문

데이터가 없을 때 사용자는 무엇을 기대하는가

빈 화면은 하나의 상태가 아니다. 처음 사용해서 비어 있는지, 필터 때문에 결과가 없는지, 권한이 없어 볼 수 없는지, 로딩이나 오류가 끝나지 않은 것인지에 따라 사용자가 해야 할 행동은 완전히 달라진다.

이 글에서는 처음 사용 상태, 결과 없음 상태, 권한 없음 상태를 비교한다. 목표는 빈 공간을 꾸미는 것이 아니라 사용자가 왜 막혔는지 이해하고 다음 행동을 선택하게 만드는 것이다.

핵심 관점

Empty State는 빈 공간을 채우는 장식이 아니라 사용자의 막힘을 해석하는 장치다. 같은 빈 화면이라도 처음 사용, 검색 결과 없음, 권한 없음, 오류는 완전히 다른 메시지를 요구한다.

같은 일러스트와 같은 문구로 모든 빈 화면을 처리하면 가장 중요한 원인이 사라진다. Empty State는 데이터 유무가 아니라 원인과 다음 행동의 문제다.

상태가 잘 읽히는 장면

처음 가입한 대시보드에서 샘플 프로젝트, 새 프로젝트 만들기, 팀원 초대하기를 제공한다.

이때 빈 화면은 제품이 아직 쓸모없다는 신호가 아니라 첫 작업을 시작하는 입구가 된다.

검색 결과가 없을 때 검색어 수정, 필터 초기화, 추천 검색어를 함께 제공한다.

사용자는 결과가 없다는 사실보다 어떤 조건을 바꾸면 탐색을 이어갈 수 있는지 먼저 이해한다.

좋은 Empty State는 데이터가 없다는 사실보다 왜 비어 있는지와 무엇을 시작하면 되는지를 먼저 설명한다.

사용자를 막는 상태

모든 빈 화면에 표시할 항목이 없습니다만 보여준다.

사용자는 원인을 알 수 없고 다음 행동도 알 수 없다. 이 경우 사용자는 화면의 의도를 스스로 추측해야 한다.

UX가 나빠지는 순간은 대개 사용자가 다음 행동을 알 수 없을 때다.

권한이 없어서 데이터가 보이지 않는 상황을 데이터 없음으로 처리한다.

사용자는 요청 권한이나 관리자 문의가 필요한지 알 수 없다. 이런 문제는 구현 단계에서도 자주 반복된다.

정상 상태만 만들고 예외 상태를 나중에 붙이면 문구, 포커스, 버튼 상태, 재시도 흐름이 제각각이 된다.

상태 피드백 사례와 근거

빈 상태는 데이터 없음이 아니라 상황 설명이다

Empty State는 처음 방문, 검색 결과 없음, 권한 없음, 필터 결과 없음, 오류를 구분해야 한다. 모두 비어 보이지만 사용자가 던지는 질문과 필요한 다음 행동이 다르다.

프로젝트 관리 도구의 첫 화면은 새 프로젝트 만들기나 샘플 프로젝트를 제안해야 하고, 검색 결과 없음 화면은 검색어 수정이나 필터 해제를 제안해야 한다. 아무것도 렌더링하지 않으면 사용자는 로딩 중인지 정말 비어 있는지 판단할 수 없다.

협업 도구, 문서 도구, 쇼핑 검색, 관리자 콘솔을 비교하면 빈 상태의 역할이 달라진다. 협업 도구의 첫 화면은 시작을 도와야 하고, 쇼핑 검색의 결과 없음은 조건 수정을 도와야 하며, 관리자 콘솔의 권한 없음은 요청 경로를 알려줘야 한다. 같은 empty라도 사용자의 질문이 다르면 화면의 책임도 달라진다.

실무 해석

프론트엔드에서는 isEmpty 하나로 끝내지 말고 first use, no search result, filtered out, permission denied, load failed 같은 상태를 분리하는 편이 좋다. 사용자가 다르게 해석하는 상태는 코드에서도 다르게 표현되어야 한다.

접근성 측면에서는 빈 상태가 실제 콘텐츠 영역의 상태 변화임을 전달해야 한다. 로딩이 끝난 뒤 결과가 없어진 것인지, 필터 조건이 바뀐 것인지, 권한 문제로 숨겨진 것인지 스크린 리더 사용자가 이해할 수 있어야 한다.

피드백 설계 기준

빈 상태는 첫 사용, 필터 결과 없음, 권한 없음, 오류를 구분할 때 품질이 갈린다.

기준 1. 비어 있는 원인이 무엇인지 먼저 구분한다

처음 사용 상태라면 시작 행동이 필요하고, 검색 결과 없음이라면 조건 수정이 필요하다. 권한 없음이라면 요청 경로가 필요하고, 오류라면 재시도나 문의가 필요하다.

기준 2. 사용자가 지금 할 수 있는 가장 작은 다음 행동을 제안한다

새 프로젝트 만들기, 필터 초기화, 권한 요청, 샘플 데이터 열기처럼 즉시 실행 가능한 행동을 제안한다. 행동이 너무 크면 빈 상태가 다시 온보딩 장벽이 된다.

기준 3. CTA가 필요한 빈 상태와 설명만으로 충분한 빈 상태를 나눈다

모든 빈 상태에 버튼이 필요한 것은 아니다. 읽기 전용 히스토리처럼 사용자가 채울 수 없는 영역은 설명만으로 충분할 수 있고, 첫 사용 대시보드처럼 시작 행동이 필요한 곳은 CTA가 필요하다.

기준 4. 빈 상태가 로딩이나 오류처럼 보이지 않게 한다

결과가 없다는 확정 상태와 아직 데이터를 가져오는 중인 상태는 다르게 보여야 한다. 빈 컨테이너만 먼저 렌더링하면 사용자는 로딩이 멈춘 것인지, 결과가 없는 것인지, 권한 때문에 숨겨진 것인지 구분하지 못한다.

자주 빠지는 함정

모든 빈 상태에 같은 일러스트와 같은 문구를 쓰면 가장 중요한 원인이 사라진다. 비어 있음은 하나의 상태가 아니라 여러 상태의 결과다.

Empty State를 상태 모델로 바꾸기

Empty State는 isEmpty 하나로 처리하기보다 원인별 상태로 나누는 편이 안전하다.

• firstUse: 사용자가 아직 데이터를 만들지 않은 상태
• noResults: 검색어에 맞는 결과가 없는 상태
• filteredOut: 필터 조건 때문에 결과가 사라진 상태
• permissionDenied: 데이터는 있지만 사용자가 볼 권한이 없는 상태
• loadFailed: 데이터를 가져오지 못해 비어 보이는 상태
• readOnlyEmpty: 사용자가 채울 수 없는 읽기 전용 빈 상태

이 구분이 있어야 문구, CTA, 권한 요청, 필터 초기화, 재시도 버튼을 각각 다르게 설계할 수 있다. 같은 빈 화면이라도 사용자가 할 수 있는 일이 다르면 컴포넌트가 받는 상태 이름도 달라야 한다.

테스트해야 할 흐름

• 첫 사용 상태: 시작 CTA나 샘플 데이터가 노출되는가
• 검색 결과 없음: 검색어 수정, 필터 초기화, 추천 조건이 제공되는가
• 권한 없음: 권한 요청이나 관리자 문의 경로가 있는가
• 로딩 이후 빈 상태: 로딩 완료와 결과 없음이 구분되는가
• 접근성 경로: 빈 상태의 원인과 다음 행동이 스크린 리더로 전달되는가

추가로 비교할 상태

• 문서 도구, 이슈 관리 도구, 협업 도구의 첫 사용 Empty State를 비교한다
• 검색 결과 없음과 권한 없음 상태가 다르게 설계된 서비스 사례를 찾는다
• 샘플 데이터와 CTA가 있는 빈 대시보드 사례를 모은다

상태 설계 질문

• 처음 사용, 결과 없음, 권한 없음, 오류 상태를 명확히 구분했는가
• CTA가 없는 Empty State가 괜찮은 경우도 설명했는가

FAQ

언제 쓰면 좋을까?

사용자가 빈 화면의 원인을 오해할 수 있거나 다음 행동을 선택해야 할 때 필요하다. 첫 사용, 결과 없음, 권한 없음, 필터 결과 없음은 반드시 구분하는 편이 좋다.

언제 피해야 할까?

이미 주변 맥락만으로 비어 있는 이유가 명확하고 사용자가 할 행동도 없을 때는 과한 일러스트나 CTA를 피한다. 빈 상태가 화면의 주인공이 되면 실제 작업 흐름을 방해할 수 있다.

구현할 때 먼저 볼 것은?

firstUse, noResults, filteredOut, permissionDenied, loadFailed를 isEmpty 하나로 묶지 않는 일이다. 상태가 나뉘면 문구, CTA, 권한 요청, 재시도 테스트도 나뉜다.

출처

• Nielsen Norman Group, 10 Usability Heuristics for User Interface Design: https://www.nngroup.com/articles/ten-usability-heuristics/
• W3C, Web Content Accessibility Guidelines WCAG 2.2: https://www.w3.org/TR/WCAG22/
• WAI-ARIA APG, Alert Pattern: https://www.w3.org/WAI/ARIA/apg/patterns/alert/