We’ve seen new customers often start with features - Workspaces, Layouts, Window Management, Launchpad… and later ask what users are actually trying to do.
But I suggest flipping it.
First, do a design exercise: map real user journeys to the right desktop primitives, and only then decide what you should standardize, what you should automate, and what you should leave flexible.
Step 1: Define the user journey
To design an interop experience, you first need a clear picture of your users, their workflows, and what “success” looks like in their day-to-day work.
Start by answering practical UX questions:
- Who are the users? Traders? Wealth managers? Call center agents? Platform admins?
- What do they want to achieve? (Goals, not features.)
- What tasks do they perform? Are they repetitive? Are they complex? Are they time-sensitive?
- How many applications does one task require? One screen or six apps side-by-side?
- How many tasks do they run in parallel? Are they juggling multiple “active states” at once?
- Do they have defined workflows? Or do they improvise and switch constantly?
- How often do they switch contexts? Every 30 seconds, or a few times a day?
- What environment are they in? Desktop-first? Tablet-first? A mix? Do they need both?
- What matters more: flexibility or standardization? Do they need strict layouts, or freedom to rearrange?
When you’ve answered these (and perhaps a few more), you have an overview that outlines what your UX actually needs to support. Now you can apply the io.Connect Desktop capabilities that support those journeys.
If you’re unsure which approach fits best, several short consultations/meetings can save weeks of rework, because it forces alignment on journeys, needs, and expectations.
Takeaway
Start by mapping user journeys to interop UX patterns. Apply the patterns and UI capabilities that support your user journey flows. Increase adoptions by supporting user needs. If you start just with features, you’ll design something that looks shiny, but doesn’t serve practical needs.
Step 2: Translate journeys into desktop UX primitives
Once you know the workflows, you’re essentially choosing desktop primitives:
- Do users need structured “task execution spaces”? That usually points to Workspaces (a unified frame where apps become building blocks).
- Do users need “return to a known state” across many apps, monitors, and workflows? That’s Layouts (save/restore arrangements + context).
- Do you need the fundamentals of desktop control - window types, grouping, docking, programmatic control? That’s Window Management.
You can use all of them together, but they solve different UX problems.
Let’s go deeper into Workspaces and Layouts.
Workspaces: one unified frame for task execution
If your users regularly work inside a known task cockpit (a repeatable set of apps arranged in a repeatable way), Workspaces are a great UX lever.
What a Workspace is in UX terms
A Workspace is not “multiple windows”. It’s a single visual container (“Workspaces App” / “Frame”) where multiple apps are arranged as a structured layout. Apps become individual building blocks that users (or you programatically) can add, remove, move, resize, and recompose. And users can have as many workspaces and match them to their activities. They can switch between them right from the workspace frame or load and manage them from the integrated launchpad. Workspaces support a locking model where specific functionality can be suspended or UI controls hidden to prevent modification (e.g., disabling drop/extract, hiding Save/Eject/Close controls, etc.).
Workspaces support both user-driven composition (drag/drop, rearrange, eject) and programmatic composition (the platform can build and restore the workspace for the user). Тhey let you design a consistent “task space” without forcing every app team to redesign their UI.
Saving and restoring a Workspace Layout
A Workspace Layout is a blueprint for a single Workspace: it captures what’s inside that Workspace (the set of apps/components and how they’re arranged in the Workspace frame) and is primarily about restoring a focused “task cockpit.”
They can be:
- created programmatically,
- defined in the Workspaces App definition,
- or fetched from a layout store (including io.Manager-backed setups).
From a UX perspective it means:
- You can treat layouts as design artifacts.
- You can ship “recommended task spaces” without hardcoding UI logic into each app.
- You can still allow user personalization on top (depending on your controls model).
If you want apps to interact with the Workspaces model intentionally, the Workspaces API is accessible via io.workspaces, enabled by adding the Workspaces library to the IODesktop initialization (using the globally injected IOWorkspaces() factory). See docs for more details.
Takeaway
Workspaces are for task execution UX: one structured cockpit, repeatable composition, and a model for controlled flexibility.
Layouts: autonomy, personalization, multi-monitor
Workspaces solve “inside the cockpit”. Layouts solve “the whole desktop”.
What a Layout is in UX terms
In large enterprises, users often run multi-monitor setups and arrange apps “the way they work.” Layouts let users save and later restore the exact arrangement and context of their whole environment - windows, apps, Workspaces, and their bounds, then switch between activity-specific setups without losing progress.
One example is traders, as they usually require a large set of apps, which are often arranged on more than one monitor. For them, layouts provide a great way to easily load all apps the way they have left them, along with their context, with the exact bounds and on the exact location. They can have layouts that map their activities, such as ”Start of a day” or “Buy” and “Sell”. And they can switch between those without losing progress. This type of UX encourages experimentation and flexibility.
Users have Personalization through personal layout saving. Basically, they can do whatever they want with all interop-enabled apps. They can move them freely and position them where necessary, and platform admins can provide preconfigured layouts (distributed through io.Manager) that speed up the process.
As with Workspaces, the Layout functionality is available within the UI and programmatically.
The Layouts library supports:
- saving and restoring layouts
- importing/exporting/removing/getting layouts
- hibernating and resuming layouts (faster switching at the expense of system resources)
- events related to added/removed/changed/saved layouts
Saving and restoring a Layout
Saving/restoring a Layout is about bringing back the entire environment: windows across monitors, window groups, and Workspaces together with their bounds and (optionally) context. Restoring can be designed as task switching (minimal disruption, keep running instances) or as reset to known good (close running instances first). Workspace Layout restore gets you back into a specific cockpit, while Layout restore gets you back into a known full-desktop state and can be tuned for either continuity or cleanup depending on how users actually work.
The default Global Layout: “start my day for me”
Users often need the same starting environment every morning.
io.Connect Desktop supports a default Global Layout that can be loaded on startup, so users don’t waste time rebuilding their baseline environment. See docs for more details.
Layout store
In the standard deployment model, layouts are typically served remotely (not stored locally), and the platform can pull a remote store to discover new layouts. This store is usually connected to an entitlement system, so different users can have different layouts.
That’s a major UX unlock:
- You can deliver role-based layouts (e.g., “Trader AM”, “Trader PM”, “Supervisor”, “Support”).
- You can enforce consistency without removing personalization completely.
- You can onboard users by giving them a working desktop from day one.
The hybrid model: Workspaces inside Layouts (and why it’s powerful)
While planning architects often select between Workspaces or Layouts, but you don’t have to. Layouts can include Workspaces. In fact, a Global Layout can contain windows, window groups, and Workspaces. That’s the hybrid model:
- Workspaces define the structured task cockpit.
- Layouts define the full desktop state, potentially including multiple workspaces + other windows.
And you can have:
- a Workspace as your “main cockpit” (controlled, structured, governed),
- plus additional windows/groups across monitors,
- all saved and restored together as a Global Layout.
There’s even a restore option that controls whether Workspaces in a Global Layout are restored by reference (their original saved definition) versus restoring them exactly as they were at the moment the Global Layout was saved (restoreWorkspacesByReference).
That matters for UX consistency:
- Restore-by-reference supports “always restore the standard workspace template”.
- Restore-the-snapshot supports “restore exactly how the user last left it”.
Both are valid. The right choice depends on whether your UX strategy is standardization-first or personalization-first.
So in your practice do you use Workspaces, Layouts, or both and how? Do your end-users understand (or care about) the difference?
And do you use these terms internally or have renamed them to something that makes more sense at your org?
I’m curious to read your thoughts in the comments.