Spectrm had approved a full product redesign. Then we realized the interface wasn't the real problem. The product had outgrown the system underneath it. I joined at that turning point.

Spectrm had approved a full product redesign. Then we realized the interface wasn't the real problem. The product had outgrown the system underneath it. I joined at that turning point.

Role

Senior Product Designer

Senior Product Designer

Scope

Redesign · Design System · Automation · AI

Redesign · Design System · Automation · AI

Period

2023-2025

2023-2025

Overview

Overview

What Spectrm was
What Spectrm was

Spectrm helped brands automate customer conversations across messaging channels, turning marketing and commerce flows into conversational journeys.


Teams at companies including BMW, Volkswagen, Ford, KLM and HelloFresh used it to create conversations, personalize messages, interpret replies with AI and measure performance. All of these capabilities met inside the same journey.

Spectrm helped brands automate customer conversations across messaging channels, turning marketing and commerce flows into conversational journeys.


Teams at companies including BMW, Volkswagen, Ford, KLM and HelloFresh used it to create conversations, personalize messages, interpret replies with AI and measure performance. All of these capabilities met inside the same journey.

My role
My role

I joined as a Senior Product Designer during the end-to-end redesign. My work spanned core automation experiences, the new design system and product discovery, partnering with the CPO, lead product designer, PMs and engineering from early product thinking through production-ready design.

I joined as a Senior Product Designer during the end-to-end redesign. My work spanned core automation experiences, the new design system and product discovery, partnering with the CPO, lead product designer, PMs and engineering from early product thinking through production-ready design.

Context

Context

The redesign exposed the real problem
The redesign exposed the real problem

Spectrm had grown considerably on top of Quasar. Over time, product requirements had become more sophisticated than the framework underneath them.


The redesign made that visible everywhere. New interaction patterns required exceptions, existing components had to be stretched and seemingly small UX improvements often carried technical compromises.


At some point, redesigning the interface without addressing the foundation stopped making sense.

Spectrm had grown considerably on top of Quasar. Over time, product requirements had become more sophisticated than the framework underneath them.


The redesign made that visible everywhere. New interaction patterns required exceptions, existing components had to be stretched and seemingly small UX improvements often carried technical compromises.


At some point, redesigning the interface without addressing the foundation stopped making sense.

Design Decisions

Design Decisions

Stop designing around the framework
Stop designing around the framework

Initially, the practical approach was to keep working within Quasar wherever possible.


But the further the redesign moved, the more our product started adapting to the framework instead of the other way around. Together with design and engineering, we moved toward a custom component foundation.


That decision increased the upfront scope significantly. It also allowed components to be designed around Spectrm's actual behavior, including complex states, configuration-heavy workflows and patterns Quasar had never been intended to support.

Initially, the practical approach was to keep working within Quasar wherever possible.


But the further the redesign moved, the more our product started adapting to the framework instead of the other way around. Together with design and engineering, we moved toward a custom component foundation.


That decision increased the upfront scope significantly. It also allowed components to be designed around Spectrm's actual behavior, including complex states, configuration-heavy workflows and patterns Quasar had never been intended to support.

Complexity needed structure, not simplification
Complexity needed structure, not simplification

The journey builder made that challenge especially visible. A single automation could contain triggers, messages, conditions, branches, variables and increasingly complex configuration. Cleaner concepts were easy to produce by reducing what was visible, but that pushed important context elsewhere and made larger journeys harder to reason about.


We iterated instead on how the complexity was structured. Condition nodes were redesigned, variables were grouped more meaningfully and details such as long variable names had to work without overwhelming the canvas. The canvas became less about making every node look simple and more about making the whole journey understandable.

The journey builder made that challenge especially visible. A single automation could contain triggers, messages, conditions, branches, variables and increasingly complex configuration. Cleaner concepts were easy to produce by reducing what was visible, but that pushed important context elsewhere and made larger journeys harder to reason about.


We iterated instead on how the complexity was structured. Condition nodes were redesigned, variables were grouped more meaningfully and details such as long variable names had to work without overwhelming the canvas. The canvas became less about making every node look simple and more about making the whole journey understandable.

Design System

Design System

One redesign became a product language
One redesign became a product language

Those problems rarely stayed isolated to one screen. A condition, dropdown or input designed for a simple form could behave very differently inside an automation node with multiple states, long values or nested logic.


I helped turn those recurring cases into a system of components, variants and interaction rules that design and engineering could reuse across the product. The design system grew from the product rather than being designed separately from it.

Those problems rarely stayed isolated to one screen. A condition, dropdown or input designed for a simple form could behave very differently inside an automation node with multiple states, long values or nested logic.


I helped turn those recurring cases into a system of components, variants and interaction rules that design and engineering could reuse across the product. The design system grew from the product rather than being designed separately from it.

Ai Experience

Ai Experience

Then AI changed the conversation
Then AI changed the conversation

While the redesign was still evolving, ChatGPT happened. Generative AI began changing the assumptions behind conversational software.


I moved into Product Discovery to explore what that meant for Spectrm and how AI-driven experiences could fit into a product originally built around deterministic journeys.


The questions changed with it. If parts of a conversation could now be generated dynamically, we had to rethink how much control users needed and how that control should be represented in the product.

While the redesign was still evolving, ChatGPT happened. Generative AI began changing the assumptions behind conversational software.


I moved into Product Discovery to explore what that meant for Spectrm and how AI-driven experiences could fit into a product originally built around deterministic journeys.


The questions changed with it. If parts of a conversation could now be generated dynamically, we had to rethink how much control users needed and how that control should be represented in the product.

AI needed boundaries
AI needed boundaries

For enterprise customers, useful AI is not enough. They need clarity over which data it can access, how information is processed, how behavior is constrained and what happens when confidence is low.


The experience communicated that control through defined sources, behavioral limits, fallback paths and visible system states. The aim was to expose decisions affecting privacy, responsibility and customer experience without exposing the complexity underneath them.

For enterprise customers, useful AI is not enough. They need clarity over which data it can access, how information is processed, how behavior is constrained and what happens when confidence is low.


The experience communicated that control through defined sources, behavioral limits, fallback paths and visible system states. The aim was to expose decisions affecting privacy, responsibility and customer experience without exposing the complexity underneath them.

outcome

outcome

An unfinished transition
An unfinished transition

After two years, Spectrm was acquired by Charles and later folded into its conversational commerce platform.

Some ideas and patterns continued there. Other parts of the roadmap never reached production.


Spectrm never reached the neat finish line we originally imagined. The acquisition changed the roadmap while the redesign was still evolving, leaving some of the work shipped, some continued elsewhere and some unfinished.

After two years, Spectrm was acquired by Charles and later folded into its conversational commerce platform.

Some ideas and patterns continued there. Other parts of the roadmap never reached production.


Spectrm never reached the neat finish line we originally imagined. The acquisition changed the roadmap while the redesign was still evolving, leaving some of the work shipped, some continued elsewhere and some unfinished.

Looking back
Looking back

The defining decision was not replacing Quasar. It was recognizing that Spectrm’s product direction required a foundation of its own.


The builder made that system necessary. The rest of the platform made it durable.

The defining decision was not replacing Quasar. It was recognizing that Spectrm’s product direction required a foundation of its own.


The builder made that system necessary. The rest of the platform made it durable.