화면의 빈 상태·오류·과부하를 빠짐없이 세는 프롬프트

처음 비어 있는 것과 사용자가 비운 것을 다르게 봅니다.

분류	디자인 › 화면·제품 설계
태그	체크리스트분석검토

프롬프트 (영어 본문 · 답은 한국어로 옵니다)

List the states this screen needs. ***Beyond the one it was designed in.***

**Premise: screens get designed with realistic data and then meet reality.**

**Go through:**
1. **Empty** — ***first-time empty and emptied-by-the-user are different.* **The first needs an explanation; the second needs reassurance**
2. **Loading** — ***and how long before it needs to say something***
3. **Partial** — some data arrived, some did not
4. **Error** — ***per thing that can fail, and what the user can actually do about each***
5. **Too much** — ***the list with 400 items, the name with 60 characters, the number with 9 digits.* **Say what breaks first**
6. **Too little** — one item, no name, a missing image
7. **Permission** — ***visible but not allowed, versus not visible at all.* **These look the same to the designer and completely different to the user**
8. **Stale** — the data was right when it loaded

**Per state:** what the user sees / **what they can do** / ***whether this state is a dead end***

**Then:**
- ***Which state will actually happen most often.* **It is rarely the one that got designed**
- **Which ones I can skip**, and why — *not every state needs a design*
- ***What the content needs to say*** in each — **not "show an error message", the actual sentence**

⚠️ ***You cannot see the screen. Work only from what I described*** — **do not assume a layout, a component, or a platform convention I did not state.** Where my description is not enough, **say what you would need to see.**

붙여 넣으면 맨 아래에 채울 칸(화면 · 보여주는 데이터)이 나옵니다

어떤 프롬프트인가

화면은 그럴듯한 데이터로 만들어지고 현실에서 깨진다. 특히 빈 상태는 하나가 아니다 — 처음이라 비어 있는 것은 설명이 필요하고, 사용자가 다 지워서 비어 있는 것은 안심이 필요하다. 이 프롬프트는 여덟 가지 상태를 세고, 각 상태에 실제로 들어갈 문장까지 요구한다.

모델 비교

ChatGPT가 가장 충실하고 신중하다. Gemini는 구체적이나 금지된 가정이 많고, [C]는 답이 제공되지 않았다.

ChatGPT종합 1위

40/ 50

＋ 요구된 8개 상태와 문구·행동을 충실히 다뤘다.

－ 지나치게 길고 일부 시간 기준은 근거가 약하다.

Gemini

34/ 50

＋ 실패 원인별 행동과 실제 문구가 선명하다.

－ 보관 기간·통계·레이아웃 등 미제공 사실을 단정했다.

기준	ChatGPT	Gemini	앞선 모델
지시 준수	9	7	ChatGPT +29%
정확성	8	5	ChatGPT +60%
구체성	9	8	ChatGPT +13%
구성·가독성	8	8	동점
분량 적정성	6	6	동점

gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-25). 측정값이 아니라 AI 심사 결과입니다.

답 전문 보기

같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.

넣은 입력

화면: 마이페이지 > 주문 내역 리스트 화면

보여주는 데이터: 최근 6개월치 주문 카드 목록 (주문일자, 상품 썸네일, 상품명, 배송상태 뱃지, 결제금액, 리뷰쓰기 버튼)

gpt-5.6-luna (codex CLI · 에이전트 하네스) · 실행일 2026-09-24

화면 설명만 기준으로 보면, 핵심은 “주문 카드 목록” 자체와 카드 안의 각 데이터가 서로 다른 상태를 가질 수 있다는 점입니다. 특히 배송상태·결제금액·리뷰쓰기 가능 여부는 상품 썸네일이나 상품명과 별개로 실패하거나 늦게 도착할 수 있습니다.

1. Empty

처음부터 주문이 없는 경우

보이는 것: 주문 카드 대신 최근 6개월 내 주문이 없다는 안내
할 수 있는 것: 주문 내역 화면을 나가거나, 제공된다면 상품 보러 가기
막다른 길인가: 상품 보러 가기 같은 연결이 있으면 아님. 없으면 사실상 막다른 길
문구:
“최근 6개월 내 주문 내역이 없습니다.”
상품 탐색 연결이 있다면: “상품을 둘러보고 주문해 보세요.”

사용자가 주문 내역을 비운 경우

주문 내역을 사용자가 삭제·숨김 처리할 수 있다는 기능이 설명에 없으므로, 현재 화면에는 해당 상태가 존재한다고 단정할 수 없습니다.

그 기능이 있다면:

보이는 것: 일반적인 “주문 없음”과 구분되는 안심 안내
할 수 있는 것: 주문 내역 복원, 삭제 전 상태 확인
막다른 길인가: 복원 기능이 있으면 아님
문구:
“주문 내역을 모두 숨겼습니다.”
“주문 정보는 삭제되지 않았으며, 언제든 다시 볼 수 있습니다.”

주문 자체가 취소되거나 환불된 것은 “empty”가 아니라 주문 카드가 남아 있는 상태에서 배송·주문 상태가 바뀌는 문제입니다.

2. Loading

보이는 것: 주문 카드 영역이 아직 준비되지 않았다는 상태. 실제 카드 내용을 임의로 보여주면 안 됨
할 수 있는 것: 잠시 기다리기. 충분히 오래 걸리면 재시도
막다른 길인가: 짧은 시간 동안은 아님. 오래 지속되면 오류 상태로 전환되어야 함
문구:

초기 로딩:

“주문 내역을 불러오는 중입니다.”

약 2~3초 이상 지연될 때:

“주문 내역을 불러오는 데 시간이 걸리고 있습니다.”

약 8~10초 이상 또는 요청 실패 시:

“주문 내역을 불러오지 못했습니다. 다시 시도해 주세요.”

시간 기준은 실제 API 응답 시간에 맞춰 조정해야 하지만, 사용자가 빈 화면을 보고 기다리는 시간을 2~3초 이상 방치하지 않는 것이 좋습니다.

3. Partial

부분 상태는 여러 형태로 발생할 수 있습니다.

일부 주문 카드만 도착한 경우

보이는 것: 도착한 주문 카드와 함께 아직 더 불러오는 중이라는 안내
할 수 있는 것: 도착한 주문은 확인 가능. 자동으로 이어서 불러오거나 재시도 가능
막다른 길인가: 아님
문구:
“주문 내역을 더 불러오는 중입니다.”

카드 안에서 일부 필드만 도착한 경우

예를 들어 상품명과 썸네일은 있지만 배송상태나 결제금액이 없는 경우입니다.

보이는 것: 도착한 값은 표시하고, 없는 값은 카드 전체를 숨기지 않고 해당 영역만 로딩 또는 미완성 상태로 표시
할 수 있는 것: 상품 정보 확인. 배송상태·결제금액이 필요한 작업은 값이 준비될 때까지 기다리거나 재시도
막다른 길인가: 필드에 따라 다름
문구:
- 배송상태: “배송 상태를 불러오는 중입니다.”
- 결제금액: “결제 금액을 불러오는 중입니다.”
- 리뷰 버튼 판단 불가: “리뷰 작성 가능 여부를 확인하는 중입니다.”

데이터가 영구적으로 없는 것인지 아직 도착하지 않은 것인지 구분해야 합니다. -, 0, 빈 문자열을 무조건 보여주면 사용자는 실제 값이 없다고 오해합니다.

4. Error

오류는 목록 전체가 아니라 실패한 대상별로 다뤄야 합니다.

주문 목록 전체를 불러오지 못한 경우

보이는 것: 카드 대신 목록 오류 안내
할 수 있는 것: 다시 시도
막다른 길인가: 재시도 버튼이 있으면 아님
문구:
“주문 내역을 불러오지 못했습니다. 네트워크 상태를 확인한 후 다시 시도해 주세요.”
버튼: “다시 시도”

일부 주문만 불러오지 못한 경우

보이는 것: 정상 카드와 실패한 구간이 함께 보임
할 수 있는 것: 실패한 부분만 다시 불러오기
막다른 길인가: 아님
문구:
“일부 주문 내역을 불러오지 못했습니다.”
버튼: “다시 불러오기”

상품 썸네일을 불러오지 못한 경우

보이는 것: 이미지 영역의 대체 이미지 또는 이미지 없음 상태
할 수 있는 것: 상품명과 주문 정보는 계속 확인 가능
막다른 길인가: 아님
문구:
“상품 이미지를 불러오지 못했습니다.”

오류 문구를 카드 전체에 띄울 필요는 없습니다. 이미지 실패가 주문 정보 확인을 막지는 않기 때문입니다.

상품명이 실패한 경우

보이는 것: 상품명 영역의 오류 표시
할 수 있는 것: 주문일자·금액·배송상태 확인. 상품 상세 이동이 가능하다면 상품명 오류로 이동하지 못할 수 있음
막다른 길인가: 상품명만 필요한 경우에는 부분적인 막힘
문구:
“상품명을 불러오지 못했습니다.”

배송상태를 불러오지 못한 경우

보이는 것: 배송상태 뱃지 대신 상태 확인 불가
할 수 있는 것: 배송상태 재시도. 배송조회 기능이 있다면 그 기능은 별도로 확인
막다른 길인가: 배송 진행을 알아야 하는 사용자에게는 사실상 막힘
문구:
“배송 상태를 확인할 수 없습니다. 잠시 후 다시 시도해 주세요.”

결제금액을 불러오지 못한 경우

보이는 것: 금액 대신 확인 불가 상태
할 수 있는 것: 금액 재시도. 금액이 확인되지 않으면 결제·환불 관련 판단은 보류
막다른 길인가: 부분적으로 아님. 다만 금액 확인이 목적이면 막힘
문구:
“결제 금액을 확인할 수 없습니다. 잠시 후 다시 시도해 주세요.”

리뷰 쓰기 요청이 실패한 경우

보이는 것: 버튼을 눌렀지만 리뷰 화면으로 이동하지 않음
할 수 있는 것: 다시 시도
막다른 길인가: 재시도가 있으면 아님
문구:
“리뷰 작성 화면을 열지 못했습니다. 잠시 후 다시 시도해 주세요.”

리뷰 작성이 불가능한 주문이라면 오류와 구분해야 합니다.

이미 작성함: “리뷰를 작성했습니다.”
작성 기간 만료: “리뷰 작성 기간이 종료되었습니다.”
아직 작성할 수 없음: “배송 완료 후 리뷰를 작성할 수 있습니다.”

이 세 가지가 실제 정책인지 확인이 필요합니다.

5. Too much

주문 카드가 400개인 경우

먼저 깨지는 것: 목록 탐색성과 성능. 사용자는 원하는 주문을 찾기 어렵고, 한 번에 모두 렌더링하면 스크롤·메모리 문제가 생길 수 있음
보이는 것: 최근 주문부터 일부만 표시하고 추가 로딩
할 수 있는 것: 더 보기, 페이지 이동, 기간 좁히기 등. 다만 기간 필터가 있다는 전제는 아직 없음
막다른 길인가: 탐색 방법이 없으면 사실상 막힘
문구:
“최근 주문부터 표시하고 있습니다. 더 많은 주문을 보려면 아래로 내려 주세요.”

현재 설명에는 검색·필터·페이지네이션이 없으므로, 400개를 실제로 처리할 탐색 방식은 별도로 설계해야 합니다. “최근 6개월”이라는 범위가 이미 제한되어 있으므로, 데이터가 400개까지 발생 가능한지도 확인해야 합니다.

상품명이 60자인 경우

먼저 깨지는 것: 카드 높이와 카드 간 수직 리듬, 이어서 배송상태·금액·버튼의 정렬
보이는 것: 1~2줄까지만 표시하고 말줄임
할 수 있는 것: 전체 상품명 확인. 카드 탭이나 상세 화면으로 이동하는 기능이 있다면 확인 가능
막다른 길인가: 전체 이름을 확인할 방법이 없으면 아님이 아니라 정보 손실
문구 예시:
“프리미엄 무선 노이즈 캔슬링 헤드폰 블랙…”

말줄임 기준과 전체명 확인 방법은 화면을 봐야 정할 수 있습니다.

결제금액이 9자리인 경우

먼저 깨지는 것: 금액 영역의 너비, 통화 단위와 버튼의 겹침
보이는 것: 금액이 줄바꿈되거나 잘리지 않도록 한 줄 처리
할 수 있는 것: 전체 금액 확인
막다른 길인가: 잘리면 금액을 정확히 알 수 없으므로 아님
문구: 별도 문구보다는 형식 자체가 필요합니다. 예: “123,456,789원”

금액 영역이 고정 폭인지, 카드가 가로형인지 세로형인지 알 수 없으므로 정확한 표시 방식은 화면 확인이 필요합니다.

6. Too little

주문이 한 건뿐인 경우

보이는 것: 카드 한 장만 표시되며, 카드가 비어 보이지 않아야 함
할 수 있는 것: 해당 주문의 정보 확인, 리뷰 작성 또는 상태 확인
막다른 길인가: 아님
문구: 별도 empty 문구는 필요 없음

상품명이 없는 경우

보이는 것: 빈칸 대신 이름 없음 상태
할 수 있는 것: 주문일자·금액·배송상태 확인. 대체 식별자가 있다면 그것으로 주문 확인
막다른 길인가: 상품을 식별할 다른 정보가 없으면 부분적으로 막힘
문구:
“상품명이 없습니다.”

상품 이미지가 없는 경우

보이는 것: 이미지 없음용 대체 영역
할 수 있는 것: 나머지 주문 정보 확인
막다른 길인가: 아님
문구:
“상품 이미지가 없습니다.”

배송상태 또는 결제금액이 실제로 없는 경우

보이는 것: 오류처럼 보이지 않는 “정보 없음” 상태
할 수 있는 것: 제공된 정보 확인
막다른 길인가: 해당 값이 없어도 주문 확인이 가능하면 아님
문구:
- “배송 상태 정보가 없습니다.”
- “결제 금액 정보가 없습니다.”

“불러오지 못했습니다”와 “원래 정보가 없습니다”는 반드시 구분해야 합니다.

7. Permission

정보는 존재하지만 사용자가 볼 권한이 없는 경우

예를 들어 결제금액이나 주문 상세가 특정 권한 뒤에 있는 경우입니다.

보이는 것: 해당 값이 존재하지만 잠긴 상태 또는 접근 제한 안내
할 수 있는 것: 권한 요청, 로그인, 본인 인증 등 실제 가능한 조치
막다른 길인가: 조치를 제공하면 아님
문구:
- 로그인 필요: “주문 내역을 보려면 로그인해 주세요.”
- 본인 인증 필요: “본인 인증 후 결제 금액을 확인할 수 있습니다.”
- 권한 없음: “이 주문 내역을 볼 권한이 없습니다.”

정보 자체를 사용자에게 노출하지 않는 경우

예를 들어 다른 사람의 주문이 목록에서 아예 제외되는 경우입니다.

보이는 것: 사용자는 해당 주문이 있었다는 사실조차 알 수 없음
할 수 있는 것: 없음
막다른 길인가: 사용자 입장에서는 판단할 수 없는 상태
문구: 사용자에게 보여줄 문구가 없어야 합니다.

디자이너 관점에서는 둘 다 “목록에 안 보임”처럼 보이지만, 사용자 관점에서는 “권한이 없어서 못 보는 것”과 “애초에 존재하지 않는 것”이 다릅니다. 어떤 데이터가 권한 제한 대상인지 정책 확인이 필요합니다.

8. Stale

보이는 것: 예전에 불러온 주문일자·상품명·배송상태·금액·리뷰 가능 상태
할 수 있는 것: 새로고침, 최신 정보 다시 확인
막다른 길인가: 새로고침이 있으면 아님
문구:

새로고침 전:

“주문 내역이 최신 정보가 아닐 수 있습니다.”

갱신 중:

“최신 주문 내역을 확인하는 중입니다.”

갱신 실패:

“최신 정보를 불러오지 못했습니다. 현재 표시된 정보는 이전에 불러온 내용입니다.”

특히 배송상태와 리뷰쓰기 버튼은 오래된 상태가 사용자 행동을 잘못 유도할 수 있습니다. 리뷰 버튼이 실제로는 만료됐거나 배송상태가 변경됐을 수 있으므로, 버튼을 누른 시점에도 최신 상태를 재검증해야 합니다.

실제로 가장 자주 발생할 상태

이 화면에서 현실적으로 가장 자주 생길 가능성이 높은 것은 완전한 오류보다 다음 조합입니다.

데이터가 늦게 도착하는 로딩
배송상태나 리뷰 가능 여부만 늦거나 바뀌는 부분 상태
이전에 로드한 배송상태와 현재 서버 상태가 다른 stale 상태
상품 이미지 누락 또는 이미지 로드 실패
배송 전이라 리뷰를 쓸 수 없는 정상적인 비활성 상태

즉, “모든 값이 정상적으로 채워진 카드”와 “목록 전체 오류” 사이의 상태를 우선 설계해야 합니다.

설계를 생략해도 되는 상태

다음은 발생 조건이 실제로 없다면 별도 화면 디자인을 생략할 수 있습니다.

사용자가 주문 내역을 직접 비우는 empty: 삭제·숨김 기능이 없다면 발생하지 않음
권한 제한 상태: 모든 주문 내역이 로그인한 본인에게 항상 제공된다면 생략 가능
400개 초과 상태: 최근 6개월 데이터가 시스템상 충분히 제한된다면 별도 대량 목록 설계는 불필요
9자리 금액: 서비스의 최대 결제금액이 그보다 낮다는 정책이 보장된다면 생략 가능

다만 별도 화면을 만들지 않는 것과 상태를 무시하는 것은 다릅니다. 예를 들어 이미지 실패는 별도 페이지가 필요 없지만, 이미지 없음 대체 표현은 필요합니다.

반대로 다음은 생략하면 안 됩니다.

최초 주문 없음
로딩 지연
목록 전체 오류와 일부 오류
상품 이미지 없음 또는 실패
배송상태를 확인할 수 없음
리뷰 작성 불가와 리뷰 요청 실패의 구분
긴 상품명
오래된 배송상태

추가로 확인해야 하는 것

현재 설명만으로는 다음을 알 수 없어 정확한 상태 설계를 확정할 수 없습니다.

카드 탭 시 주문 상세 화면으로 이동하는지
상품명·이미지를 눌렀을 때 상품 상세로 이동하는지
주문 내역 삭제·숨김 기능이 있는지
로그인·본인 인증이 필요한 화면인지
배송상태와 결제금액이 어떤 API에서 오는지
리뷰 작성 가능 조건과 만료 정책
목록이 페이지네이션인지, 무한 스크롤인지
새로고침 방식과 데이터 갱신 주기
상품명이 카드 안에서 몇 줄까지 허용되는지
이미지가 없을 때 사용할 기본 이미지가 있는지
주문 취소·환불·부분 배송을 어떤 배송상태로 표현하는지

이 정보를 확인하면 각 상태를 별도 디자인할지, 카드 내부의 국소 상태로 처리할지까지 결정할 수 있습니다.

같은 분류의 프롬프트

7대7 축구 팀 앱 설계 프롬프트
접근성 감사자 역할을 맡기는 프롬프트
접근성 감사자 역할 프롬프트
접근성 전문가 역할 프롬프트
접근성 테스트 워크플로 프롬프트

많이 찾는 것

분류