Microsoft Demo Management System
Redesigning the content management platform behind Microsoft's global retail demo experiences used across thousands of Windows devices worldwide.
Team
Jeremy Cimafonte
Services
Design, Product
Date
2024
— 2026
Overview
Key Decisions
The Demo Management System powers every product demo you see on a Windows PC in a retail store such as Best Buy, MediaMarkt, FNAC, JB Hi-Fi, and dozens more. Microsoft admins, OEM partners like Dell and HP, and retail operators all use it to create, customize, target, and deploy localized demo experiences. I owned end-to-end UX strategy, user research, product requirements, and high-fidelity design for the full platform redesign.
25K+
Retail Stores
210K+
Devices Managed
30+
OEM & Retail
Partners
100%
Self-Service
Publishing
The Challenge
Key Decisions
Microsoft’s RDX platform powers demo experiences on Windows PCs at major retailers such as Best Buy, MediaMarkt, FNAC, and JB Hi-Fi. But behind the scenes, the content management workflows were fracturing, and partners were starting to walk away.
Everything ran through two people.
OEM partners like Dell and HP couldn't self-serve. Every content update, every targeting change, every approval required a Microsoft admin to manually intervene. As one OEM partner put it: "Can I have my team use DMS vs. having to rely on Daniel or Pau?"
Partners were defecting.
One-third of retail devices weren't running the demo application at all. Retailers like Currys and FNAC had built their own parallel systems because the official platform didn't meet their needs. This wasn't a usability problem, it was a platform adoption crisis.
The tools were duct tape.
Content creation relied on spreadsheets for SKU mapping, PowerPoint decks for stakeholder approvals, and raw JSON files for configuration. There was no preview environment. Teams created PowerPoint mockups to show stakeholders what content might look like on a device, or drove to retail stores to check in person.
Nobody could measure anything.
Management was split across disconnected tools. ReDECS for content, separate systems for targeting, and no unified dashboard. No dwell time, no interaction metrics, no A/B testing. Content decisions were pure guesswork: "We don't know what's working and what isn't. Need more data."
Research & Discovery
Key Decisions
I led a multi-method research effort, including competitive CMS analysis, stakeholder interviews, in-store retail audits, and telemetry and support ticket analysis, to ground the redesign in real user needs. I used AI tools to supercharge and assist with synthesizing interview data into the research matrix and pain point mapping, accelerating the transition from raw notes to structured findings.
The tooling was years behind industry standards. A competitive analysis against leading CMS platforms revealed the DMS was significantly behind on table-stakes features: content preview, role-based workflows, bulk operations, and localization management. Partners weren't being unreasonable by building their own systems; they were filling a gap we'd left open.
Three distinct user types, three different mental models. Stakeholder interviews across Microsoft admins, OEM brand managers, and retail operations teams surfaced three primary personas (each with fundamentally different workflows, authority levels, and definitions of success). A system that treated them identically would fail all of them.
Adoption anxiety was a real barrier. A forces analysis revealed that even users who wanted a better system worried it would be too complex to learn or incompatible with their IT policies. Any redesign had to feel simpler than what it replaced, not just more powerful.
Microsoft Admin
Platform governance, partner management, content approval workflows, targeting rules, and telemetry oversight.
Brand Partner (OEM)
Brand profile setup, product series management, localized demo creation, feature showcases, and campaign publishing.
Retail Partner
Store management, SKU mapping, device provisioning, campaign targeting at the store level, and test drive configuration.
Key Decisions
Key Decisions
One unified platform. I designed a single platform with role-based views. Admins see governance and approval controls. OEMs see brand management and campaign tools. Retailers see store operations and device provisioning. This preserved a shared data model and navigation structure while giving each persona only what they needed at each step.
The navigation model mirrors the data hierarchy: Companies → Brands → Product Series → Models → Features → Campaigns. This made the system's mental model immediately legible to new users, regardless of their role.
Evaluating build vs. buy for the CMS foundation. The competitive analysis made a clear case for leveraging an existing headless CMS. Established platforms already provided structured content models, modular templates, role-based permissions, and localization workflows out of the box. Ultimately, the team decided to build the CMS in-house to maintain full ownership and long-term flexibility. My role was ensuring that decision didn't mean reinventing everything: I scoped the custom build to focus on the capabilities that were truly unique to our domain (targeting rules, device preview simulation, telemetry integration, and offline deployment, etc.) while applying the patterns and conventions we'd identified in the competitive analysis to the foundational CMS layer. The research ensured we built with intent, not from scratch by default.
Defining what we wouldn't build for MVP. With an enterprise CMS touching global partners, the feature surface area was enormous. The most impactful thing I did was define and document what we would not build for the first release. Features such as A/B testing, advanced offline deployment, and automated content optimization, were all deferred with written rationale for each. This gave the team a focused, shippable scope and gave stakeholders confidence that their needs weren't being ignored. The P0/P1/P2 prioritization framework from the research directly informed these decisions. I used AI to help build and maintain the PRD as a living document. Keeping feature definitions, acceptance criteria, and deferral rationale current as the project evolved.
Progressive disclosure over feature density. An enterprise platform serving three user types across 30+ global partners could easily become overwhelming. I used progressive disclosure patterns throughout (simple defaults with advanced options available on demand) so first-time OEM partners saw a guided onboarding flow while power users could access the full targeting and configuration depth. This reduced perceived complexity for new partners (a key adoption barrier the research identified) while preserving efficiency for experienced users.
Design Solution
Key Decisions
I designed the DMS interface using Microsoft's Fluent 2 design system, delivering high-fidelity screens in both light and dark themes. The research and PRD were thorough enough to move directly to high-fidelity design, using AI-assisted prototyping to rapidly explore UI options for complex controls such as the targeting interface and content editor before committing to final patterns.
Rather than walking through the design chronologically, I've organized the solution around the core problems it addresses.
Self-Service Content Creation
Before: Content creation required Microsoft admins to manually assemble demos using spreadsheets for data, PowerPoint for layouts, and JSON for configuration. Partners couldn't create or edit content independently.
After: A visual content editor lets OEM and retail partners build, customize, and publish demo experiences directly. Templates provide brand-consistent starting points; a structured content model separates content from presentation, enabling reuse across regions and devices. Partners can go from draft to published without touching a spreadsheet or waiting on an admin.
Unified Targeting & Deployment
Before: Targeting was a multi-step guessing game (platform, OEM, model, region) with unclear priority rules, no subtractive logic, and frequent errors, resulting in shoppers seeing irrelevant or missing demos.
After: A guided targeting interface with clear parameter hierarchy, validation checks, tooltips, and support for both additive and subtractive targeting. Rules-based deployment replaces manual per-asset configuration, letting partners target by region, store, device, and locale at scale.
Partner Dashboard & Role-Based Access
Before: All three user types (admins, OEMs, retailers) used the same undifferentiated interface. There was no self-service onboarding, and OEM IT policies often blocked direct access entirely.
After: A unified dashboard with role-based views surfaces the right tools for each persona. First-time partner onboarding flows guide setup step by step. The task management system gives every user a clear picture of their active work, pending reviews, and items needing attention.
Preview & Approval Workflows
Before: Previews relied on PowerPoint decks or in-store visits. Approvals happened over email and Teams, with no version history or audit trail.
After: An in-platform preview environment simulates how content will appear on actual devices across resolutions and locales. Shareable preview links replace PowerPoint decks. A built-in multi-level approval system with commenting, notifications, and version tracking keeps the entire review workflow inside the platform.
Analytics & Telemetry
Before: No integrated metrics. Teams couldn't measure demo engagement, dwell time, or content effectiveness. Every optimization decision was guesswork.
After: Integrated telemetry dashboards surface device status, content coverage, and geographic deployment data in real time. The analytics foundation gives partners and Microsoft visibility into demo performance for the first time — enabling the data-driven content optimization that was previously impossible.
Impact
Key Decisions
The DMS 2.0 redesign transformed a fragmented, manual content pipeline into a unified, self-service platform for Microsoft's global retail demo ecosystem, leading to increased sales and a 70%+ reduction in content handoff time.
Learnings
Key Decisions
How you define the problem determines what you build. This project started as a UX redesign for a tool was hard to use. But the research revealed something bigger: one-third of partners weren't using the platform at all. Currys and FNAC had built their own systems. Reframing this as a platform adoption crisis rather than a usability problem changed the entire scope of the redesign. From improving screens to rebuilding trust in the ecosystem. The most important design decision I made happened before I opened Figma.
The best recommendation isn't always the one that ships. I made a strong case for leveraging an existing headless CMS. The team chose to build in-house for long-term ownership. Instead of resisting, I shaped that decision - scoping the custom build around our unique differentiators and applying the patterns we'd benchmarked to the foundation. Knowing when to advocate and when to adapt is the difference between influence and stubbornness.
Scope discipline was the most impactful skill. As both Product Owner and Lead Designer, the pull toward "one more feature" came from both directions. The single most important thing I did was define and document what we wouldn't build for MVP, with clear rationale for each deferral. That discipline is what let the team ship a focused first release instead of an overloaded one.
