The Unified Journey: rebuilding how partners onboard products on SmartThings

01

Context

The SmartThings Developer Console is the portal partners use to build, certify and market their products in the SmartThings ecosystem, from solo hobbyists to enterprise brands. It serves more than 120 partners and thousands of hobbyists, across 12 protocols such as Matter and Zigbee. Every paying partner goes through it to get certified, so it sits on the critical path to launching a product. It's a Next.js application that combines marketing content, documentation and developer tooling.

02

The problem

Registering and certifying a product meant filling in one product form. Over the years it had grown into dozens of fields with different requirements, backed by several upstream services, each with its own validation and dependencies.

Because everything lived in one form with one validation pass, a change to a single requirement could block a partner from submitting anything else. New features were hard to add without affecting others, and user reports were hard to trace to the field that caused them. Most importantly, users were overwhelmed: there was little guidance, and people dropped off out of frustration, confusion, or because they had to leave the page to read the documentation. Hotjar, Google Analytics and our partner-success team all confirmed it.

03

The idea

At the time there was a push to let other Samsung teams own the parts of the form that relied on their services. Microservices raised hard questions about who would respond to incidents and who controlled releases. I had already built the component library these teams were using, so I proposed consuming their work as versioned dependencies, under feature flags we controlled.

Separately, I had been exploring how to break the form into standard modules that could be chained into a step-by-step flow. When our designer, Derek Warner, shared a Figma design for a new workflow with an accompanying summary, the two ideas came together: combine summaries and workflows with a modular form, on top of the component library, with a contract other teams could build against. We called it the Unified Journey.

It was September 2025 and the roadmap was full through Q4, so I kept going on my own initiative. Within a couple of days I had a working vertical slice for one product type, enough to prove it was feasible and surface the real requirements. I demoed it to my manager and the product team and got the green light.

04

How it works

05

The result

Partners now establish what they're building first: the product type and integration. From there, they only ever see the sections that apply. Instead of a wall of fields, they land on one overview of their product, with a completion status and their path to certification. Each section opens its own guided workflow, with room to explain what's asked, recommend the standard option, link to the docs and validate that section on its own.

The look and feel is Derek Warner's work: he designed every screen, including the dark-mode, mobile and tablet variants, and had earlier helped me set up the design system behind the component library. We iterated constantly between his Figma files and my prototypes. Because the improvements shipped through the shared component library, teams not using these flows directly benefited too.

06

Rollout

Every new flow and redirect went behind a feature flag, and we released in stages: first to the product team and partner-success managers, then to all internal employees, then to a few select partners, and finally publicly at the end of January 2026. We delayed the public release twice to fix two edge cases, to protect a zero-break cutover.

07

Impact