Imagine a stage full of world-class musicians who’ve never met before. Without hearing each other, everyone plays at their own tempo and style and at their own moment. The result isn’t a symphony - it’s noise if there’s no conductor to help them synchronize.
Interop UX is the conductor (orchestrator layer). It brings timing, structure, and intent. It’s what happens when individual apps start playing as an orchestra, when the right UI cues come on time, the right data flows between components, and the right actions happen exactly when the logic calls for them.
Apps “talk” to each other: exchange data, trigger actions, and share context.
End-users can “focus” on what’s important - their tasks and goals while using a consistent and unified interface. Everything acts and feels like one synchronized system, no matter the tech stack behind, and how many apps you have. Users connect data sources and navigate between apps as part of one continuous flow rather than juggling windows or fragmented apps.
There are three layers that make Interop UX:
1. UI Interop: consistent interaction patterns across apps
UI Interop makes the difference between “every widget looks and behaves differently” and “the desktop feels like one suite.” In practice, the systems you need to connect come from many different vendors, teams, tech stacks, and even eras (30-year-old legacy platforms sitting next to modern AI apps), and often have little in common. What helps bridge that gap are themes that can be fully customized (using predefined ones as a base or creating them from scratch), and serve as a visual unifier. Platform Styles allow changes that span across themes, while running apps inside shared frames (such as Workspace frames or Web Group app headers) and platform components like dialogs and notification toasts help the platform act as one system. Not just visually, but behaviorally, as each element listens and acts toward the user’s intent and is translated across the platform. A simple example is when all apps indicate shared context at the same time, or when apps react consistently to a theme updates.
Themes: dynamic UI consistency at runtime
io.Connect Desktop supports Themes as a first-class platform capability. Themes can be switched at runtime (for example light/dark or firm-specific variants), and apps can react to theme changes via the Themes API. When apps subscribe to theme changes, users no longer experience half-dark, half-light desktops - a common view in complex environments.
You can read more about themes here:
Platform Styles: one design system across system UI and apps
io.Connect Desktop provides Platform Styles - a shared styling layer used by system UI surfaces, including:
- Launchpad
- Workspaces (Frames, tabs, controls)
- Web Groups
- Modal windows and dialogs
System apps are styled using a common theme package (@interopio/theme) and expose CSS variables that can be overridden to match your design sy@interopiotem. This means you don’t have to re-skin every system surface individually to achieve a consistent look and feel.
Users stop mentally “switching products” when moving between system UI and business apps. Brand alignment becomes systemic, not best-effort and visual changes (colors, spacing, typography) can be rolled out centrally instead of app by app.
Platform Styles are intentionally variable-driven: base colors feed into semantic variables, which then flow into individual components. Change the foundation once, and the entire platform adjusts coherently.
You can explore the growing list of Platform styles here: io.Connect Desktop Documentation - Platform Styles
Windows, groups, and frames as UX surface area
UI interop also includes how windows themselves behave and look.
io.Connect treats windows as platform objects, which means you can standardize:
- Window frames and controls
- Tabs and window grouping behavior
- Sticky windows
- Always-on-top functionality
- Custom frame buttons and actions
This matters because window decorations are part of the UX. When some apps have tabs, some don’t, some tear off, some don’t, this affects the flow. With Web Groups, the group frame itself becomes a customizable UI surface area. Instead of a generic container, the group can expose controls, indicators, or workflow affordances that belong to the group, not to any single app inside it, so the functionality moves up from individual apps into a shared UI.
The goal of UI interop is not visual polish. It’s cognitive offloading. When users recognize patterns, they stop re-learning the environment and even unknown actions become natural. Interop succeeds when users stop thinking about how to use the desktop and focus entirely on what they’re trying to do.
Once the UI behaves and looks like one system, the next question becomes: how does context move through it? That’s where data interop takes over.
2. Data Interop: shared context that keeps apps in sync
Data interop is where apps exchange context: selected client, instrument, trade, etc. A selection in one app can synchronize with other apps.
A core capability allowing this is the Channel Selector. It is intended for end-user-controlled synchronization and data sharing.
On the other side we have shared contexts which are set programmatically. The UX here is to help users understand when, and why data changes.
io.Connect provides standardized mechanisms for:
- Modal dialogs and confirmations
- Alerts and blocking flows
- Notifications with consistent placement, actions, and severity
When every app invents its own flow or confirmation behavior, users hesitate. But if they follow a shared pattern, users act faster and with more confidence. This is especially important in regulated or high-pressure workflows, where “Did I really confirm this?” should never be ambiguous.
If you want to go deeper into the technical concepts, and when each shines check:
- Key Integration Concepts: Key io.Connect Integration Concepts Explained
- Data sharing cheatsheet: io.Connect Data Sharing Comparison Cheatsheet
- Channels documentation: io.Connect Desktop Documentation - Data Sharing > Channels > Overview
3. Workflow Interop: continuous flows vs. window juggling
Workflow interop is where interoperability stops being “data sync” and starts feeling like a guided experience. The user isn’t just seeing the same ticker in multiple places - they’re being moved through a sequence: discover → open the right tool → land in the correct state → take the next action without losing momentum. If UI interop reduces cognitive load and data interop keeps apps aligned, workflow interop is what turns those two into a repeatable journey.
A practical way to think about it is: how do workflows start, and how do they keep going? Starting is often a discovery problem. A user needs one dependable hub where they can find what’s available - apps, Workspaces, Layouts, notifications, and settings, and where search behaves like a real platform feature, not a simple filter. That hub becomes the “starting point” for new activities and task switching, especially in multi-app environments where users don’t want to remember which tool is responsible for which step.
Continuing a workflow is about designing the “next click.” Notifications are a good example because they can carry actions and route users forward. A well-designed notification isn’t an FYI - it’s a decision point. The click can take the user into a handling flow by invoking an interop method, and action buttons can represent the top two “next steps” the user is likely to take. That turns alerts into controlled micro-workflows: acknowledge → open portfolio → call client → escalate, all without forcing the user to manually hunt for what’s next.
Workflow interop is when users can launch, navigate, and organize streams as one continuous flow, rather than bouncing between windows or tabs. Behind the scenes actions are handled via Intents, Interop methods, Pub/Sub.
This is also where platform UX primitives come into play. Core building blocks like different Window types, Workspaces, Layouts, the Launchpad and Notifications are important to merge UI and workflows into UX.
We’ll explore those in Part 2 of this series.
