The VR Maker marker editor was one of the platform most-used and most-confusing features. Users place interactive markers on panoramic images to add information, navigation, and media to their tours. The legacy editor required users to choose from over 10 marker types upfront — image tag, video tag, note tag, hotspot, info tag, link tag, sticker, and more — each with its own editing interface and capabilities. Users had to understand the taxonomy of marker types before they could create what they needed. If they chose wrong, they had to delete and start over.
The core problem was that the system was organized around technical marker types rather than user intent. A user thinking "I want to show a photo gallery when someone taps here" had to know that this required an image tag specifically. A user wanting to link to an external site had to choose between link tag and hotspot based on subtle differences they did not understand. The redesign needed to flip the mental model from type-first to intent-first, while migrating all existing markers to the new framework without breaking anything.
I deconstructed every marker type to understand what they actually did. I found that all 10+ types were combinations of just three concerns: what appears on the panorama (the marker visual), what happens when you interact with it (the action), and what content it contains. An image tag was really a marker + open-tag action + image content. A hotspot was a marker + switch-scene action + no content. By separating these three layers, I could collapse the entire taxonomy into a composable framework.
I redesigned the editor into three sequential panels. First, Markers: choose what to display on the panorama — an icon from the template library, an uploaded image, or a video — and set its visual style (size, color, and whether it is clickable or searchable). Second, Actions: if the marker is clickable, choose what happens — switch to another panorama, open an embedded URL screen, open a content tag, open the search panel, or play an audio guide. Third, Content: if the action opens a tag, build the content — upload images for a gallery, write a description, add CTA buttons. Most fields are optional; the marker adapts its display based on what the user actually fills in.
The framework uses conditional logic to show only what is relevant. If a marker is set to non-clickable, the action panel never appears. If the action is switch-scene, the content panel never appears. Users only encounter complexity when their intent requires it. A simple directional hotspot takes 15 seconds to create; a rich media tag with gallery, description, and CTA takes a couple of minutes — but both use the same framework.
Every existing marker in the system had to map cleanly to the new framework. I built a compatibility matrix showing how each legacy marker type decomposed into marker + action + content values. This became the migration blueprint for engineering: existing user content transitions automatically with no manual re-editing required. Users open their existing tours and find their markers intact, now editable through the new framework.
Instead of redesigning 10+ marker editors, I decomposed them into three composable layers: visual (marker), behavior (action), and payload (content). This eliminated the need for users to learn a taxonomy and reduced 10+ separate interfaces to one adaptive flow. It also makes the system extensible — adding a new action type does not require a new marker type.
Panels appear only when the previous choice demands it. Non-clickable markers skip the action panel entirely. Scene-switching actions skip content. This progressive disclosure means simple markers are genuinely simple to create, while complex markers guide users through each decision step by step.
Rather than requiring users to fill specific templates per marker type, I made almost every content field optional. The marker tag visually adapts based on what content is provided: add only an image and it shows as a thumbnail; add a description and CTA and it becomes a rich info card.
The marker editor redesign is in development with early user testing showing strong positive reception. The three-panel framework consolidates over 10 legacy marker types into a single, composable editing experience while maintaining full backward compatibility.
This project crystallized a principle I now apply to every legacy redesign: decompose before you redesign. The old marker system was not 10 separate features — it was three concerns tangled together. Once I untangled them, the solution was almost obvious. The hardest part was not designing the new framework; it was building the migration matrix that let existing content transition without breaking. In enterprise product design, the migration strategy IS the design strategy.