How Should a SaaS App Handle Switching Between Workspaces?

How should a SaaS app handle switching between workspaces?

Treat the switcher as a mode control, not a navigation control. The workspace a user is in changes what every other action means, which is the textbook definition of a mode. Design it with that in mind and the hard problems mostly solve themselves. Design it as a dropdown and you will ship data into the wrong account.

This is one of those features that looks like a two hour job and turns into a quarter of bug reports. The dropdown is easy. Everything downstream of the dropdown is not.

So this is a framework rather than a gallery of nice switchers. Five questions, in order. Answer them before you open Figma and the interface tends to design itself.

Why is a workspace switcher a mode, not a menu?

Page Laubheimer of Nielsen Norman Group defined modes in April 2019 as different interpretations of the user input by the system depending on which state is active. Same input, different results. That is exactly what a workspace does. Clicking Delete means one thing in the sandbox and something very different in the customer's production account.

A menu takes you somewhere. A mode changes what everything means without moving you anywhere. Confusing the two is the root cause of most workspace bugs we have seen, because it leads teams to style the switcher like navigation and then wonder why people lose track of it.

Laubheimer calls the failure a mode slip: the user is not aware of the currently active mode. His example is a 1991 plane crash where a control meant for a 3.3 degree descent was interpreted as 3,300 feet per minute. Nobody misread a label. The mode was simply not visible enough.

Question one: how does a user know where they are?

Answer it with redundancy, not a single label. NN/g's recommendation for modes is at least two visual indicators, such as highlighting on the mode selector combined with a cursor change. For workspaces, that means the name in the switcher plus one persistent environmental cue.

The cheapest second cue is colour, applied to a persistent element like the top bar or the sidebar edge, with the colour chosen by the workspace owner rather than assigned by you. People learn their own colour in a day and stop reading the label entirely.

This is Nielsen's first heuristic, visibility of system status, which says the design should always keep users informed about what is going on. It is first on the list for a reason, and workspace switching is where most products quietly fail it.

Question two: what happens to the page you were on?

Decide deliberately between three options and apply one everywhere. Stay on the equivalent page in the new workspace, return to a home or dashboard, or block the switch while unsaved work exists. Products that mix all three, depending on the screen, teach users that switching is unpredictable.

Our default recommendation is the equivalent page when a clean equivalent exists, and the dashboard when it does not. Landing on a settings screen for a workspace you just entered is disorienting in a way that landing on its overview is not.

Never silently discard unsaved work. That is Nielsen's third heuristic, user control and freedom, which asks for a clearly marked emergency exit for actions taken by mistake.

Question three: which actions must never cross a workspace boundary?

List them before you build. Typically: anything that deletes, anything that bills, anything that invites a person, and anything that publishes to the outside world. These get a confirmation that names the workspace in the confirmation text itself, not just in the corner of the screen.

Naming the workspace inside the confirmation is the single highest value detail in this whole feature. "Delete this project?" is a mode slip waiting to happen. "Delete Onboarding Flow from Acme Production?" is not, because the mode is now in the user's line of sight at the exact moment it matters.

This is Nielsen's fifth heuristic, error prevention, which holds that the best designs carefully prevent problems from occurring rather than explaining them afterwards. A good error message here is already too late. The related ground on reversibility is covered in designing undo for destructive actions.

Question four: how do permissions differ per workspace?

Assume they always differ, and show the current role next to the workspace name. A user who is an admin in one workspace and a viewer in another will otherwise experience your product as randomly broken, clicking things that do nothing and finding menus that moved.

The failure mode is subtle. People do not read a disabled button as a permission signal. They read it as a bug, and they file it as one. Showing the role turns a support ticket into a two second realisation.

How you structure those roles in the first place is a separate and larger design problem, and we worked through it in how to design roles and permissions people understand.

Question five: what does the switcher itself need to show?

Workspace name, the user's role, and a distinguishing mark such as a logo or colour. Nothing else. Resist member counts, plan badges and last activity, all of which crowd out the three things someone is actually scanning for.

Sort by recency of use, not alphabetically. People return to two or three workspaces constantly and visit the rest rarely, and a recency sort puts the right ones at the top without anyone configuring anything.

Add search once a meaningful share of users pass roughly seven workspaces. Below that it is clutter. Above it, scanning fails and recognition stops working, which is Nielsen's sixth heuristic, recognition rather than recall, asking you to minimise the user's memory load by keeping options visible.

Does this problem actually affect enough users to justify the work?

Yes, and the direction of travel is clear. Zylo's 2026 SaaS Management Index reports that the average company manages 305 SaaS applications, and that marketing teams alone use an average of 103 marketing related applications.

The same index found licence utilisation improved from 47% in 2024 to 54% in 2025. Roughly half of purchased seats still go unused, which tells you how much of this sprawl is people holding access they touch occasionally rather than daily.

Occasional access is exactly the dangerous case. A daily user learns your switcher. A monthly user does not, and they are the one who will act in the wrong workspace.

What about agencies and consultants, who live in this problem?

They are your hardest users and your best testers. A person who manages fifteen client workspaces switches more in a week than an internal user does in a year, and every weakness in your design shows up in their workflow first.

Two things help them disproportionately. Let them pin a handful of workspaces above the recency list. And make the distinguishing colour or logo theirs to set, so their mental model matches their client roster rather than your data model.

We sit on this side of the problem ourselves, moving between client environments all day, which is why we have opinions about it that are stronger than the feature usually deserves.

What is the most common mistake teams make here?

Putting the switcher inside the settings area. It gets there because engineering treats workspace as account configuration, and it is wrong because switching is something people do constantly while working, not something they do while configuring.

The second most common is inconsistent placement between the web app, the mobile view, and the admin area. Nielsen's fourth heuristic, consistency and standards, says users should not have to wonder whether different words, situations or actions mean the same thing. A switcher that moves between surfaces breaks that on every visit.

The third is treating the switcher as final polish. Because it touches routing, permissions and data scoping, it is architectural, and retrofitting it is much more expensive than it looks. A related pattern shows up in how settings pages accumulate.

How would you test whether yours works?

Run one task with five people who each belong to at least three workspaces. Ask them to perform a destructive action in a specific named workspace, without telling them how to switch. Watch where their eyes go before they click. If they check the switcher, your cues are working. If they do not, they are not.

Then check your own data for the strongest signal available: how often a user switches workspaces within sixty seconds of arriving. That is a person realising they were in the wrong place, and it is the closest thing to a mode slip counter you can get without instrumenting anything new.

We design these systems alongside the marketing sites that sell them, which means we see both the promise and the product. If you are adding multi workspace support and want a second pair of eyes before it reaches the architecture, we are happy to talk it through. You can find us at phoenix.studio.