피그마 빈 화면·오류 화면 검토법: 개발 전에 꼭 확인해야 할 예외 케이스
피그마 빈 화면·오류 화면 검토법: 개발 전에 꼭 확인해야 할 예외 케이스 피그마 빈 화면·오류 화면 검토법: 개발 전에 꼭 확인해야 할 예외 케이스 기획 리뷰 단계에서 빈 화면과 오류 화면을 놓치면 개발 후반부에 리소스가 배로 듭니다. 화면 설계 시 반드시 짚어야 할 예외 케이스와 실전 검토 순서를 정리했습니다. 📌 목차 리뷰 때는 안 보이고 개발 때 터지는 화면들 핵심 개념 — UI 상태(State) 설계란 무엇인가 실제 사례로 보는 누락 패턴 적용 방법 — 리뷰 시 확인 순서 실무 팁 3가지 마무리 — 핵심 요약과 다음 행동 FAQ 1. 리뷰 때는 안 보이고 개발 때 터지는 화면들 기획 리뷰를 마치고 다 같이 화면을 검토했다고 생각한 순간, 개발자가 와서 "이 기능은 화면에 없는데 필요한 것 아닌가요?"라고 물어볼 때가 있습니다. 분명 여러 명이 함께 봤던 화면인데도 놓친 부분이 있었다는 걸 그제야 깨닫습니다. 특히 빈 화면이나 오류 화면처럼 평소 눈에 잘 띄지 않는 예외 케이스에서 이런 일이 자주 벌어집니다. 2. 핵심 개념 — UI 상태(State) 설계란 무엇인가 화면은 항상 "정상적으로 데이터가 채워진 상태"만 존재하는 게 아닙니다. 데이터가 아예 없는 상태(Empty), 요청 중인 상태(Loading), 요청이 실패한 상태(Error), 일부 데이터만 도착한 상태(Partial)가 함께 존재합니다. 기획 단계에서 정상 케이스만 그려두고 나머지 상태는 개발자 재량에 맡기면, 서비스 전체의 톤앤매너가 화면마다 달라지고 사용자 경험도 일관성을 잃게 됩니다. 3. 실제 사례로 보는 누락 패턴 검색 결과 리스트 화면을 기획하면서 정상적으로 결과가 나오는 화면만 그려두고 넘어간 적이 있습니다. QA 단계에서 "검색 결과가 없을 때 화면이 텅 비어 보인다"는 피드백을 받고서...