B2B AIaaS · Enterprise SaaS
Vyin AI Platform Architecture Reboot
Turning fragmented AI capabilities into a clearer, scalable enterprise platform foundation.
Move Vyin AI from a collection of technical capabilities toward a clearer enterprise-facing platform. By synthesizing fragmented product and usability issues, we defined the relationships between the platform, AI applications, tenants, permissions, and cross-app workflows, then translated those definitions into V1 product decisions and implementation-ready experience systems.
Industry
B2B AIaaS · Enterprise SaaS
Role
Product Designer / UX Architect
Scope
Team
Duration
9 Months
01 · Context and Challenge
Four Product Problems Behind the Fragmented POC
Vyin AI began as a technical proof of concept for multiple AI capabilities. The models and backend services worked, but the product had not yet been structured into an enterprise platform that users could understand, navigate, and operate. We reframed the challenge around four distinct product domains rather than a collection of screen-level inconsistencies.
Central challenge
01
Platform model — How should users understand, discover, access, and move between AI applications?
02
Enterprise operating model — How should tenants, workspaces, roles, permissions, and shared resources work together?
03
AI workflow and trust — How should users understand progress, review requirements, available actions, and authorization?
04
Application creation and publishing — How should users apply AI models to business workflows without overbuilding editing flexibility?
Challenge 01
Platform Model Ambiguity
Users could not tell whether Vyin was a marketplace, an app-management hub, or an operating layer—or how discovery, access, ownership, and switching fit together.
Challenge 02
Enterprise Operating Model Complexity
Tenant, workspace, account, role, permission, resource, and app-access concepts were distributed across the product, forcing users to infer the operating model.
Challenge 03
AI Workflow and Trust Gaps
Training, processing, review, publishing, failure, adjustment, and authorization lacked visible states, available actions, and recovery paths.
Challenge 04
Application Creation and Publishing Complexity
The Web Application Module risked becoming a flexible website builder before the core workflow—applying AI models to structured business scenarios—was clear.
Team context
At the time, the team did not have a dedicated Product Manager or frontend engineering capacity covering the full product-definition layer. The design team therefore contributed to early product structuring, issue synthesis, UX definitions, V1 direction, optimization concepts, and implementation-ready delivery. My role was to help clarify and translate these decisions with the team—not to claim independent ownership of the business strategy.
02 · Experience Audit and Synthesis
From 43 Experience Gaps to Four Product Domains
To understand why the POC felt fragmented, we reviewed the existing platform against Nielsen’s usability heuristics and documented 43 observable gaps. These were audit findings—not user-interview evidence or post-launch outcomes. We grouped repeated symptoms into seven issue clusters, then translated those clusters into four mutually distinct product domains and a cross-cutting onboarding journey.
What the audit surfaced most often
43
All 43 gaps were mapped to Nielsen’s usability heuristics. The distribution below shows where issues appeared most often; it is diagnostic evidence, not a measure of user impact.
Consistency & Standards — 35% (15 items)
Visibility of System Status — 20% (9 items)
Efficiency & Flexibility — 16% (7 items)
User Control & Freedom — 14% (6 items)
01
43 Observable Experience Gaps
Documented across the existing platform through a heuristic evaluation.
02
7 Issue Clusters
Grouped repeated symptoms by affinity and likely root cause—not by individual screen.
03
4 Product Domains
Collapsed the issue clusters into four distinct product problem areas that could guide decisions and ownership.
04
Decision Criteria
Compared options through comprehension cost, workflow continuity, V1 feasibility, and future extensibility.
05
V1 Product Decisions
Used those definitions to set V1 scope, constraints, and product trade-offs.
06
Experience-System Concepts
Translated the decisions into connected concepts that product and engineering could implement.
Platform model
Enterprise operating model
AI workflow and trust
Application creation and publishing
Cross-cutting journey · Onboarding and activation
The synthesis separated four product domains so each downstream decision had a clear source. Onboarding remained a cross-cutting journey because activation depended on the platform model, enterprise setup, AI workflow, and application publishing working together.
03 · UX Definition
Defining Four Product Domains Before Designing Screens
The audit did not lead directly to interface design. We translated the seven issue clusters into four product domains, each responsible for a different structural question. This gave product, design, and engineering one shared model for discussing V1 scope before committing to detailed screens.
Onboarding was treated as a cross-cutting journey through all four domains—not as a fifth, competing product category.
Topic 01
Platform Model and App Access
How should users understand the platform’s role and the relationship between application discovery, ownership, access states, commercial entry points, and cross-app switching?
Topic 02
Enterprise Operating Model
How should tenants, workspaces, accounts, members, roles, permissions, shared resources, app access, and quota fit into one understandable system?
Topic 03
AI Workflow and Trust
How should the product expose processing states, progress, review requirements, available actions, failure recovery, authorization, and security signals?
Topic 04
Application Creation and Publishing
How should users apply AI models through structured templates and publishing safeguards without turning V1 into an unrestricted website builder?
PLACEHOLDER
STRATEGY FRAMEWORK
FULL WIDTH · 16:9
01
Platform foundation
02
Shared experience layer
03
AI applications
04 · Product Decision 01
Build One Platform Model Before Optimizing App Independence
The first decision combined discovery, ownership, access states, commercial entry points, and app switching into one platform-model question. We compared independent app experiences with an integrated platform model across comprehension cost, task continuity, implementation cost, scalability, and V1 clarity.
Option A
Independent App Experiences
Advantages — focused professional tasks; more room for independent evolution; suited to mature applications. Costs — higher switching cost; fragmented task context; more navigation and state-management complexity; weaker early platform coherence.
Option B · Proposed for V1
Integrated Platform Model
Advantages — one understandable platform model; less context loss; shared data, navigation, and tenant context; lower V1 consistency cost. Costs — less application independence; possible future constraints; requires a coherent platform interaction model.
Decision
For V1, we proposed one integrated platform model.
A shared hub and consistent application states would help users understand what they could discover, access, subscribe to, and use without losing context between applications. Individual applications could become more independent once their workflows, demand, and maturity justified the additional complexity.
Clarify the product model before maximizing application independence.
05 · Product Decisions 02–04
Three Decisions Completed the V1 Direction
With the platform model defined, the remaining domains required three explicit decisions: how AI workflows would communicate trust, how application creation would remain focused, and how enterprise permissions would match V1 maturity.
Decision 02
Make AI Workflow States Explicit, Not Implicit
Training, processing, review, approval, publishing, failure, retry, and authorization had to be treated as product states—not hidden backend conditions. Each state needed to explain what was happening, what the user could do, and what would happen next.
Direction — expose progress, review requirements, available actions, failure recovery, and authorization signals even when the underlying AI process remained complex.
Trust requires visible state, control, and next actions.
Decision 03
Prioritize AI Application Over Website-Building Flexibility
The Web Application Module could have evolved into a highly flexible website editor. However, the product’s core value was helping users apply AI models to business scenarios quickly and reliably. We therefore proposed a constrained, section-based, template-oriented editor.
Trade-off — less layout freedom, fewer typography and styling options, and more controlled page structures in exchange for lower learning cost, faster first-time completion, more predictable output, lower development complexity, and less long-term technical debt.
Do not overbuild editing flexibility before the core product value is validated.
Decision 04
Start With Default Roles Instead of Custom Permissions
A highly configurable enterprise permission system could support more use cases, but it would also introduce significant complexity across the platform and individual applications. Because V1 functionality was not yet deep enough to justify that model, we proposed starting with default roles and clearer access boundaries.
Trade-off — reduced short-term flexibility in exchange for a system that was easier to understand, faster to implement, and safer to extend later.
Match permission complexity to product maturity.
06 · V1 Experience System
Translating Four Product Decisions Into Three Experience Systems
The four product decisions were translated into three connected experience systems. Decisions 01 and 04 converged in Platform Foundation; Decision 02 became AI Workflow; Decision 03 shaped Application Creation and Operation. Onboarding crossed all three as the activation journey.
Platform Foundation
AI Workflow
Application Creation and Operation
System 01
A shared foundation combining the platform model with the enterprise operating model: where users were, which tenant and application they were operating in, what they could access, and how they could move across the platform.
— Global navigation and page hierarchy
— App identity, entry points, and access states
— Multi-tenant platform and workspace logic
— Member and role management
— Default permission roles
— Shared usage and quota visibility
— Onboarding from registration to the first AI task
System 02
AI Workflow
A clearer operational model for AI creation and processing, replacing black-box behavior with visible states, progress feedback, available actions, review requirements, and authorization signals.
— Draft, training, processing, and failed states
— Review required, approved, and published states
— Adjustment and retry actions
— Model authorization, voice watermark, and security signals
— Clear next actions by state
System 03
Application Creation and Operation
A constrained way to connect AI capabilities to business tasks through structured templates, model application, publishing safeguards, and clear operational boundaries.
— Section-based templates
— AI model application
— One-person editing occupancy
— Unsaved-work protection
— Publishing states and free-plan usage limits
Draft
Training
Processing
Review Required
Approved
Published
Failed
Adjustment Available
PLACEHOLDER
DETAIL ZOOM
AI WORKFLOW STATE
07 · Delivery and Enablement
Turning Product Decisions Into an Implementation Model
Each deliverable traced back to one of the four product decisions. The work translated shared definitions into platform structures, user flows, interaction states, reusable patterns, and implementation-ready specifications.
Key flows and state logic
Multi-tenant and permission concepts
AI model-state definitions
Web Application Module concepts
Onboarding logic
V1 functional planning
Design System foundations
Design Guidelines
UI/UX Specifications
What this enabled
A Shared Foundation for Product and Engineering
The work created a shared reference for discussing platform and application relationships, tenant and permission logic, AI workflow states, V1 constraints, and implementation decisions. This is a qualitative outcome, not measured post-launch impact.
PLACEHOLDER
UX SPECIFICATION
LANDSCAPE
STATE LOGIC
HANDOFF
08 · Measurement Direction
Measurement Direction — Not Post-Launch Results
User-Level Activation
01 → Registration or Login
02 → First App Entry
03 → First AI Model Started
04 → First AI Model Completed
05 → Model Applied to Web Module
06 → First Page Published
Tenant-Level Setup
01 → Tenant Created
02 → Member Invited
03 → Role Assigned
04 → App Access Configured
05 → Usage or Quota Reviewed
09 · Reflection
The Most Valuable Work Was Defining What the Product Needed to Be
This project reinforced that early AI-product problems often sit beneath individual interfaces. The work became valuable when observable UI symptoms were traced to product-model, operating-model, workflow, and application-design decisions.
Product design created value by connecting evidence, decisions, and implementation.
Diagnose structural causes, not screen symptoms
Make expensive decisions explicit early
Use constraints to protect V1 product value
Translate definitions into implementable systems
What I would validate next
Enterprise-role comprehension, onboarding activation, cross-application workflow completion, permission-setup success, and AI-workflow trust signals.
Evidence boundary — post-launch metrics were unavailable, so these are proposed validation directions rather than reported impact.
