Who it's for
B2B SaaS teams where admin and customer UI drifted apart. Live products with tenants, roles, and billing - where the champion cannot explain what a new member should do on day one.
Multi-tenant SaaS UX
Two products. One family.
Admin and customer surfaces in one coherent system - workspace context, roles people can explain, and a shared kit engineering can ship without forking the product.
Multi-tenant SaaS product design for admin and customer surfaces
What we deliver
Multi-tenant UX design: admin consoles, customer workspaces, role models, and a shared component kit with tenant-safe variants. Phased rollout into live products, not a big-bang redesign.
Problems we solve
Empty workspaces after signup, permission fog, and parallel admin/customer roadmaps. When every release risks forking the product, we map workspace → role → surface → action first.
Kriva is a product design and engineering studio - not a boxed SaaS vendor. You own the designs, component specs, and documentation after launch. For full build scope (MVP + engineering), start at SaaS product solutions.
Which page should I read? This page is for multi-tenant admin and customer surfaces in live SaaS. For MVP, onboarding strategy, and engineering scope, start at SaaS product solutions.
Where it stalls
The product works.
The tenant does not stick.
Live SaaS rarely fails on polish. It fails when admin, customer, and roles drift apart - and nobody can explain what a tenant should do next.
Empty workspace after signup
The happy path assumes an admin who already knows the product. New tenants hit a blank state and leave, or open a ticket that should have been a first-run path.COST: churn before first value, support load on day one
Permission fog
Roles were added for sales and security. Users hit “you don’t have access” with no path to the owner or admin who can grant it.COST: blocked actions, champion escalations, sales confusion
A change hits every workspace
Teams freeze UI work rather than ship incrementally. Without a shared kit, every release risks forking admin and customer into two roadmaps.COST: parallel design systems, slower releases, tenant regressions
Tenant & role model
Workspace → role → surface → action
Every screen answers four questions before UI begins - so admin and customer stay one family, not two products bolted together.
-
01
Workspace
Which tenant is this? Nav, empty states, and billing copy follow that context.
-
02
Role
Owner, admin, member, guest - in language the champion can repeat on a sales call.
-
03
Surface
Admin console or customer workspace: same kit, different job.
-
04
Action
What can this role do here? Blocked actions name who can unlock them.
-
05
Next step
One clear move: invite, import, ask admin, or complete the job they came for.
What we design
The three surfaces in one product family
Admin, customer, and permissions - each with a distinct job, built from the same component kit.
An admin console the champion can run
Members, billing, and integrations in language that matches how the team actually joins, not a policy matrix dumped into settings.
- Invite flows that match how seats are bought
- Safe defaults before enterprise policy
- Members, billing, integrations, seat controls
A customer product that inherits the kit
Workspace home, empty states, and next actions that know the tenant and the role: so “you don’t have access” is never a dead end.
- Role-aware empty states, not a blank canvas
- Ask-admin path when an action is blocked
- Daily actions that know workspace context
A role model sales can explain
Four roles most B2B products actually need. Advanced policy waits until someone asks for it, after first value, not before.
- Plain-language roles before SSO sprawl
- Capabilities named, not buried in policy
- A matrix engineering can implement once
Product system
One kit, not two product forks
Shared components with tenant-safe variants. Engineering ships one family - design does not maintain parallel admin and customer roadmaps.
One pattern, both surfaces
Type, density, buttons, and tables stay in one system: admin and customer inherit the same foundation.
Tenant-safe diffs
Variants for role, tenant state, and surface - not a separate codebase per screen.
Phase into live
Flagged variants ship incrementally. A workspace stays usable while the kit evolves.
Case study · PayrollPro
Permissions after SSO.
Progressive onboarding and permission clarity for a UK & EU payroll platform - after SSO pushed admin setup ahead of the job.
- Problem
- SSO made permission setup block the first payroll run. Buyers authenticated but never reached the job.
- Decision
- Default safe role on entry. Defer the policy matrix until after first value.
- Workflow
- Admin and customer surfaces share one kit: first sitting completes a real pay run before advanced roles.
- Sector
- B2B SaaS · payroll
- Scope
- Role model, admin vs customer kit, onboarding paths
PayrollPro is a published case study. Client labels may be portfolio names. Signed-off numeric outcomes appear only on ShiftRail.
payrollpro / first sitting
First sittingAfter SSO
SSOIdentity verified
DoneLink bankSafe default role
DoneRun test cycleFirst value · not policy setup
NowInvite rolesAfter the run completes
LaterPattern from the published PayrollPro study · illustrative UI only
How we engage
From tenant map to phased rollout
Every step ties to a live SaaS product - not a generic agency process deck.
-
01
Map tenants & roles
Who is in the workspace, what they can do, and which surface they open. Named before screens.
-
02
Design both surfaces
Admin and customer in one family: empty states, blocked actions, and the ask-admin path.
-
03
Spec variants
Components and flagged variants engineering can ship without a rewrite.
-
04
Phase into live
Sequence the rollout so tenants stay usable while the kit evolves.
Adjacent services
Often sits next to this brief
This service owns tenant-aware UX. These are the capabilities that usually sit beside it.
01
Product Design & UX
Whole-product story, flows, and launch-ready UI when the product is new or being rebuilt.
→ 02Dashboard Design
The morning scan: hierarchy, filters, and exceptions - not the first-run or the role model.
→ 03SaaS Product Solutions
Activation, onboarding, and MVPs when the leak is signup-to-first-value, not the kit itself.
→FAQ
About this service
How this differs from Product Design and Dashboard Design - and how we ship into a live tenant.
Yes. Phased rollouts are the default. We work inside the live product with flagged variants and a sequence engineering can ship: without a big-bang cutover.
Product Design owns the whole-product story for new or rebuilt products. This service owns tenant-aware UX, permissions, and admin versus customer surfaces on a live SaaS. Many engagements start here when the product is already shipping.
Dashboard Design owns the morning scan: hierarchy, filters, drill-downs. This service owns workspace context, roles, and the relationship between admin and customer UI. A live SaaS often needs both.
Yes. The brief is usually the gap between them: an admin console that drifted, a customer product that never inherited the same patterns, and permissions that only make sense to the person who built the role model.
Design-only or design-and-build. Tenant model and API contracts are in scope when engineering is. Full MVP scope lives on SaaS product solutions.
Start a conversation
Show us where admin and customer diverge.
If admin and customer surfaces do not share permissions, roles, and one system - say where they drifted. We'll review the tenant model and recommend a phased path. No RFP required.
Reply within one business day NDA available No obligation
Inquiry received.
We will reply within one business day. If you still need a longer brief or a scheduled call, use the contact page.