Nuance Design System
Nuance.com was running on Bootstrap with no formalized design system layered on top. I founded one and deliberately shaped it to Microsoft's conventions, so the coming integration wouldn't turn it into throwaway work.
A Dragon Professional v16 product page on nuance.com, built on the Nuance Design System.
Overview
Nuance.com - the marketing and product site for Nuance's conversational-AI and healthcare-documentation lines - had grown for years on a bare Bootstrap foundation with no shared, formalized design system on top of it. I founded the system that fixed that, and made a deliberate early call: build it to already look and behave like Microsoft's conventions, since Nuance's acquisition by Microsoft meant an integration was coming.
Nuance needed a system that could scale internally in the near term, but that also wouldn't become throwaway work once the wider integration happened.
No system prior to an acquisition
Nuance.com had grown without a formalized design system. Components had drifted into inconsistent variants across pages, there was no single source of truth for developer handoff, and the site was overdue for an accessibility and technical foundation refresh.
This mattered beyond day-to-day efficiency. Nuance was moving toward full integration into Microsoft, and Microsoft was in parallel building its own enterprise design system, Reimagine.
Redundant variants of the same pattern, inconsistent naming, and no documentation authors could reference meant every page rebuilt decisions that had already been made.
Microsoft was building its own enterprise design system, Reimagine, in parallel, and thin dev resourcing meant a fully independent NDS risked becoming redundant work leadership could shelve entirely.
W3C compliance and responsive layout support were both overdue, which made the technical foundation one of the first things to fix rather than the last.
Research & discovery
Component inventory audit
Significant divergence: multiple redundant variants of the same pattern, inconsistent naming, and no editorial documentation authors could reference when building pages.
Handoff by ad hoc communication
On the development side, design specs weren't standardized, so handoff relied on conversation rather than a shared source of truth.
Reimagine as a benchmark
I proposed aligning NDS to Microsoft's conventions before seeing Reimagine firsthand, and the working relationship I built with their team later confirmed the bet was right.
Authors as the real users
AEM content authors were the people living with the drift daily, which made their pain points the most reliable signal for what to standardize first.
The work had two tracks running together: a technical foundation, and the documentation and handoff practice built on top of it.
Technical foundation
I partnered with the development team on QA and audit work to support an upgrade to the latest version of Bootstrap (v5.3). This unlocked CSS variables, responsive typography, and mobile-first layout patterns that the component library could then be built on top of.
Documentation and handoff
I built editorial-style component documentation for authors, describing how and when to use each component, and used generative AI alongside the EightShapes Figma plugin to accelerate that work. I also built granular component specs for developers, and established Figma as the enforced single source of truth for handoff, training the development team on how to extract specs and properties directly from it.
Biweekly sessions with authors
To keep the system grounded in real usage, I ran biweekly sessions with AEM content authors to surface their pain points, then applied that feedback to revamp specific components, including the site's purchase widget, product catalog, and webinar pages.
Process the team could track
With the product manager, I introduced sprint ceremonies (planning, standups, retrospectives) and pushed adoption of Azure DevOps as the team's shared work management platform, replacing informal coordination that had made prioritization difficult to track.
Development resourcing was thin, and a fully bespoke atomic system is expensive to sustain with a small team. I proposed aligning NDS to Microsoft's conventions before I'd seen Reimagine itself, betting that consolidation would matter more than independence for a small team with thin dev resourcing. Once the working relationship with their team gave me visibility into Reimagine's actual file organization, naming conventions, and documentation structure, that confirmed the direction and let us commit further. That early bet turned out to matter more than I expected.
Built to align, not compete
An atomic, Figma-based design system for nuance.com with three parts, deliberately architected to mirror Microsoft's Reimagine conventions rather than diverge from them.
Upgraded foundation
Bootstrap 5.3 in production, supporting responsive and accessible patterns: CSS variables, responsive typography, and mobile-first layouts for everything built after it.
AI-assisted documentation
Editorial component documentation written for authors, covering how and when to use each component, produced with generative AI and the EightShapes Figma plugin.
Figma as the source of truth
Enforced dev-ready specs for engineering handoff, with the development team trained to extract specs and properties directly from the file.
Additional screens from this project are being prepared for publication. Check back soon, or get in touch for a walkthrough.
Impact & results
NDS was ultimately placed on indefinite hold when Nuance was integrated into Microsoft.com, and the alignment decision is what kept the investment.
Bootstrap 5.3 shipped to production in December 2023, establishing the technical foundation for all subsequent component work
Figma established as the enforced source of truth for handoff, removing a major source of spec ambiguity and rework
The working relationships I built with Microsoft's Reimagine team during this project carried forward directly. I moved into a Reimagine governance role at Microsoft once the integration completed, drawing on the same system-thinking work I'd done at Nuance.
Lessons learned
Aligning early to Microsoft's conventions, rather than building a fully independent system, was the right call given how the project actually played out. In an organization heading toward consolidation, designing for compatibility can matter more than designing for independence.
The one thing I'd do differently: with development resourcing constrained, I stayed largely on the design and Figma side of the system. In hindsight, I spent enough hours in Figma comment threads that one outlived an entire sprint. Next time I'd trade some of that for actual repo access in order to reduce the QA back-and-forth with the dev team.