A product architecture and system design case focused on transforming hotspot creation from a fragmented multi-tool workflow into a unified system inside a B2B SaaS platform.
Product Definition · System Modeling · Workflow Architecture · UX Architecture · Requirements Engineering · Product Strategy
Sirv is a platform for digital asset management and image delivery used across both B2C and B2B scenarios. The hotspot functionality described in this case specifically targets B2B workflows, where teams manage product media at scale for e-commerce and operational use.
As customer needs evolved, many required hotspot functionality to annotate products directly inside spins. However, this functionality did not exist inside Sirv, forcing users to rely on external tools such as Arqspin, WebRotate 360, and AJAX-Zoom. This created a fragmented workflow where users had to move assets between platforms, manage multiple tools, and deal with inconsistencies in output.
The opportunity was not simply to introduce hotspots as a feature, but to eliminate fragmentation and bring the entire workflow into a single controlled system.
My role
I led product definition and interaction architecture for the hotspot editor inside Sirv.
I analyzed competitors and external workflows to identify the product opportunity, architected the integrated system, and aligned key decisions directly with the CEO, who also acted as the product’s CTO. My role covered system modeling, workflow design, edge-case resolution, and preparation of implementation-ready documentation for engineering.
I defined the hotspot system architecture, creation logic, and state behavior across both standard and irregular spins, and translated the solution into structured artifacts including workflows, user stories, acceptance criteria, and technical documentation that enabled development without ambiguity.
Market gap
The competitive landscape showed a clear split. Simpler tools offered ease of use but limited control, while more advanced solutions required technical expertise and external setup. None of the existing tools provided a seamless, integrated workflow inside a media management platform.
This created a gap for a solution that could combine usability, control, and integration within a single system, removing the need for external tools and reducing operational complexity.
Problem
The request to “add hotspots” initially appeared straightforward, but the actual problem was structural.
A 360° spin is a sequence of frames, not a static image. A hotspot is not a point but a behavior that must persist correctly across frames depending on object visibility. This makes placement, tracking, and display inherently complex.
At the same time, users approached the problem with fundamentally different mental models. Some understood frame-based logic and required precision control, while others expected a simple, guided experience.
In addition to this, the system contained ambiguous states, especially during creation, where partial actions could lead to unpredictable outcomes if not explicitly defined.
The deeper issue was that hotspot behavior had no system layer. It depended on manual interpretation rather than defined rules.
Workflow problem
Before integration, users had to rely on multiple tools to complete a single task, moving assets between systems and manually recreating configurations. This introduced friction, increased cost, and slowed down iteration.
The workflow itself was the problem, not just the missing feature.
Workflow logic is composed visually, while configuration and system feedback remain connected to the same authoring surface
Key insight
The problem was not hotspot creation itself, but the absence of a system that could define and control its behavior across fragmented workflows. Without such a layer, hotspot logic remained inconsistent and dependent on user interpretation, making the process unreliable and difficult to scale. This required shifting from feature design to building a controlled authoring system where behavior is governed by product logic rather than manual input.
Solution
I defined the hotspot editor as an integrated authoring system where hotspot behavior is governed by rules, states, and logic rather than manual repetition.
The system is structured around a centralized hotspot library that acts as the main control layer. All actions, including creation, editing, preview, and visibility management, originate from this state, ensuring consistency across the product.
Central hotspot library as the system entry and control layer
Creation is built around a dual-mode model designed to resolve differences in user expertise and spin geometry. Auto mode simplifies placement through algorithm-driven logic, reducing interaction to a minimal number of steps. Manual mode provides full control for irregular or complex scenarios where automation cannot be trusted.
Dual-mode creation system adapting to user expertise and spin complexity
Auto mode is based on a frame calculation model that determines hotspot visibility across the rotation axis. This reduces a multi-frame placement problem to a predictable sequence of actions, shifting complexity from the user to the system. Instead of manually placing hotspots across dozens of frames, users define key points and the system generates consistent behavior.
// Defines the frame range where hotspot remains visible
90 / (360 / x) = frames to left and right of origin
// Where:
90 = degrees of visibility arc (left + right of feature)
360 = full rotation axis
x = total frame count of the spin
// Example: 36-frame spin, pointer on frame 2
90 / (360 / 36) = 9 frames
// Visible range: frame 30 → frame 2 → frame 10Algorithm defining hotspot visibility across frame sequences
Manual mode exists to handle edge cases, including irregular spins, non-standard rotation, and scenarios where precise frame control is required. It removes algorithmic constraints while preserving system consistency.
A critical part of the system was defining explicit rules for all ambiguous states. For example, partially created hotspots, frame navigation, and conflicting inputs were resolved through predefined logic. No state was left undefined, ensuring predictable behavior across all interactions.
The system also includes a preview layer where users can validate hotspot behavior in context before finalizing changes, ensuring correctness at the interaction level.
Preview mode validating hotspot behavior before final use
Key decisions
The system required several non-trivial trade-offs where multiple valid approaches existed, each with different risks.
The first decision was between unrestricted flexibility and system-controlled behavior. A fully flexible model would allow users to place hotspots freely across frames, but this would make behavior inconsistent and difficult to predict, especially for non-technical users. I chose to constrain behavior through system rules and validation, sacrificing some freedom in exchange for consistency and reliability of results.
The second decision was whether to design a single unified creation flow or separate flows for different user types. A single flow would simplify the interface but fail to support both novice users and advanced scenarios. I introduced a dual-mode system instead, accepting additional complexity in the product in order to reduce cognitive load for beginners while preserving precision for experienced users.
The third decision concerned automation versus manual control. A fully manual system would be predictable but slow and cognitively demanding, especially for spins with many frames. A fully automated approach would be efficient but unreliable for irregular cases. I combined both approaches by introducing algorithm-driven placement for standard spins and manual fallback for edge cases, ensuring both speed and control.
Finally, I chose a library-centered architecture over direct editing flows. Editing hotspots directly on spins without a central system would be faster in simple cases but would not scale for management, visibility control, or reuse. By introducing the hotspot library as the main system state, I traded initial simplicity for long-term scalability and consistency.
Implementation
I translated the system into a structured set of artifacts that enabled implementation across product, design, and engineering.
Competitive analysis and workflow mapping defined the product opportunity and system boundaries. CJM and use case mapping defined how different user types interact with hotspot creation and where complexity must be abstracted or exposed.
User journey defining interaction paths and complexity levels
User stories and acceptance criteria formalized system behavior, covering creation flows, state transitions, validation logic, and edge cases. Every interaction was defined as testable behavior rather than interpretation.
System behavior translated into implementation-ready requirements
The architecture defined clear separation between interaction layer, logic layer, and execution behavior, ensuring scalability and integration with the existing platform.
System architecture integrating hotspot editor into the platform
All key decisions and system rules were aligned directly with the CEO, acting as CTO, ensuring feasibility and alignment with platform constraints. Documentation served as a single source of truth for development, eliminating ambiguity during implementation.
Tools
Figma was used to design and iterate on interactive prototypes, including the hotspot editor, creation flows, and system states. FigJam supported workflow mapping and exploration of interaction logic, helping define how users move between library, creation, and preview states.
NotebookLM was used to structure requirements, decompose the system into logical layers, and build a coherent map of artifacts including flows, rules, and dependencies. This allowed the product definition to remain consistent across all stages.
Genspark was used for deep research and competitive analysis, helping identify gaps in existing solutions and validate the product opportunity.
ChatGPT supported validation of system logic, edge cases, and documentation clarity, ensuring consistency across workflows, rules, and decision-making.
Jira was used for cross-functional coordination and decomposition of the system into implementation-ready tasks. Confluence served as the single source of truth for documentation, capturing system behavior, requirements, and constraints for product, engineering, and QA alignment.
Impact
The primary outcome was the elimination of workflow fragmentation. Users could create, manage, and publish hotspots without leaving the platform, reducing reliance on external tools and improving consistency across the media pipeline.
The system reduced complexity, improved usability, and enabled faster iteration, while maintaining control over hotspot behavior across different types of spins. Integrated workflows of this type are known to reduce process time by up to 60–70% and consolidate multiple tools into a single system .
The result was not just a new feature, but a transformation of hotspot creation into a scalable product capability.