데이터 테이블에 하나의 범용적인 빈 상태(Empty State)만 사용하지 마세요
대부분의 데이터 테이블은 "데이터가 없습니다"라는 단 하나의 메시지만 보여줍니다.
디자인 리뷰 단계에서는 괜찮아 보일지 모르지만, 실제 서비스(production) 환경에서는 고객 문의(support ticket)를 양산하게 됩니다.
빈 테이블은 세 가지 서로 다른 상황을 의미합니다. 각 상황에는 그에 맞는 구체적인 디자인, 텍스트, 그리고 액션이 필요합니다.
반드시 별도로 디자인해야 하는 세 가지 케이스는 다음과 같습니다.
1. 첫 사용 (데이터가 아직 존재하지 않음)
사용자가 처음 방문한 상태입니다. 사용자는 이 테이블이 무엇을 하는 곳인지, 어떻게 시작해야 하는지 알고 싶어 합니다. • 목표: 사용자의 온보딩(Onboarding) 유도. • 텍스트: 테이블의 목적을 설명합니다. • 액션: 첫 항목을 생성하거나 데이터를 가져올 수 있는 버튼을 제공합니다. • 피해야 할 것: "데이터가 없습니다"와 같이 더 이상 진행할 수 없는 막다른 길처럼 느껴지는 메시지.
2. 필터링된 빈 상태 (데이터는 있지만 필터로 인해 보이지 않음)
사용자가 적용한 필터의 결과가 0건인 경우입니다. 이 경우 사용자는 도구가 고장 났다고 생각하기 쉽습니다. • 목표: 사용자가 데이터를 찾을 수 있도록 돕습니다. • 텍스트: 어떤 필터가 활성화되어 있는지 명확하게 명시합니다. • 액션: 모든 필터를 해제하거나 수정할 수 있는 버튼을 제공합니다. • 피해야 할 것: 활성화된 필터를 무시하는 범용적인 메시지.
3. 로드 실패 (요청 실패)
서버에서 에러를 반환했거나 네트워크 연결이 끊긴 경우입니다. • 목표: 사용자가 문제를 복구할 수 있도록 돕습니다. • 텍스트: 로드에 실패했음을 설명하고 타임스탬프나 에러 코드를 보여줍니다. • 액션: 재시도(Retry) 버튼을 제공합니다. • 피해야 할 것: 실제로는 기술적인 오류인데 사용자에게 "데이터가 없습니다"라고 말하는 것.
팀들이 이를 놓치는 이유:
- 프로세스 너무 후반부에 빈 상태를 디자인합니다.
- 데모 데이터로만 테스트하기 때문에 빈 상태를 실제로 볼 일이 없습니다.
- 빈 상태를 예외적인 케이스(edge case)로 취급합니다.
사실, 빈 상태는 매우 영향력이 큰(high-leverage) 순간입니다. 잘 설계된 빈 상태는 사용자를 단 몇 분 만에 '0'의 상태에서 '가치'를 느끼는 상태로 이동시킵니다. 반면 잘못 설계된 상태는 사용자를 혼란스럽고 좌절하게 만듭니다.
테이블 컴포넌트를 구축할 때 이러한 조건들을 각각 별도로 처리할 수 있도록 만드세요. 지금 디자인하는 데는 비용이 거의 들지 않지만, 나중에 엄청난 양의 고객 지원 시간을 절약해 줄 것입니다.