Designing complex B2B SaaS: roles, permissions, admin and multi-tenant workflows

If you're weighing whether a design partner for SaaS can handle admin, workspaces, and permission-heavy product work, this page is the decision guide for that shape of problem.

The moment it breaks

The question I ask early on any B2B product: can you show me this same screen as a read-only member? Too often the answer is broken buttons, an empty state that says nothing, and settings the member should not see. The invite flow stalls. Options show up that the role should never reach. Three screens in, it's clear: the whole product was designed for one role.

This happens constantly in B2B SaaS. Roles and permissions are not visually exciting to design. They feel like a checkbox. So teams defer them, ship the happy path, and discover the gaps through support tickets. Users write in because they can't see what they need. Admins can't find the setting. Guests get errors that mean nothing.

The fix is designing the right screens for each role, before anyone writes a line of code.

Start with a role map, not screens

The first document I build is not a wireframe. It's a simple grid: who can see what, and who can do what.

This is a minimal example. This is not client data. It's a starting point to show what the matrix looks like.

Most products have more nuance than this. Permissions are often conditional: a member can edit their own records but not others'. Some actions are gated by plan tier, not just role. The matrix has to capture those cases too.

This document comes before any UI design starts. It becomes the reference point for every screen we build. When a designer or engineer asks "what should happen here for a viewer?", the answer is already written down.

Designing every screen per role

Once the matrix exists, the real work begins. Every screen has to be designed in every state for every role that can reach it.

That means more than greying out buttons. A disabled button with no explanation leaves users stuck. A better pattern: disabled with a tooltip that says "ask your admin to enable this." Or a locked field that explains why it's locked. Or a permission-denied state that tells people what to do next, not just that they can't proceed.

Empty states differ by role too. A new member sees an empty project list because nothing's been shared with them yet. An admin sees it because no projects exist. Same screen, different message, different call to action.

Do not just design the happy path. Design what a viewer sees when they land on a page an owner built. Design what happens when someone tries to access a URL they do not have permission for. Users find the edge cases. Build them.

Admin consoles and settings

Settings pages are where people go looking and give up. They can't find what they need. The structure does not match how they think.

The first decision: what's a workspace setting versus a personal setting? Workspace settings affect everyone. Personal settings affect only the user. These belong in different places. Mixing them creates confusion that's hard to untangle later.

Within workspace settings, billing deserves its own section with a clear owner. Only certain roles should reach it. Members and invites belong together. Single sign-on, security, and audit settings belong with admins. Surfacing these in the wrong place (or not at all) is what generates those "where do I find X?" tickets.

I work through the information architecture of settings before touching the visual design. It's faster than redesigning it after launch. For internal tools and business portals where customers or partners see the admin side, the bar for clarity is even higher.

Multi-tenant and workspace patterns

Multi-tenant means one app serves many separate organizations, each with their own data. The UI has to make clear which organization you're currently in. Users who belong to multiple workspaces need to switch between them without confusion. And data from one tenant must never appear in another.

Agencies and consultants often belong to many client accounts. The workspace-switching pattern matters a lot for them. The current account should be obvious at a glance. Switching should be fast and reversible.

Data leakage in the UI is usually an engineering bug, but design plays a role. If a dropdown includes items from another workspace, that's a design failure before it's an engineering one. The prototypes we build make these risks visible before code ships.

Approval and audit flows

Request, approve, reject. These flows look simple. They rarely are.

A rejection without a reason is a dead end. The person who requested something does not know what to fix or who to ask. Build the reason into the reject action. Make it required, or at least easy.

Audit logs are the other side of this. Someone needs to know who approved what, and when. Most audit logs are a wall of timestamps and system IDs that no one can actually read. A better audit log surfaces the human action: "Maria approved the budget request on Tuesday" is more useful than a raw event ID.

If your product has approval flows, it probably needs an audit log. It does not have to be complex. It has to be readable.

How this lands in an existing design system and codebase

Permission-aware components are worth building once and reusing everywhere. A button that knows it can be disabled-with-reason is more useful than a plain button with a tooltip bolted on afterward. A role badge, a locked field, a "request access" state: these become components in the system.

Documentation matters here. Engineers and AI coding tools both benefit from clear rules about what each role can do. We write those rules where the team can find them, not buried in a Figma comment.

Prototypes close the loop. Before engineering commits to building a flow, we prototype it and click through it as each role. Stakeholders see what a viewer actually experiences. Product leads catch gaps before they become bugs. This saves real time later.

If the system has drifted from production, a design system audit is often the right first move. If you're planning a broader UI rebuild on top of messy roles, read when to redesign a SaaS product and consider a pre-redesign audit before you commit engineering months.

Real examples from our own work

For Cloud Accountant Staffing, we designed a self-service candidate portal where employers search, filter, and shortlist pre-vetted accounting talent at their own pace. Employers and admins see a different surface than candidates browsing the pool. We built it prototype-first so those flows were clickable before development started.

For Suggestion Ox, we designed live Q&A with moderator and attendee views. Questions come in, get approved, upvoted, answered, or dismissed. Moderators and attendees see fundamentally different interfaces. A full prototype plus a style guide gave their backend team a concrete target to build toward.

For Nekst, a real estate CRM, we built a working prototype and a component system so the Nekst team and the AI tools they build with could extend the direction after the engagement.

When an embedded design partner fits vs an in-house hire

A design partner fits when you need senior judgment across roles, admin, and system design right now, and your team is actively shipping. You get coverage without the ramp-up time.

A full-time hire fits when the product surface is large and stable enough to justify a permanent owner. Someone who lives inside the product every day.

You can do both in order. You can bring in a partner to set the foundation, then hire someone to own it long-term. The dedicated designer versus embedded partner split is on dedicated designer vs embedded product partner.

When the work is a full product surface with roles baked in, not a single portal, product redesigns often run as back-to-back Sprints after the role map exists.

How we'd start

We start with a two-week Sprint at $3,750. The goal: map your roles and prototype the riskiest flows. At the end, you have a working clickable prototype and a clear decision to make about next steps.

If you want to continue, we work on a monthly basis. Standard is $4,995 per month. Advanced is $7,495 per month. Bigger work is scoped in back-to-back Sprints. We do not quote fixed project fees. Published prices are on pricing: a Sprint is $3,750 for two weeks, Standard is $4,995 a month, and Advanced is $7,495 a month.