화면이 예뻐도 개발에서 막히는 이유는 무엇인가요?
정의서 리뷰 회의에서 가장 많이 나오는 질문은 디자인의 완성도가 아니라 "이 경우엔 뭘 보여줘야 하나요?"입니다. 데이터가 하나도 없을 때, 서버 응답이 3초 넘게 지연될 때, 글자 수가 화면 폭을 넘어갈 때 — 이런 경우의 수가 정의서에 빠져 있으면 아무리 시안이 정교해도 개발은 멈춥니다.
디자이너는 '정상적으로 데이터가 잘 채워진 화면' 한 장을 기준으로 작업하는 경우가 많지만, 개발자는 그 화면이 놓일 수 있는 모든 상태를 코드로 분기 처리해야 합니다. 이 간극이 리뷰 단계에서 질문이 몰리는 근본 원인입니다.
화면정의서에 반드시 포함해야 하는 4가지 상태는 무엇인가요?
화면 하나당 최소 아래 4가지 상태를 별도로 정의해야, 디자이너·개발자·QA가 같은 화면을 상상할 수 있습니다.
- Empty — 데이터가 하나도 없을 때 보여줄 문구, 버튼, 일러스트를 정의합니다.
- Loading — 로딩 표시 방식(스켈레톤/스피너 등)과, 몇 초 이상 지연되면 타임아웃으로 처리할지 기준을 정의합니다.
- Error — 서버 오류·네트워크 오류 시 노출할 메시지와 재시도 동선을 정의합니다.
- Success — 정상적으로 데이터가 채워졌을 때의 기본 화면이며, 대부분의 시안이 이 상태만 그려져 있습니다.
상태 전환 조건까지 적어야 하는 이유는 무엇인가요?
단순히 4가지 화면을 각각 그리는 것만으로는 부족합니다. "무엇이 발생했을 때 Loading에서 Error로 바뀌는지", "Error 화면에서 재시도를 누르면 다시 Loading으로 가는지 Empty로 가는지"처럼 상태 사이의 전환 조건까지 문서에 명시해야 개발자가 별도로 되묻지 않습니다.
디자이너·개발자·QA는 같은 정의서를 어떻게 다르게 읽나요?
같은 문서를 보고도 직군마다 확인하는 지점이 다르기 때문에, 한 명의 시각으로만 정의서를 검수하면 다른 직군이 필요로 하는 정보가 비기 쉽습니다.
- 디자이너는 상태별 화면이 시각적으로 자연스러운지, 레이아웃이 깨지지 않는지를 중심으로 봅니다.
- 개발자는 상태 전환 조건과 API 응답 값에 따라 분기 로직을 어떻게 짜야 하는지를 중심으로 봅니다.
- QA는 문서에 적힌 예외 케이스를 실제로 재현할 수 있는지, 빠진 케이스는 없는지를 중심으로 봅니다.
정상 케이스 80%보다 예외 케이스 20%를 먼저 정의해야, 개발 단계에서 되돌아오는 질문이 줄어듭니다.
예쁜 시안이 있으면 화면정의서는 생략해도 되나요?
시안은 정상적으로 보이는 한 순간만 보여주지만, 정의서는 그 화면이 놓일 수 있는 모든 상황을 보여줘야 합니다. 디자인 완성도와 별개로 상태값과 예외 흐름이 빠진 정의서는 개발 단계에서 반드시 재질문을 유발합니다. 슈퍼플래닝은 UX기획 단계에서 상태값 정의를 시안 작업보다 먼저 확정하는 방식으로 진행합니다.