AI / Design Communication & Image Prompting

From empty state to content

What should happen in the 400ms after the user taps New

Scenario: a list page is empty on first use. The user taps New, submits, and the first item is created. Design the transition from empty state to content: 1) The state sequence — empty, submitting, skeleton, partial appear, complete; 2) Duration and easing for each step, keeping the whole thing under 400ms; 3) How to prevent layout shift, including reserving height and keeping skeleton dimensions identical to real content; 4) Where focus and scroll position go; 5) Accessibility — what changes under prefers-reduced-motion, and whether aria-live is needed; 6) The three things this transition must confirm to the user. Give a timing table showing what the user sees at each step.

How to use

Do not prop up a slow endpoint with a skeleton; past one second, switch to a progress state or return to the list first.

Good for

On first use the list is empty and the user creates the first item — with no feedback at that moment, they assume it did not save and tap again.
The list page also has controls that depend on content, such as filters and bulk actions — the transition has to answer when those controls appear as well.

Not for

Content always arrives as a whole page from the server, an admin report for instance — there is no empty-to-content moment, and a transition only adds delay.
Every create navigates to a full detail page — that is a page transition, not a state transition within one screen.

Example

Input

A task app: the empty state is an illustration plus Create your first task; the user types a title and submits, and the first item has to appear; today the screen flashes white and the item just shows up

What you get

It lays out five steps: the illustration fades over 120ms; skeleton rows reuse the real 56px row height and card radius; after 120ms the first item fades in with an 8px upward move; the remaining rows stagger in at 40ms intervals; focus lands on the new item's title with scroll pinned to the top. The white flash happens because nothing holds the space during the wait, and a skeleton removes it. Under reduced motion the offset and stagger are dropped, leaving a 100ms opacity swap.

Common mistakes

Using a skeleton to cover a slow endpoint — the transition is 400ms; if the call takes two seconds the skeleton just sits there and the user gets more anxious.
Letting new content fly in from off-screen — beyond 24px of travel the user loses the spatial relationship of where it was added.

Try tweaking it like this

Try the reverse transition after deleting the last item — going from content to empty is easier to get wrong; an illustration that pops in reads like an error.
Add the failure branch: on a failed submit, keep what was typed and show the error in place — a transition design has to include the path where it does not work.