All posts

May 26, 2026

Every Screen Your B2B SaaS Needs: A Complete Design Checklist

Most AI design tools generate the screens you describe. A complete B2B SaaS product needs screens you haven't thought to describe yet. Here's the full list — and how to get all of them in one generation.

When a B2B SaaS founder says they need a design, they usually mean they need their core feature designed. The dashboard. The main workflow. The screen that does the thing the product does.

What they're less likely to have thought through — until engineering asks — is everything else. The onboarding that gets users from signup to that core feature. The settings page that an admin needs to configure the workspace. The billing and plan management screens that every paying product eventually requires. The team management view. The invitation flow. The empty states that appear before any data exists. The error states that appear when something goes wrong. The email confirmation screens. The password reset flow.

None of these are the product. All of them are required for the product to ship.

The full screen inventory

A complete B2B SaaS design typically needs coverage across these categories:

Authentication Sign up, log in, forgot password, password reset, email verification, invite acceptance (distinct from standard signup), SSO or OAuth entry points if applicable.

Onboarding Welcome and orientation, workspace or account setup, first-use guidance for the core feature, first-value delivery screen, completion and "you're set up" state. If there are multiple user types — admins who set up the workspace and members who join it — each needs a distinct onboarding path.

Core feature screens Whatever the product does: the main list or dashboard, the detail or editor view, the creation flow, the settings for individual items. For most B2B tools, this includes both the populated state (normal usage) and the empty state (first use, no data yet) for every view.

Navigation and global structure Sidebar or header navigation, application shell, breadcrumbs if the information architecture has depth, search or command palette if the product warrants it.

Team and user management Member list, invite flow, role assignment, pending invite states, removing a member, role permissions view.

Workspace and account settings General settings, notification preferences, integrations or connected accounts, data export, account deletion with appropriate confirmation.

Billing and subscription Current plan view, upgrade/downgrade flow, payment method management, invoice history, trial expiry states, cancellation flow with confirmation and win-back moment.

Notifications In-app notification centre (if the product has activity that generates notifications), notification preferences, read/unread states.

Error and edge states 404 page, permission denied, session expired, maintenance or downtime, failed action states for any critical flows.

Why most AI tools don't get you here

The gap isn't prompting skill. You could describe every category above in a prompt and get something generated for each one. The problem is that individually prompted screens don't add up to a coherent product.

The billing page generated separately from the settings page may have different component vocabulary. The onboarding for admins, prompted weeks after the core feature, may use different visual patterns and different copy voice. The empty states, added last because they were thought of last, may not match the populated states they mirror. The team management flow may handle roles that don't match the role structure established in the core feature.

These inconsistencies are invisible in demos. They become visible when engineers are working from the designs and realise that different screens make different assumptions about the same data structures, or that the same action is represented three different ways depending on which screen was generated first.

How spec-driven generation covers the full inventory

Mowgli's questionnaire doesn't just ask about the core feature. It asks about user types, which determines the scope of role-differentiated screens. It asks about first-time flows, which determines the onboarding sequence. It asks about edge states and error conditions, which determines the coverage of empty, error, and permission-denied states. It asks about scope and boundaries, which surfaces whether billing, team management, and settings are in scope or out.

These answers go into the spec. The spec is the product model. The generation is an expression of that model across every screen it implies — not just the screens that were individually described, but all the screens that follow from the product being what the spec says it is.

For a typical B2B SaaS product, this means 30 to 50+ screens generated in one pass: the core feature in its populated and empty states, the full onboarding sequence for each user type, the settings and team management screens, the billing flow, the authentication screens, and the full set of error and edge states the spec defined. All in the same visual language, all derived from the same product model, all coherent with each other.

Starting from a partial design

If you're further along — you have some screens but the rest of the inventory is missing — you bring what exists into Mowgli and it gets absorbed into the spec. From there, you're not on your own figuring out what's missing. Mowgli lives through the spec: it knows what you're building, what flows exist, and what the product is trying to do. Ask it what's missing. Ask it what you should add next. Ask whether the billing flow covers the trial expiry case or whether the team management section needs a permissions screen. Because Mowgli is always aware of the full spec, it can answer those questions with the context of your actual product — not as a generic AI assistant, but as a co-pilot that has been in the room for every product decision you've made.

The goal, at any stage, is the same: a complete, coherent design set that covers the whole product, not just the part that was easiest to describe. Engineering a product from an incomplete design doesn't go well. The missing screens don't stay missing — they get made up during implementation, without the benefit of the design decisions that would have made them consistent.

Sources