In previous articles we covered: io.Connect UX components, user journey mappings, workspace and layout hybrid use. Finally, let’s take a look at a practical role-based example.
A Trader desktop that answers real questions
There are many valid UX approaches for interop-enabled platforms. Different firms, desks, and even teams will optimize for different workflows, constraints, and risk profiles. A reliable way is to start with a role-based recipe: pick one persona, design a coherent environment for their day, and then reuse the pattern across roles.
Why “Trader” is a good stress test
Traders tend to have time-sensitive, high-stakes tasks with constant context switching. Their core questions are rarely “Which app do I open?” and almost always:
- What’s driving the market today?
- Do I have all the data I need before making this call?
- Can I easily see related trades, instruments, or clients?
- I’m seeing unusual volume - is there breaking news I’m missing?
- What are other traders or analysts saying about this stock?
The UX goal here is speed and clarity. One missed update can mean a missed opportunity.
Step 1: Divide the desktop by purpose (so the environment is scannable)
A simple, high-performing pattern is to divide the screen by purpose and make each region predictable. This can be achieved using a layout that saves windows on a multi-screen setup. And the main context driver can be a workspace:
Top row: Market data and charting
Put your “fast scanning” tools on top: price charts, performance indicators, heatmaps, and anything that drives decisions. The important UX move is to let these apps share context, so a single symbol change updates the whole strip. In io.Connect Desktop, Channels are designed for this kind of user-controlled synchronization, and the Channel Selector makes that relationship visible.
Bottom-left: Utilities (Launch/Search/Tools)
Reserve a predictable corner for “starting actions”: global search, launching apps, kicking off workflows, and platform utilities. This is where Launchpad shines because it’s meant to be a central hub for apps, Workspaces, Layouts, notifications, preferences, and global search.
Center: the Main Context Driver
In the middle, place what actually drives the desk’s context - typically the order management/execution surface, a watchlist, positions, and fills. This is the place where the desktop “acts as one”: when the trader changes context here, everything else should follow (charts, news, research, risk, comms).
Left/center-bottom: News & Research
Place streaming news and research adjacent to the main driver so it can be filtered by context (e.g., selected symbol/company). UX-wise, this is where traders validate: “Is there anything I’m missing?”
Right side: Communication + Portfolio/Risk
Keep collaboration and exposure in a stable area: email/chat (e.g., Symphony/Teams) plus portfolio and risk views. Traders need to act fast, but they also need to sanity-check impact. Putting these views in a predictable region reduces “hunt time.”
Step 2: Put the Main Context Driver inside a Workspace (so execution is one cockpit)
Once the outer desktop is divided by purpose, the next UX improvement is to make the execution center a Workspace.
That Workspace serves as a “cockpit” window (Frame) where the key widgets are arranged for the current activity. A practical “Trader Workspace” can look like:
- Top: Market overview widget
- Left: Trade blotter / watchlist / positions
- Center: Analytics, order blotter, portfolio summary, news
- Right: Chat + exposure
- Optional: an assistant panel (for summarizing, navigating, or guided flows based on the interop data you already have)
This keeps the trader’s highest-frequency interactions in one bounded surface, while the rest of the desktop (charts, research, comms, risk) stays purposefully placed around it.
Step 3: Use Window Groups where “move together” beats “merge into one app”
Not everything must belong inside a Workspace. For sets of windows that should behave as a unit (e.g., a cluster of charts, or a news+research pair), Window Groups give you a fast structure: windows move/minimize/maximize together, but remain individually usable. This is especially useful on multi-monitor setups where traders want stability without losing window-level control.
Step 4: Save it as a Layout (so “start of day” is one click)
Once the desktop is arranged (groups + Workspace + Launchpad placement), save it as a Global Layout. This turns your “good setup” into a repeatable state:
- Traders can restore the entire environment with a single click.
- Desks can keep multiple layouts for different modes (market open vs intraday vs end-of-day).
- You can set a default Global Layout to restore on startup for instant readiness.
Layouts also support enterprise patterns such as remote stores and centralized availability.
Step 5: Distribute the baseline (optional, but powerful)
If you use a centralized layout store (for example via io.Manager-backed storage), you can provide a standard baseline layout to users and keep it consistent. This is where role-based UX becomes operational: the trader joins the desktop and starts productive immediately, without spending the start of the day arranging windows.
This is a pattern you can follow. The specific apps and widgets will differ per desk, vendor stack, and workflow. The structure is what matters: divide by purpose, define a main context driver, put execution into a Workspace, group what should move together, and persist the whole environment as a Layout.
Below are some more examples of how you can use the mix of capabilities for certain scenarios in practice.
Recipe 1: Fixed workflow
Let’s say new portfolio managers need approved flows that start fast. Based on the user journey and capabilities mapping, we can use:
- Preconfigured Workspaces
- Launchpad to start the flow
- Predefined data streams
How this translates to platform mechanics
- Use Workspaces as the unified frame and lock down what should not change
- Use Launchpad as the single starting point for apps/workspaces/layouts with global search.
A fixed workflow recipe works best when your users have repeatable, high-frequency tasks and you want the desktop to feel like a guided product experience, not a sandbox. The goal is to remove “setup time” and reduce decision fatigue: users shouldn’t have to remember which apps to open, where to place them, or how to wire context. The key is to treat “fixed” as intentional UX guardrails, not as a hard limitation.
Recipe 2: Exploration + flexibility
If we have power users who iterate and have a multi-monitor setups leverage:
- Multiple saved layouts
- Multi-window support
- Discoverability through Launchpad
Where Layouts do the heavy lifting
- Layouts save/restore desktop arrangement + context.
- Layout store configuration can be local or handled remotely.
Here, the UX win is not “one blessed workflow,” but fast switching between different mental modes: morning scan vs. active execution vs. research vs. review, without forcing users to rebuild their desktop every time.
Recipe 3: Monitoring + quick action
When users often receive signals and need to keep awareness without losing focus, use:
- Sticky windows and Workspaces
- Actionable notifications
- Contextual data, channels
This allows you to:
- Have the sticky windows: “always visible” without making the desktop messy
- Persistent notifications will invoke Interop methods, making the user reaction much faster and intuitive. Notifications can actually start new user flows. E.g. (some AI app says): I’ve found this information on the news and prepared a report for you to review. User clicks on a notification button “View report” and opens a new workspace.
- Channels make it easy to see the data relations
Monitoring-heavy roles (traders, operations, support) often fail with “too much visibility” or “too many interruptions.” The right pattern is a controlled split: keep a small set of windows always visible for situational awareness, and route everything else through lightweight prompts that turn into the next step only when needed. Notifications can include action buttons that invoke Interop methods, so the user’s next click can be a deterministic handoff into the right handling flow rather than a hunt for the right window, turning signals into actions. For high-tempo desks, you can even use the Hotkeys API for registering key combinations and receiving notifications when they’re pressed, regardless of focus.
Recipe 4: Prevent errors
To help prevent errors Platform admins rely on guardrails, confirmations, and reduced degrees of freedom. Use:
- Dialogs for confirmation
- Alerts for state change
- Predefined settings & limited edit rights
To:
- Make it obvious what the workflows are doing. Keep the user in control.
- lock some settings to suspend workspace functionality/hide buttons to prevent unintended modifications
In regulated or high-pressure workflows, we need an environment where the next step is explicit, state changes are observable, and risky actions require deliberate intent. A practical approach is to standardize confirmations and alerts instead of letting every app invent its own modal patterns.
Naming guidelines
Names should reflect the purpose to help users navigate and trust the system.
Here are three practical models:
- Task-based (“Risk Check”, “Pre-Meeting Review”)
- Function-based (“Order Entry”, “Client Lookup”)
- Context-based (“Smith Portfolio”)
A good naming scheme reduces time-to-orient when restoring a Layout, switching between tasks, or collaborating (“open Risk Check and share your screen”). Pick one of the above models as the default and use the others as controlled exceptions, otherwise naming becomes inconsistent.
A persistence guarantee: user-defined names of groups and windows saved in a layout are preserved when the layout is restored.
If you want a deeper dive into a specific concept or flow, tell us what you care about most and I’ll expand on it in detail.