Part 1 — VIVERSE for Business: Core Journeys
A Two-Part Story
VIVERSE for Business is a large-scale enterprise VR platform with complex workflows, diverse user roles, and strict access controls. I led the UX design from zero to launch, balancing customer needs, technical feasibility, and business goals under tight timelines.
To show the breadth and depth of the work, this case study is split into two parts:
Part 1 covers core user journeys that define how people enter, navigate, and communicate.
Part 2 focuses on in-meeting collaboration tools, accessibility, and design system development.
Together, they tell a single story of solving high-stakes design problems in a fast-changing environment.
Company:
VIVERSE
Role:
Lead UX Designer
Year:
May 2022 - Nov 2024
Designing entry, navigation, and communication for enterprise VR.
Our team
2
UX&UI Designers
1
Visual Designer
25
Developers
6
Quality Control
Overview
Me and another UX designer Irma designed the foundational experiences for VIVERSE for Business, ensuring users could enter meetings, move through virtual spaces, and communicate with colleagues intuitively—without VR-specific skills. The goal was to translate complex enterprise requirements into seamless, role-based behaviors.
Before we start the design, I did a product comparison with Microsoft Mesh, including the feature specification, website landing page, and SWOT
The Problem
I started this product from scratch. The problem was to clarify the complex requirements and discover what enterprises truly needed—without direct customer contact—relying only on the product manager’s input. I had to transform these requirements into intuitive operational behaviors, such as defining roles and permission rules, entry/exit protocols, and navigation standards.
The 4 quadrants help us to split the phases, based on the requirement discussion with the product and the engineering manager.
Based on the urgent and important quadrants, the product manager, the engineering manager, and I have agreed on the draft release plan.
Wait, so how I estimate the design timeline based on it?
The actual design timeline is essentially the launch date minus the time needed for development and testing — which becomes the window for design work. In reality, that only gave us about 1.5 months, which wasn’t enough to build from scratch.
What? Do I work crazy hours and watch the sunrise every day?
Not exactly, it's about overtime, 3 to 4 hours a week. But if we see it as a waterfall workflow, yes, it is insane.
Since I've been facing similar situation many times, what we did was to shift to a partial release approach: finalizing and handing off some components early so engineering could start in parallel.
Challenge
We needed to design for multiple user roles (hosts, guests, space owners) in a 3D environment, all while working with evolving technical constraints. The product’s scope was broad, timelines were tight, and team members left mid-project.
Before designing the user flow, I mapped out the relationship between roles and spaces to understand the logic of room entry permissions
Ideation of early stage
Solution
I focused on designing workflows that set clear user expectations, aligned with enterprise policies, and reduced confusion. Let's go through it:
Entering/Leaving Meeting Rooms – Defined role-based entry permissions, arrival points, and leaving behaviors. The requirement document simply stated that users should be able to enter and leave the space, but it didn’t explain the details — such as where users go after leaving, how the experience might differ depending on their role, or what permissions are needed to enter.
To fill these gaps, I initiated a series of discussions with the product manager. Together, we mapped out the capabilities of each role, clarified the purpose of each space, and identified potential limitations and error cases we needed to prepare for.
In the virtual world, users can go anywhere without "walking"; they can just open the portal and transfer.
Scheduling, Editing, and Canceling Meetings – Streamlined calendar integration and made the interface simple for both VR and non-VR participants.
The use case shows how to create a meeting from the Calendar.
The create meeting flow is unlike most online meeting flows. Since it's a virtual world, it is better if users know where they want to host and the room capacity.
Not just the interaction and experience. Due to the designer shortage, I was also responsible for some of the UI design.
Checking Schedules – Through menus, users can check their personal schedule and select the meeting or event they want to join without leaving the meeting room.
When personal calendar is connect to the VR platform, users can reduce to switch back and forth between computers and VR devices, making the experience more consistent and reducing usage difficulties.
Open Calendar to check the meeting schedule in VR.
Map Navigation – This multi-functional map, given the businesses have access to multiple virtual buildings and spaces in their premium plans, allows users to not only view their current location but also switch between buildings for quick travel.
I also add the occupancy status of each meeting room, indicating which spaces are available.
Private Talk – Enabled one-on-one audio calls within VR without leaving the shared space, respecting privacy boundaries.
User can call someone else by selecting from the Space management or from the Nameplate card.
Chats – Combined text, voice calls, and quick reactions in a single accessible interface for real-time and async communication.
This is a late-production feature. We've noticed that users often ignore messages from colleagues while in the VR world (immersively), often having to take off their VR headsets to check every in a while. Eventually, we hope to add a feature that allows users to connect with colleagues even in VR without switching between devices, you can message to colleagues when using the product.
The Key Takeaway
In Part 1, I learned how to distill ambiguous, second-hand requirements into clear, testable design flows by developing detailed user flows based on inferred needs and validating with key stakeholders.
By grounding decisions in role-based rules and predictable behaviors, I created a foundation that scaled across multiple enterprise scenarios. The experience reinforced my adaptability and ability to deliver clarity from complexity.
Partnership with
