Nuance Mix - Versioning and Workstreams
Nuance Mix is an enterprise conversational AI platform used by 75% of Fortune 100 companies and over 15,000 enterprise customers across healthcare, retail, and customer service. The platform allows both technical and non-technical users to build, train, and deploy voice and chat experiences - from defining intents and dialog flows to publishing finished bots across channels.
As a product designer on the Mix team, I owned end-to-end design across multiple areas of the platform over three years. One of the most significant projects I undertook was designing a versioning system for Mix - a feature that had become one of the most consistently requested capabilities from enterprise customers, and one that would fundamentally change how teams managed and maintained their conversational apps.
Challenge
Enterprise teams building on Mix were running into a problem familiar to anyone who has shipped a product: things go wrong after deployment, and recovering from those mistakes was harder than it needed to be.
Users wanted an easier way to roll back to a known good state after a bad deploy. They wanted to be able to track the history of their bot over time, understand what changed and when, and restore previous states without manual workarounds. For teams with multiple contributors working on the same project, the risk of overwriting each other's work was a constant friction point.
The challenge was compounded by the nature of the product. Most versioning systems live in code environments - GitHub, GitLab, version-controlled IDEs - where the mental model of branches, commits, and diffs is second nature to developers. Mix served a much broader audience. Business users, content designers, and conversation architects were building bots alongside technical users, and they had no frame of reference for the conventions of code-based version control.
The goal was clear: bring the safety and confidence of versioning to Mix in a way that felt native to a visual product builder - not a code editor.
Process
Research & Competetive Analysis:
The feature was driven primarily by direct customer feedback, with versioning appearing consistently in support requests and product conversations. To understand how to approach the design, I conducted a competitive analysis across a wide range of products that had solved versioning in some form - Figma, Webflow, various CMS platforms, and inevitably, developer tools like GitHub and GitLab.
The developer tools were instructive but not directly transferable. They assume a user who thinks in commits and branches. Mix needed something that could be understood immediately by someone who had never touched a terminal.
Landing on the timeline model
The timeline emerged early as the right pattern. It's a universally understood metaphor - everyone knows how to read a timeline, and it immediately communicates the core concept: your bot has a history, and you can move through it. I explored an alternative approach using a flat list of versions and snapshots, but it quickly became clear that the list format lost something important: the sense of time passing, of distance between states. The timeline made the relationship between snapshots and versions intuitive in a way a list couldn't.
The core model worked like this: as users worked on their bot, the system automatically created snapshots - lightweight checkpoints that appeared as markers on the timeline. From any snapshot, a user could create a named version - a more deliberate save state they could return to. Rolling back was available at two levels: to the most recent snapshot, or to any previously created version.
The language was deliberately non-technical throughout. No "commits." No "HEAD." States were described in plain terms, actions were labeled for what they did rather than what they were called in engineering.
Multi-user considerations:
Mix supported multiple contributors on the same project, which added complexity to the versioning model. The system needed to work in a shared environment without creating conflicts - versioning applied to the bot as a whole, not individual user sessions. This required clear communication design around collaborative states: what happens when two users are working simultaneously, and how does the system surface that without getting in the way.
Workstreams - designing a visual Git:
The versioning feature was designed as the foundation for a larger initiative I was working on in parallel: Workstreams. The concept was to bring branching to Mix - allowing individual users or teams to create their own workstream, develop independently, and merge back into the main project through a structured review and approval process.
The ambition of Workstreams was essentially to replicate the Git workflow for a visual product builder. That meant designing a diff view — a side-by-side comparison of two states where differences were visually highlighted rather than shown as code - and a merge and approval flow that non-technical users could navigate with confidence. The reference was a git repo; the execution had to feel like a design tool.
Loading states and product character:
One of the more enjoyable design challenges during this period was developing Mix's product character - including the mascot I designed for the platform's loading states. In a product this technically dense, moments of levity matter. The loading screens gave the platform a personality and gave users a moment to breathe during longer processing operations.
Results
By the time platform investment was paused following Nuance's acquisition by Microsoft, the versioning feature had reached high-fidelity design and was actively in development - the engineering team had begun implementation when the project was wound down.
The designs were validated internally and reflected months of iteration against real customer needs. The rollback model, timeline interface, and plain-language approach were well-received in internal reviews, and the Workstreams concept represented a clear and logical next step that would have significantly expanded Mix's capabilities for enterprise teams managing complex, multi-contributor projects.
The feature didn't reach production - but the problem it was solving was real, the approach was validated, and the design work represents one of the most complex systems challenges I've taken on: making version control feel effortless for users who had never needed to think about it before.
“I don't think I've ever seen branching and visual diffing done this way before. This is awesome.”
Stakeholder reaction in design review
Principle Engineer, Nuance Mix
Conclusion
Versioning for Mix taught me a lot about designing at the edge of a user's mental model. The hardest part wasn't the interaction design - it was figuring out how to borrow a concept deeply embedded in technical culture and strip away everything that made it feel technical, while keeping everything that made it useful.
The timeline model was the right call. The Workstreams concept - a visual Git - remains one of the ideas I'm most proud of developing, even without a shipped product to point to. It pushed me to think about how visual diff, merge, and branch metaphors translate to a non-code environment, and it's a problem space I'd be genuinely excited to return to.
The project also reinforced something I believe about enterprise product design: the complexity of the system is your problem, not the user's. Your job is to absorb it.