Skip to content
Components
/
Empty State
Dark

Empty State

Two screens for the states most systems leave the designer to invent. Error and empty, drawn light and dark, from the same components as every other screen.

Preview

Two screens for the moments a product usually leaves blank. One thing went wrong, one thing has not happened yet, and both are built from the same components as every other screen in the system.

Empty State, two screens, light and dark
393 x 852 each, Platform ios-md
Empty state app, error screen, lightEmpty state app, error screen, dark
Error
Empty state app, add money screen, lightEmpty state app, add money screen, dark
Add money

The set is drawn twice in Figma, a light row and a dark row, with Color Tokens set explicitly on every frame rather than inherited from the page. The dark screens are not a second drawing. They are the same instances resolved against the other mode.

What it is built from

Nine instances across two screens. This is the smallest set in the library, and the small number is the argument: an empty state does not need new parts, it needs the same parts arranged with restraint.

Component
Placed
Nested
Where
4
0
Both screens, one primary and one quiet
2
0
Both screens
1
1
Error only, carrying the x glyph
1
0
Add Money, sitting in a hand drawn badge

Add Money reports no nested instances at all, and that single anomaly is the tell. On Error the glyph is nested because it sits inside the _Alert Status component. On Add Money it sits at the top level because the badge around it was drawn by hand. The states section explains why, and what to do about it.

States that ship

Empty and error are the states most systems leave the designer to invent at the end of a project, under time pressure, one screen at a time. Here the badge that marks them is a component with four types.

Type
Glyph
Use it for
Error
x
A request failed and the user can retry
Warning
exclamation
Something needs attention before it fails
Success
check
A task finished and the screen has nothing left to show
Verified
check
An identity or account is confirmed

Four types, one axis, 64 x 64 in the component and scaled to 80 on these screens. Pick the type from what the user is meant to feel, not from the colour you want.

Now the part that is drawn locally, because a docs page that hides it is worth nothing. On Add Money the badge is not an instance. It is a frame holding two ellipses at 70 and 60 with a wallet-minimal icon at 35, a hand made copy of the component sitting one screen away from the real thing. It happened for a reason worth fixing rather than scolding: the Type axis fixes the glyph per type, so there is no way to keep the badge and change the icon to a wallet. The fold back is specific. Give _Alert Status an instance swap property for its glyph, and this rebuild disappears along with every future one. Four rectangles named Divider, 345 x 179, also sit at the top and bottom of both screens doing the centring; they carry a real fill bound to bg/white-0 rather than being empty spacers, so they are load bearing and should stay, but the name is wrong and should not survive the next pass.

Tokens

Six collections behind the two screens. Switching one mode is the entire dark mode step.

Collection
Modes
What it drives here
Color Tokens
Light, Dark
Page surface, badge ring, badge fill, both Buttons
Foundations
Default
The 345 content width and the block spacing
Typography
Default
Headline and supporting line
Platform
ios-md, ios-lg, android
Status bar and platform metrics, set to ios-md
Platform Bridge
Brand, System
Available, not exercised by this set
Motion
Default
Available, not exercised by a still export

The badge fill on Add Money resolves through state/information/lighter-50, which lands on a pale blue in Light and a saturated blue in Dark. Even the hand drawn badge is fully bound, so the local copy survives the mode switch. It is a component problem, not a token problem, and the two are worth telling apart when you audit your own file.