Design insights:how users interact with split-screen in Twin

Understanding how professionals navigate and compare data across multiple 3D and 2D views : and what it teaches us about designing for spatial awareness.

Case Type: User Research & Interaction Design

Tags: Digital Twin, 3D, 2D interation, user research, split screen, split view

Read the insights

Project Context & Role

  • Project: Digital Twins product (for an oil & gas / industrial domain)

  • Time: April 2021

  • Role: Senior UX Designer

  • Responsibility: Own the split-screen / split-view user experience, from concept through hand-off to front-end developers; also research, prototyping, testing, iteration, documenting, and supporting devs.

  • Stakeholders: Developer lead, tech VP, customer solutions team, oil & gas field clients.

  • Deliverables: Sketches, UX research artifacts, prototype, usability testing, documentation.

Because of confidentiality, all the screens shown are remade; layout and flows are preserved but sensitive data is removed.

Problem / Use Cases

In a “Simultaneous Operations” workflow within the digital twins platform, users start in a 3D map view.

1. They can search or find a task in a table and right-click to open documents or info graph views.

  • The issue: when a document view is opened, an info graph view also opens, and both take over the screen as a split view. But when users open only the info graph view (without document), the behavior is inconsistent.

2. To return to 3D view, users had to close both document & graph views—there was no clear path back.

  • This inconsistent behavior led users to feel lost and frustrated.

So the UX problem is that the split view behavior is not predictable or consistent, the flow of opening/closing is confusing, and users struggle to understand how to navigate back.

User & Persona

Persona: “IOC operator” — someone working in control rooms, monitoring operations, needing visibility over tasks, alerts, documents, relationships between objects, etc.

User flow & needs:

  1. First glance / overview: See a clear, unobstructed view of the control room or operations.
  2. Arriving at terminal: Identify tasks, get personalized info, drill into details.
  3. Routine work: Observe multiple data views, prioritize tasks, dig into relationships and documents.
  4. Meetings / planning: Bring together relevant documents, notifications, history, annotations, layering information.

Key pain points discovered via UX research / feedback sessions:

  • Landing in 3D view by default is not useful when the user doesn’t know what to search yet.
  • Split view opens in unpredictable ways.
  • The flow has dead-ends; users often lose track or can’t find their way back.
  • Users want control: “show me what I ask for, allow me to hide it, and bring it back easily.”

User interview

I conducted interviews with IOC opreator user to understand how they manage multiple views in their daily work. Their feedback highlighted the need to maintain visual context and control over visible screens, which directly informed the split-screen design.

We also held several user journey discussions to better understand how people moved through the system in real scenarios. These conversations helped us identify key moments of friction, clarify user goals, and uncover the context behind their actions. By mapping these journeys, we could align the split-screen behavior with how users actually think and work, rather than how we assumed they would.

Goals & Design Questions

Goal statement: Let users assign relevant views in split screen in a way that supports their workflow. Make split screen behavior consistent, clear, and easy.

Design questions included:

  1. Must graph view always accompany document view?
  2. Can the flow for opening / assigning split views be smoother?
  3. How to reduce visual confusion?
  4. How important is 3D view to the user?
  5. What are the consistent rules for assigning windows to splits?

Design Process & Iteration

Mind mapping

At this point, I was curious about how others had already solved the problem of split views. I started by looking at familiar systems — Apple’s split window, Microsoft’s window snapping — and paid close attention to how they handled opening, resizing, and switching between views. I didn’t just study the patterns; I tried them out myself, clicking around, dragging windows, and noticing where the interactions felt natural and where they felt clunky. This hands-on exploration gave me a clearer sense of what “smooth” should feel like, and it helped shape my own expectations for what the split-screen experience in our product ought to deliver

iPad Split view
Courtesy of Microsoft
Photograph: Apple
Courtesy of Microsoft
Photograph: Apple

Sketch / concept iteration

With some reference points in mind, I began sketching out how split views could actually work in our product. My first idea was simple: every new view would just slide into the right-hand side. It sounded neat, but once I played it out with more than two views, it quickly became confusing — the “important” window often ended up tucked away, and users could easily lose track of where they were.

So I tried a different approach, in second idea, taking inspiration from iOS split behaviors. What if the most recently opened view — usually the one the user cares most about , shifted into the primary space, closer to the center or left? That way, emphasis naturally followed the user’s attention.

From there, I explored how to give people more control. Tabs seemed like a natural solution: by clicking a tab, users could decide whether that view should take the left side, the right side, or expand into full screen. To keep things flexible, I designed the 3D view so that when it was brought back to full screen, all other views would neatly collapse into tabs rather than disappear entirely. And to avoid leaving panes blank, I added empty states that offered shortcuts — little reminders of what could be opened next.

Prototype & test with developers

Once the sketches felt coherent, I worked with the developers to bring the ideas to life in a quick prototype. We hooked it up with both front-end and back-end so we could test how the split behavior actually felt in use.

It wasn’t just about proving the concept , the prototype also opened up conversations about trade-offs. For example, how many icons and tool panels could we show before the screen felt cluttered? How do we preserve valuable space when several views are open at once?

Not every detail made it into this case study, but those discussions were essential. They reminded me that design isn’t only about what looks good on paper — it’s about finding the right balance between clarity, usability, and technical feasibility

Step 1: user land in 3D view, on the search result find the tag they want to see and right click open context menu.

Step 2: From the context menu, the user selects the view they want to open — in this case, the graph view. The system automatically assigns it to the left side, positioning it close to where the user made the selection. This keeps the visual information anchored near the original action, reducing cognitive load and making the transition feel natural.

Step 3: When the user chooses to open a document, the system assigns this new view to the center — following the same rule as in Step 2. The previously opened graph view is then shifted to the right, making space for the document in the primary position. At the same time, the 3D view is minimized into a tab, so it remains accessible without cluttering the workspace.
If click 3D tab, it will have 3 options: open to the right , open to the left , or open as full screen.

Step 4: Building on Step 3, if the user chooses to open the 3D view on the left side, the previous screens are pushed toward the right.

During testing, however, I uncovered a major flaw in this design. My initial assumption was that the interface should always preserve a strict hierarchy: the most important view stays in the center, while secondary views get pushed to the right. In practice, users behaved differently. They often preferred to replace the less important view — in this case, the document — while keeping the graph view visible. Unfortunately, in our prototype, the graph view was hidden instead, which caused confusion and frustration.

 

We quickly iterated on the design to better match user expectations. Instead of enforcing a fixed hierarchy, we allowed users to choose which screen to replace. The selected view would be swapped in, while the replaced one was minimized into a tab so it stayed accessible. We tested this approach with users again and also introduced an empty state for workflows where two split-screen areas were set as the default.  

Documentation & Learning

To wrap up, I documented not only how the split layouts functioned, but also the reasoning behind them. The core idea was simple: give users control. Split layouts allow them to toggle the visibility of components, assign views to different areas, and manage their limited screen space more effectively. Depending on the workflow, splits could be vertical or horizontal, making the layout flexible enough to adapt to different contexts.

  • rationale:

    • Split layouts let users toggle component visibility, allocate views, and manage screen real estate.

    • Splits can be vertical or horizontal depending on the use case.

I collaborated with developers to create clear documentation for internal users, adding visual references to make the instructions easier to understand and follow.

Key Takeaways

Looking back, there were several key lessons from this process:

    • Collaboration mattered as much as the design itself, a concept that looked elegant in Figma still had to be feasible for developers to implement and acceptable to stakeholders.
    • Vision needed to be balanced with reality. Technical constraints and resource limits sometimes meant choosing the practical path over the ideal.
    • The most important UX decisions often happened at the component and flow level, not in glossy visuals.
    • In a fast-paced, agile setting, “quick and dirty” prototypes were invaluable for sparking conversations and moving the design forward.
    • Simplicity was a strength. In a complex industrial product, the principle of K.I.S.S. (“keep it simple, stupid”) turned out to be the best guide.

    • Through user testing and interviews, combined with continuous feedback from product owners, domain experts, and stakeholders, we were able to keep the design grounded in real user needs and practical workflows.

Follow more on

Object-Oriented UX (OOUX) for digital twins: insights to support scalable 3D view

 

Read Full Case Study

Making 3D usable: OOUX finding from isolate & highlight features

Read Full Case Study

Designing SaaS for digital twin: how discovery shaped the solution

Read Full Case Study
(47) 41 33 16 51

Reach Me By Phone

contact@yutingchuang.com

Email Me

Rølivegen 367, Steinkjer, 7718, Trøndelag

📍 Based in Norway