피그마 빈 화면·오류 화면 검토법: 개발 전에 꼭 확인해야 할 예외 케이스

기획 리뷰 단계에서 빈 화면과 오류 화면을 놓치면 개발 후반부에 리소스가 배로 듭니다.
화면 설계 시 반드시 짚어야 할 예외 케이스와 실전 검토 순서를 정리했습니다.

📌 목차

1. 리뷰 때는 안 보이고 개발 때 터지는 화면들
2. 핵심 개념 — UI 상태(State) 설계란 무엇인가
3. 실제 사례로 보는 누락 패턴
4. 적용 방법 — 리뷰 시 확인 순서
5. 실무 팁 3가지
6. 마무리 — 핵심 요약과 다음 행동
7. FAQ

1. 리뷰 때는 안 보이고 개발 때 터지는 화면들

기획 리뷰를 마치고 다 같이 화면을 검토했다고 생각한 순간, 개발자가 와서 "이 기능은 화면에 없는데 필요한 것 아닌가요?"라고 물어볼 때가 있습니다. 분명 여러 명이 함께 봤던 화면인데도 놓친 부분이 있었다는 걸 그제야 깨닫습니다.

특히 빈 화면이나 오류 화면처럼 평소 눈에 잘 띄지 않는 예외 케이스에서 이런 일이 자주 벌어집니다.

2. 핵심 개념 — UI 상태(State) 설계란 무엇인가

화면은 항상 "정상적으로 데이터가 채워진 상태"만 존재하는 게 아닙니다. 데이터가 아예 없는 상태(Empty), 요청 중인 상태(Loading), 요청이 실패한 상태(Error), 일부 데이터만 도착한 상태(Partial)가 함께 존재합니다.

기획 단계에서 정상 케이스만 그려두고 나머지 상태는 개발자 재량에 맡기면, 서비스 전체의 톤앤매너가 화면마다 달라지고 사용자 경험도 일관성을 잃게 됩니다.

3. 실제 사례로 보는 누락 패턴

검색 결과 리스트 화면을 기획하면서 정상적으로 결과가 나오는 화면만 그려두고 넘어간 적이 있습니다. QA 단계에서 "검색 결과가 없을 때 화면이 텅 비어 보인다"는 피드백을 받고서야 빈 화면 디자인이 빠졌다는 걸 알았습니다.

결제 실패, 네트워크 오류, 권한 없음처럼 자주 발생하지 않는 상황일수록 설계에서 빠지기 쉽습니다. 발생 빈도가 낮다는 이유로 뒤로 미루다가, 정작 사용자가 그 화면을 마주쳤을 때 아무 안내도 받지 못하는 경우가 생깁니다.

이런 화면은 개발자가 임시로 텍스트만 띄워두는 식으로 처리하고 넘어가는 경우가 많은데, 이후 디자인 수정 요청이 다시 들어오면서 일정이 두 번 소모됩니다.

4. 적용 방법 — 리뷰 시 확인 순서

상태 누락을 줄이려면 리뷰 순서 자체를 바꿔야 합니다. 아래 순서로 확인하면 빠뜨리는 화면을 줄일 수 있습니다.

1. 화면 목록을 뽑을 때 정상 상태 외에 Empty, Loading, Error, Partial 상태를 항목으로 함께 나열합니다.
2. 와이어프레임 단계에서 상태별로 최소 한 개씩 화면을 그려봅니다.
3. 리뷰 자리에서 "이 화면에서 데이터가 없을 때는 어떻게 보이나요", "요청이 실패하면 어떤 안내가 나가나요"라는 질문을 팀원에게 직접 던집니다.
4. 개발 핸드오프 전, 상태별 화면을 한 페이지에 모아 개발자와 함께 다시 확인합니다.

5. 실무 팁 3가지

팁1. 컴포넌트 Variants로 상태 관리하기

피그마 Variants 기능으로 하나의 컴포넌트에 Default, Empty, Error, Loading 상태를 변형으로 만들어두면, 화면을 그릴 때마다 상태를 빠뜨리지 않고 선택할 수 있습니다. 라이브러리에 상태 Variant가 없으면 새 화면을 그릴 때마다 처음부터 다시 고민하게 되고, 그만큼 누락 위험도 커집니다.

팁2. 개발자 핸드오프 전 '상태 매트릭스' 공유하기

화면과 상태를 표로 정리한 상태 매트릭스를 만들어 핸드오프 전에 공유합니다. 행에는 화면명을, 열에는 Empty, Loading, Error, Partial을 두고 각 칸에 디자인 링크나 "해당 없음"을 표시합니다. 빈칸으로 남은 부분이 바로 놓친 케이스입니다.

팁3. 실데이터·API 응답 기준으로 케이스 나누기

디자인 초안을 그리기 전에 실제 API 응답 스펙(성공, 실패, 빈 배열 등)을 개발자와 먼저 맞춰봅니다. 실제 응답 구조를 기준으로 케이스를 나누면, 머릿속으로 상상한 예외가 아니라 실제로 발생하는 예외를 놓치지 않고 반영할 수 있습니다.

6. 마무리 — 핵심 요약과 다음 행동

1. 화면은 정상 상태만 있는 게 아니라 Empty, Loading, Error, Partial 상태가 함께 존재합니다.
2. 리뷰 단계에서 이 상태들을 빠뜨리면 개발 후반부에 다시 작업해야 하는 비용이 생깁니다.
3. Variants, 상태 매트릭스, 실데이터 기준 분류를 활용하면 누락을 줄일 수 있습니다.

여러분의 프로젝트에서는 어떤 예외 화면을 놓쳤던 경험이 있으신가요. 댓글로 상황을 남겨주시면 비슷한 케이스를 모아 다음 글에서 더 다뤄보겠습니다.

FAQ

Q1. 빈 화면과 오류 화면을 항상 따로 디자인해야 하나요?

서비스 성격에 따라 다르지만, 최소한 어떤 문구와 액션 버튼이 노출될지는 미리 정해두는 것이 좋습니다. 완전히 같은 톤으로 처리해도 되는 경우도 있지만, 사용자에게 다음 행동을 안내해야 하는 오류 상황과 단순히 데이터가 없는 빈 화면 상황은 메시지 톤이 달라야 합니다.

Q2. 상태별 검토는 언제 하는 게 적절한가요?

와이어프레임 단계에서 상태 목록을 먼저 정리하고, 하이파이 디자인 단계에서 화면으로 구체화하는 순서를 추천합니다. 핸드오프 직전에서야 검토하면 일정 압박 때문에 상태가 빠지기 쉽습니다.

Q3. 오류 메시지 문구는 기획자가 직접 써야 하나요?

최종 문구는 UX 라이터나 디자이너와 협의해도 되지만, 오류 상황과 사용자가 취해야 할 다음 행동을 먼저 정의하는 역할은 기획자 쪽에 있는 경우가 많습니다. 문구 자체보다 "어떤 상황에 어떤 안내가 필요한지"를 먼저 결정하는 것이 우선입니다.