+ Covers all eight states, actions, and copy.
- Overlong, with weakly supported timing thresholds.
Separates first-time empty from user-emptied, and asks for the actual sentence rather than "show an error".
| Category | Design › Product design |
|---|---|
| Tags | ChecklistAnalyzingReviewing |
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.**
Screens are designed with plausible data and meet reality later. Empty is not one state — first-time empty needs an explanation, user-emptied needs reassurance. This covers eight and demands real copy.
ChatGPT is the most complete and cautious. Gemini is concrete but makes unsupported assumptions; [C] was not provided.
+ Covers all eight states, actions, and copy.
- Overlong, with weakly supported timing thresholds.
+ Gives clear actions and copy for each failure.
- Invents retention, usage, layout, and platform facts.
| Criterion | ChatGPT | Gemini | Leader |
|---|---|---|---|
| Instruction following | 9 | 7 | ChatGPT +29% |
| Accuracy | 8 | 5 | ChatGPT +60% |
| Specificity | 9 | 8 | ChatGPT +13% |
| Structure | 8 | 8 | Tie |
| Right length | 6 | 6 | Tie |
Scored 1–10 by gpt-5.6-sol with model names hidden (2026-09-25). This is an AI review, not a measurement.
We gave three models the same input and copied their answers unedited. Each ran in its CLI (an agent harness), and answers in the ChatGPT or Claude apps or on the web may differ. Outputs are in Korean.
The screen: 마이페이지 > 주문 내역 리스트 화면 What it shows: 최근 6개월치 주문 카드 목록 (주문일자, 상품 썸네일, 상품명, 배송상태 뱃지, 결제금액, 리뷰쓰기 버튼)
화면 설명만 기준으로 보면, 핵심은 “주문 카드 목록” 자체와 카드 안의 각 데이터가 서로 다른 상태를 가질 수 있다는 점입니다. 특히 배송상태·결제금액·리뷰쓰기 가능 여부는 상품 썸네일이나 상품명과 별개로 실패하거나 늦게 도착할 수 있습니다.
주문 내역을 사용자가 삭제·숨김 처리할 수 있다는 기능이 설명에 없으므로, 현재 화면에는 해당 상태가 존재한다고 단정할 수 없습니다.
그 기능이 있다면:
주문 자체가 취소되거나 환불된 것은 “empty”가 아니라 주문 카드가 남아 있는 상태에서 배송·주문 상태가 바뀌는 문제입니다.
초기 로딩:
“주문 내역을 불러오는 중입니다.”
약 2~3초 이상 지연될 때:
“주문 내역을 불러오는 데 시간이 걸리고 있습니다.”
약 8~10초 이상 또는 요청 실패 시:
“주문 내역을 불러오지 못했습니다. 다시 시도해 주세요.”
시간 기준은 실제 API 응답 시간에 맞춰 조정해야 하지만, 사용자가 빈 화면을 보고 기다리는 시간을 2~3초 이상 방치하지 않는 것이 좋습니다.
부분 상태는 여러 형태로 발생할 수 있습니다.
예를 들어 상품명과 썸네일은 있지만 배송상태나 결제금액이 없는 경우입니다.
데이터가 영구적으로 없는 것인지 아직 도착하지 않은 것인지 구분해야 합니다. -, 0, 빈 문자열을 무조건 보여주면 사용자는 실제 값이 없다고 오해합니다.
오류는 목록 전체가 아니라 실패한 대상별로 다뤄야 합니다.
오류 문구를 카드 전체에 띄울 필요는 없습니다. 이미지 실패가 주문 정보 확인을 막지는 않기 때문입니다.
리뷰 작성이 불가능한 주문이라면 오류와 구분해야 합니다.
이 세 가지가 실제 정책인지 확인이 필요합니다.
현재 설명에는 검색·필터·페이지네이션이 없으므로, 400개를 실제로 처리할 탐색 방식은 별도로 설계해야 합니다. “최근 6개월”이라는 범위가 이미 제한되어 있으므로, 데이터가 400개까지 발생 가능한지도 확인해야 합니다.
말줄임 기준과 전체명 확인 방법은 화면을 봐야 정할 수 있습니다.
금액 영역이 고정 폭인지, 카드가 가로형인지 세로형인지 알 수 없으므로 정확한 표시 방식은 화면 확인이 필요합니다.
“불러오지 못했습니다”와 “원래 정보가 없습니다”는 반드시 구분해야 합니다.
예를 들어 결제금액이나 주문 상세가 특정 권한 뒤에 있는 경우입니다.
예를 들어 다른 사람의 주문이 목록에서 아예 제외되는 경우입니다.
디자이너 관점에서는 둘 다 “목록에 안 보임”처럼 보이지만, 사용자 관점에서는 “권한이 없어서 못 보는 것”과 “애초에 존재하지 않는 것”이 다릅니다. 어떤 데이터가 권한 제한 대상인지 정책 확인이 필요합니다.
새로고침 전:
“주문 내역이 최신 정보가 아닐 수 있습니다.”
갱신 중:
“최신 주문 내역을 확인하는 중입니다.”
갱신 실패:
“최신 정보를 불러오지 못했습니다. 현재 표시된 정보는 이전에 불러온 내용입니다.”
특히 배송상태와 리뷰쓰기 버튼은 오래된 상태가 사용자 행동을 잘못 유도할 수 있습니다. 리뷰 버튼이 실제로는 만료됐거나 배송상태가 변경됐을 수 있으므로, 버튼을 누른 시점에도 최신 상태를 재검증해야 합니다.
이 화면에서 현실적으로 가장 자주 생길 가능성이 높은 것은 완전한 오류보다 다음 조합입니다.
즉, “모든 값이 정상적으로 채워진 카드”와 “목록 전체 오류” 사이의 상태를 우선 설계해야 합니다.
다음은 발생 조건이 실제로 없다면 별도 화면 디자인을 생략할 수 있습니다.
다만 별도 화면을 만들지 않는 것과 상태를 무시하는 것은 다릅니다. 예를 들어 이미지 실패는 별도 페이지가 필요 없지만, 이미지 없음 대체 표현은 필요합니다.
반대로 다음은 생략하면 안 됩니다.
현재 설명만으로는 다음을 알 수 없어 정확한 상태 설계를 확정할 수 없습니다.
이 정보를 확인하면 각 상태를 별도 디자인할지, 카드 내부의 국소 상태로 처리할지까지 결정할 수 있습니다.
| 7v7 Football Team Generator App | |
| Accessibility Auditor | |
| Accessibility Auditor Agent Role | |
| Accessibility Expert | |
| Accessibility Testing Superpower |