Synthetic screen-states matrix: seven cases for one orders list, each with a response, a screen and a test

A made-up screen and a table that defines done

This is a synthetic specification for an invented orders list, not a customer case and not a delivered job. It shows the artefact that makes a screen-states job checkable: a table with one row per case, the simulated response that produces it, what the screen shows, which controls remain and the name of the test that proves it. A reviewer can read the table and say what is missing; a developer can write one test per row. The wording of each message is an agreed decision for the product owner, not something the code can infer.

• Seven cases are the default set; add or remove rows by agreement.
• Every row has a test, so a later change that blanks the screen fails a named test.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

case                    | simulated response (synthetic)          | the screen shows                                  | controls          | test name
loading                 | no response yet                         | skeleton rows and "Loading orders"                | none              | shows-loading
success                 | 200, 3 orders                           | the 3 orders                                      | open, filter      | shows-orders
empty                   | 200, 0 orders                           | "No orders yet" and how to create the first one   | create order      | shows-empty
request failed          | network error                           | "Could not load your orders" and the reason       | try again         | shows-failed
timeout                 | no reply within 10 seconds              | "This is taking too long" and a retry             | try again         | shows-timeout
server error            | 500                                     | "Something went wrong on our side"                | try again         | shows-server-error
missing field           | 200, an order with no "status" field    | the order, with status shown as "Unknown"         | open              | shows-partial

The simulated responses

The responses are invented fixtures, so the cases can be reproduced without real customer data or a failing service. The missing-field case matters because it is the common cause of a white page: reading a field that is not there throws during rendering. The expected behaviour is to show the order with an unknown status and keep the rest of the page, not to throw. A rendering failure that still escapes is the job of one boundary around the screen, with a retry; the other cases are handled where the request is made.

• Use a fixture server or a mocked request layer; never the live service.
• Include one forced rendering failure to prove the boundary works and that retry recovers.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

// synthetic fixtures for the seven cases
success:        [{ id: 1, status: "paid" }, { id: 2, status: "sent" }, { id: 3, status: "paid" }]
empty:          []
missing field:  [{ id: 4 }]            // no status
server error:   HTTP 500, body {"error":"internal"}
timeout:        no response for 10 seconds
failed:         connection reset before any response

What each message must do

Each non-success state should say in plain words what happened and what the user can do next, without raw error text, codes or internal names. A retry control should repeat only a safe read. A message that appears without a page change should be exposed so assistive technology announces it without moving focus. The empty state is guidance, not an error: it should tell a new user how to get their first item.

• Failed, timeout and server error may share a layout but need different wording.
• Do not offer retry for a write that may have partly succeeded.
• Check each state at desktop and phone widths.

Limits of this example

The matrix does not describe any real application, does not prove any framework behaves a particular way beyond what the cited documentation says, and does not mean a client screen has been repaired. The matching paid job is our screen-states job (posted test price £245, untested), for one screen or a list and its detail pair in an existing React or Next.js app. Send the screen and what users see when it fails in your first enquiry, not customer data or credentials.