Founding Product Design Lead · Interaction design · Design systems · Front-end implementation
Established a coherent model for review, markup, discussion, snapshots, Stories, and role-aware external collaboration around the 3D object itself.
Vertex had to prove secure, reliable cloud collaboration around huge 3D assemblies while protecting sensitive IP and supporting both CAD specialists and external partners.
Shipped the MVP for real-time model review and annotation, making collaboration more accessible to non-CAD specialists and reducing dependence on separate tools. Core patterns carried into later product development.
Vertex was building a cloud platform for reviewing and collaborating on large 3D models. The central challenge was giving distributed engineering teams enough shared context to keep changes, markup, and decisions connected to the model itself.
The product needed a collaboration model that worked around the 3D object itself.
- Symptoms: Review and feedback spanned multiple tools, making shared context and decisions harder to carry across teams and vendors.
- Root causes: Collaboration depended on exports and workarounds instead of shared context anchored to the model.
- Constraints: Large-model performance limits and strict security and IP protection requirements.
- Result: Collaboration needed to stay connected at the moments of review and feedback when decisions were being made.
Engineering teams relied on complex 3D assemblies to make critical decisions, but collaboration broke down during review and feedback.
Teams shared large files through existing tools, emailed screenshots, or relied on meetings to explain changes that were hard to reference later. Feedback lived outside the model context, forcing people to translate intent across tools and viewpoints.
The opportunity was to support faster decisions and stronger shared understanding across teams and vendors.
Collaboration Was the Missing Layer
Most existing tools were optimized for individual authoring. Shared decisions happened through separate meetings, screenshots, and documents.Opening full assemblies could take significant time even on high-end machines, and stakeholders who only needed to review still had to load entire models.
Vendors and non-engineering partners often worked with more limited access, which made it harder to keep 3D context intact across handoffs. The product opportunity was to bring those collaborators into the same review flow.
Creating Shared Context
The initial request centered on collaboration features. Discovery showed the deeper issue was shared context. Teams needed a way to build shared understanding around complex systems while allowing people to keep the tools, workflows, and performance profiles that fit their role.
Any solution had to reconcile:
- High-fidelity 3D complexity with lightweight interaction
- Fast iteration with enterprise-grade security
- Individual workflows with shared decision-making
A shared collaboration layer could speed decisions, strengthen shared understanding, and give teams more deliberate control over sensitive data.
Most importantly, Without it, the barrier to enterprise adoption would stay too high for the platform to scale. This made shared context a product-level collaboration challenge with direct implications for speed, trust, and adoption.
Working in a stealth startup, I combined empathy mapping, workflow analysis, competitive review, and close work with product and engineering to understand how engineering teams exchanged design feedback.
The recurring need was shared context: people had to know what part of a model someone meant, what changed, and what action was expected.
Empathy mapping helped make the different collaboration needs, pressures, and handoffs across engineering roles visible.
Early discovery focused on building a shared understanding of how engineers actually collaborated around 3D models.
I worked closely with product, engineering, and an experienced design engineer SME to synthesize domain knowledge across end-to-end design and manufacturing workflows, collaboration handoffs between OEMs and suppliers, and the realities of security, performance, and tooling in enterprise environments.
This work was less about validating a single hypothesis and more about building confidence before committing to a specific interaction model.
To move from ambiguity to direction, I facilitated a focused design sprint with product, engineering, and the SME.
The sprint helped the team:
- Map OEM and supplier perspectives separately
- Identify where collaboration broke down across review, feedback, and iteration
- Explore multiple collaboration concepts quickly
- Translate the strongest directions into low-fidelity flows for discussion and refinement
This created alignment across disciplines and established a concrete starting point for experience design grounded in domain reality rather than assumption.
In parallel, I reviewed both direct CAD tools and adjacent collaboration paradigms to understand where existing solutions succeeded and where they fell short.
This included CAD platforms such as Inventor, Fusion 360, Onshape, JT2Go, and CADX, alongside adjacent paradigms such as PowerPoint, photo markup tools, GitHub, Basecamp, and InVision / Axure.
We kept full CAD authoring out of scope and focused on the collaboration layer: where work broke down, which familiar patterns already worked, and which could be adapted safely.
The pattern was consistent: collaboration happened around the model through screenshots, static documents, and separate conversations. The opportunity was to bring those into a shared workspace around the model.
Across discovery, several insights became clear:
- Collaboration broke down during review and feedback
- Security and performance shaped behavior as much as usability
- Different roles needed different views of the same model
- Existing tools centered individual workflows while collaboration context stayed spread across the surrounding process
These findings directly shaped the interaction model and platform direction that followed.
I defined the interaction model around model state, viewpoint, selection, markup, discussion, and handoff. A design sprint helped turn those ideas into a product direction the team could build against.
That gave product and engineering a common model for how a cloud 3D review session should behave.
Discovery showed the core need was shared context during review and feedback.
Teams often exported models, captured static screenshots, and reconciled feedback across separate tools. Keeping that feedback connected to the 3D context could make decisions faster and collaboration clearer, especially with external suppliers.
The strategy was to anchor collaboration to the model so discussion, context, and decisions stayed connected to the work. The goal became designing a system that supported shared understanding across roles, disciplines, and access boundaries.
- Goal: Keep discussion, context, and decisions anchored to the model.
- Inputs: Large CAD assemblies, enterprise security constraints.
- Core interactions: View, isolate, measure, annotate, compare.
- Collaboration layer: Comments, mentions, review states.
- Governance: Permissions, sharing, auditability.
Collaboration in 3D is mediated through 2D inputs, while meaning lives in a spatial environment that changes with camera angle, zoom, and orientation. There is no single stable surface, so feedback can lose intent over time.
The challenge is compounded by role differences across engineers, reviewers, and external partners. Collaboration patterns therefore had to bind 2D input to 3D context while remaining understandable across audiences and over time.
The strategy was guided by four goals:
- Keep context attached to feedback
Comments and annotations needed to stay anchored to specific views, parts, or moments in the model. - Support meaningful collaboration with role-aware protection for sensitive IP
Suppliers and external partners needed meaningful participation with access scoped to the data relevant to their work. - Balance power with approachability
Engineers needed depth and control, while other collaborators needed lightweight ways to engage with the model. - Enable both synchronous and asynchronous workflows
Teams needed to collaborate live when necessary and leave structured feedback that could be reviewed later.
These goals provided clear guardrails for experience design and prevented the solution from drifting toward familiar but ineffective patterns.
Working within a stealth startup environment required focus and restraint.
The strategy prioritized:
- Core collaboration workflows over exhaustive feature parity
- Flexible interaction models over rigid processes
- A clear interaction system before deeper edge-case optimization
That gave the team enough structure to keep building while technical and organizational constraints were still changing.
I designed the core review workflows from zero to one: navigating the model, capturing a viewpoint, marking up geometry, starting discussions, and returning collaborators to the same context later.
The goal was to make 3D collaboration understandable to people who already knew engineering workflows while keeping communication itself simple and lightweight.
Core interaction design for reviewing a 3D model while keeping markup and discussion tied to the model context.
With the strategy defined, the focus shifted to designing collaboration around complex 3D assemblies while keeping performance, security, and clarity intact.
I focused on a common interaction model for exploration, discussion, and decision-making across roles and contexts. That gave the team patterns it could reuse as new workflows were added.
Designing Collaborative Workflows
Early design work centered on how users collaborated around models and how they inspected them.
The experience was structured around three core activities:
- Explore: Navigate and inspect large assemblies efficiently
- Collaborate: Share, comment, annotate, and discuss specific parts in context
- Present: Capture, sequence, and communicate insights directly around the model
This kept interaction decisions grounded in real workflows and away from tool-centric patterns.
To support these workflows, I designed a system that separated model interaction, commentary, and narrative storytelling while keeping them tightly connected.
Key design decisions included:
- A persistent 3D model viewer as the shared source of truth
- Contextual commenting anchored to parts, views, or snapshots
- Lightweight markup tools that did not alter the underlying model
- A clear distinction between working sessions and curated stories
This allowed teams to move fluidly between exploration and communication while keeping the work and its context together.
One of the most important concepts was Stories, a way to curate and communicate decisions.
Stories allowed users to:
- Capture snapshots of relevant model states
- Annotate and draw directly on those views
- Sequence snapshots into a narrative
- Discuss changes asynchronously through lightweight snapshot views
This reduced reliance on external tools and made collaboration more accessible to non-CAD specialists while preserving engineering accuracy.
To support synchronous work, the experience included lightweight collaboration features that mirrored how teams already worked together.
These included:
- Inviting users directly into a shared model
- Following another participant’s view during walkthroughs
- Screen sharing for live reviews directly from the shared workspace
The goal was to make model-based collaboration faster and more precise while letting meeting tools handle the meeting itself.
Throughout execution, I iterated closely with product and engineering to balance usability, performance, and feasibility.
This included:
- Refining interaction density to avoid visual overload
- Adjusting tool placement based on usage patterns
- Stress-testing workflows with large, complex assemblies
The result was an experience that remained responsive and understandable under heavy technical constraints.
Validation came through internal design and engineering review, QA collaboration, directional feedback from design and engineering practitioners at mHUB, and moderated usability work as the product matured.
The feedback refined the interaction patterns and gave the team evidence that the core collaboration model was understandable enough to keep building.
Directional feedback at mHUB helped test the core interaction patterns with design and engineering practitioners.
With the core interaction model, collaboration workflows, and system structure in place, validation focused on how well the experience aligned with real-world engineering collaboration needs and fit existing design processes.
Validation occurred across two tracks: internal stakeholder review and external directional exposure.
Concepts and flows were reviewed iteratively with product leadership, engineering partners, and a senior design engineer SME with deep CAD and manufacturing experience.
These reviews focused on:
- Whether the collaboration model reflected real design-review behavior
- Feasibility of real-time and asynchronous workflows
- Alignment with CAD/PLM constraints and enterprise security requirements
- Clarity of roles, permissions, and ownership in shared models
Feedback confirmed that the shared-context approach, including snapshots, stories, markup, and role-aware collaboration, mapped well to existing workflows while making collaboration easier than file-based handoffs and separate tools. Validation refined the details and confirmed the core interaction model.
To test early concepts outside the immediate team, selected designs were shared in facilitated sessions at mHUB with design and engineering practitioners experienced in complex systems and collaborative workflows.
These sessions provided directional validation for:
- Stories as a shared communication layer
- Snapshots for focused, contextual feedback
- Real-time collaboration and follow-view interactions
- The balance between visual fidelity and lightweight participation
Feedback was largely affirming, with minor refinements to labeling, affordances, and interaction clarity while the core system structure remained intact.
The reviews confirmed:
- Core review and feedback patterns aligned with familiar engineering workflows
- Roles, permissions, and model context were understandable during review
- Stories, snapshots, and markup kept feedback anchored to the 3D model and its state
- Most changes were refinements to labels, affordances, and interaction clarity
Together, the feedback supported continuing with the core collaboration model.
mHUB sessions with design and engineering practitioners provided directional feedback that tested the collaboration model while the startup was still operating in stealth.
The work established Vertex’s first interaction patterns for viewing, markup, discussion, and shared context. Those patterns carried into later product development as the company evolved.
In a 0→1 technical product, defining the interaction language early can give Product and Engineering something concrete to make decisions against before there is enough usage data to optimize.
Building the startup's first design system close to the code
As Vertex's founding product designer, I created the initial design system in Sketch while the product itself was still taking shape. That gave the stealth startup a reusable set of visual and interaction patterns so new screens could build on the same language as the product evolved.
I also had the React front-end environment running locally on my machine. I implemented UI styling in CSS, made limited React changes when needed, and submitted my own pull requests. That level of implementation fluency let me stay close to how the system behaved in production, reduce translation loss, and work directly with Engineering while keeping my primary role focused on product design.
That implementation mindset extended beyond the application UI. I also built product emails and tested them in Email on Acid across email clients, treating consistency across delivery environments as another part of the experience rather than a handoff detail.
How I'd approach this work with AI today
I was Vertex's only designer for the first year, so I was defining the interaction model and the beginnings of the design system while also working directly in the React codebase.
Today I'd make that system useful to both the team and the AI tools we work with. I'd document the tokens, component behavior, interaction patterns and product rules so a tool like Cursor has the same context we do. Then I'd use AI-assisted coding to get complex interactions into working prototypes earlier and help new work stay aligned with the system as it evolves.
My role would be to own the interaction model, the rules and exceptions behind it, and the quality bar for what ships.
- Enabled teams to collaborate on complex 3D models while moving beyond file-based workflows
- Made reviewing, annotating, and iterating easier across roles with different levels of technical expertise
- Improved clarity and confidence in shared decision-making by making model state, context, and intent more visible to collaborators
- Established reusable interaction patterns for real-time collaboration that could support future features within a coherent experience
- Reduced ambiguity across product, design, and engineering by aligning teams around shared system models and interaction rules
- Improved delivery velocity by identifying constraints early and designing within technical realities rather than around them
Designing collaboration systems requires treating shared understanding as a first-class design outcome.
In this environment, success depended less on visual polish and more on:
- Defining clear interaction contracts between users and the system
- Making system state explicit so interpretation stays consistent across handoffs
- Balancing user needs, performance constraints, engineering feasibility, and edge-case behavior
The project taught me to define shared context, system state, and tradeoffs early. Those decisions mattered more as the product and the number of collaborators grew.
