Flexible data products have a predictable onboarding problem. The empty state is technically correct. It also hides the product model.
That was the issue in Omnismith's original onboarding flow. New users were shown the interface, then dropped into a project with no templates, no attributes, and no entities. The tutorial explained the controls, but it did not show how a real workspace should be structured.
Users could follow individual actions. They still lacked a working mental model of the product.
The blank-canvas problem
Omnismith is flexible by design. Users define templates, attributes, references, and entities to fit their own domain.
That flexibility creates a cost during the first session. A new user has to understand both the interface and the shape of a finished system.
The original onboarding handled the first part and missed the second.
A flexible product is easier to understand when users can inspect a coherent example. Omnismith's onboarding gap came from missing context around the model and the workspace structure.
What the first session needed
The onboarding flow needed to expose the model immediately.
That meant starting with a project that contained:
- a concrete schema
- example records
- visible relationships between records
- enough structure to make browsing and editing feel like real work
The example also needed to stay small and coherent while still showing how the parts fit together.
The first redesign: a seeded demo project
The first redesign used a seeded Product Catalog project.
The dataset was intentionally small, but structurally complete enough to teach the model:
- 3 templates: Category, Brand, Product
- 11 attributes across those templates
- shared fields such as
NameandDescription - references from Product to Category and Brand
- a self-reference for related products
- 19 sample entities with realistic values
This was enough to make the system legible. A user could open the project and immediately see that templates define structure, entities hold values, and references connect records into something closer to a real application than an empty workspace does.
That scope was deliberate. The dataset's job was to make the product model visible within the first few minutes.
Why the guided tour still mattered
The demo project provided context, and the guided tour directed attention.
Users had a concrete workspace to inspect, and the tour moved them through the important surfaces in the right order.
Together, they reduced the time between first login and first useful understanding.
What this solved, and what it did not
This redesign fixed the immediate blank-canvas failure. New users no longer had to infer the product model from an empty screen.
It did not solve every onboarding problem.
One seeded dataset is still one opinionated starting point. It helps users understand the system, but it also assumes that one example should be relevant to everyone. That later became the next onboarding problem to solve.
Conclusion
For flexible products, an empty workspace is a poor first lesson.
Omnismith became easier to understand after onboarding began with a small working system. Clear visibility into the product model improved first-session comprehension.
That was the first onboarding redesign. The next question was how to keep that clarity without forcing every user into the same example.
Top comments (0)