Implementation worksheet · 5 min read
An Empty-State Onboarding Checklist for New Workspaces
Every empty state in a new workspace must answer three questions in one glance: what belongs here, why it's worth creating, and the one action that creates it. The checklist: a primary CTA that starts the artifact (not a docs link), an import path beside it for users with existing data, sample content that's clearly labeled and one-click removable, and empty states for second-order surfaces (search, filters, reports) that inherit the same rules. 'No items yet' with a lonely plus button is a shrug, not a design.
New users see more empty states than features: empty board, empty inbox, empty report list. Each is either a dead end or the next step of onboarding — the checklist makes them the latter systematically instead of screen-by-screen accidentally.
Put it into practice
1. Inventory every empty surface
List each screen a day-zero workspace renders empty — including the ones behind tabs and filters. Teams find 2-3× more than they expect; each is a first impression someone gets.
2. Give each one artifact-creating CTA
The button creates the thing ('Create your first board'), never explains it ('Learn about boards'). Templates count as creation — a template picker is a legitimate primary CTA; a documentation link is surrender.
3. Offer the import path second
'Import from CSV/competitor' sits beside create, visually secondary. Users with existing data judge you entirely on this path — hiding it in settings costs your most valuable segment.
4. Label and cap sample data
If you seed examples: visibly marked ('Sample'), excluded from counts and billing, removable in one action, and auto-expiring after first real artifact. Unlabeled samples in real workspaces read as bugs.
5. Design the second-order empties
Empty search results, empty filters, zero-state reports: each inherits the pattern — say what would appear, offer the creating action. The report that renders a blank chart on day zero is the one screenshot that ends the trial.
Empty-state audit
Copy this structure into your review document and record your observed result for each row.
| Surface | Creating CTA | Import path | Sample rules | Pass |
|---|---|---|---|---|
| Main workspace | ||||
| Search results | ||||
| Reports/analytics | ||||
| Filtered views | ||||
| Mobile equivalents |
A failure worth checking
The demo-data trap: seeding rich sample content that makes every screen look alive — and every metric lie. Users explore the sample, activation dashboards glow, and nobody notices real-artifact creation is near zero because the empty states that would drive it never render. Sample data is scaffolding: labeled, capped, and torn down the moment real work begins.
Common questions
Sample data or blank-with-CTA — which converts better?
Test it per surface, but the pattern holds: samples help comprehension surfaces (reports, boards) and hurt creation surfaces (the main list, where the sample satisfies the urge the CTA needs). Hybrid — one labeled example plus a strong create path — wins most tests.
Do empty states matter after onboarding?
The same screens render for every new project, teammate and season — an empty Q1 report in January is onboarding again. Designing them once pays on every recurrence.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.