Role: Design Lead
Scope: End-to-end, Solo
Stack: Figma · Framer
Surfaces: Brand · Marketing site · Product
Category: AI Voice SaaS · Enterprise
01 - How the scope evolved
I was hired for a website.
I ended up owning the whole product.
Directed to campaigns & automations
Agency replacement
The engagement started with the marketing site — built at the time on Carrd, which was already becoming a liability. Nearly everything required a workaround or an iframe. I put together a case for switching to Framer: not just for visual flexibility, but because a platform positioning itself as enterprise-grade AI infrastructure couldn't afford to signal otherwise through its own website. The switch happened. That decision set the tone for how I'd operate throughout.
From there, I was introduced to the product's MVP. I audited it, presented findings, and was initially directed toward the Commerce surface — campaigns and automations — which was being modelled after established email and SMS platforms but needed significant rethinking to bring voice and calls into the picture. That went to dev. Then I was brought onto the core platform to handle new requirements and expand existing flows. That's where I replaced the external design agency that had been working with the startup and inherited everything from there on.
Each phase required assessing what existed, identifying what was wrong, and making a defensible case for a different direction — not just filling in screens.
02 - The Audit
The product was designed for the wrong user entirely
Before touching any files, I spoke with the founder and CTO to understand where the product vision had shifted. That context was essential — it meant I wasn't auditing against the original intent, but against where the company was actually heading.
What I found when I got into the designs: the entire product had been built around an internal service team — a white-glove fulfillment operation — not the direct user who would eventually be operating the platform themselves. The flows reflected that. Long forms with no grouping logic. High cognitive load with no progressive disclosure. Technical selections presented with no UX copy to orient the user. No live feedback, no inline validation, no way to test behavior before committing.
The critical insight wasn't that the design was visually inconsistent — it was that the mental model embedded in the flows was wrong. Fixing surface-level polish wouldn't have addressed it. The flows needed to be restructured around how an actual operator thinks about setting up and running AI voice agents.
The audit was a live walkthrough. I went through the existing designs with the founder, flagged what the problems were, and proposed a direction before leaving the conversation. Got the green light, returned with mockups. That became the pattern — show the problem, propose the fix, build it. The agency relationship ended around the same time. Scope expanded from there to cover the full platform.
03 - Design Library
Caught the drift in the modals and used it to define what the library needed to be
Early on I was moving fast — new screens against new requirements, adopting the existing design language as a starting point. That was the right call for the pace we were at. But enterprise SaaS platforms live and die by their modals. Process modals, creation modals, confirmation modals, deletion modals — they stack up fast, and each one has a CTA that needs to sit in the right place in the hierarchy.
The drift showed up there first. The delete button wasn't consistent across modal types. The trash icon was rendered filled in some places and outline in others. Small things individually — but signals of a larger problem: decisions were being made locally, screen by screen, without a shared reference to pull from.
I used that as the forcing function. I built out a design library covering color tokens, typographic styles, and iconography — not a rigid system, but a defined, reusable foundation that made the right decision the easy decision. The bigger fix was CTA hierarchy across modal types: establishing a clear, consistent rule for how primary, secondary, and destructive actions should be weighted and colored, so every modal spoke the same visual language regardless of when or by whom it was built.
Working as a solo designer means no one is going to flag this for you. The discipline to notice drift, trace it to its root, and define a rule rather than just fix the instance — that's the difference between patching and building.
The library paid off in two directions. For me: defined tokens and reusable components meant new screens could move faster without relitigating decisions. For engineering: the same tokens translated directly into implementation — no interpretation required, no back-and-forth about which shade of grey the border was supposed to be. In a solo-designer setup, the library isn't a nice-to-have. It's the thing that makes scale possible without a team.
04 - Key design decisions
Three problems worth unpacking
1
Agent builder: designing a layered prompting system operators could actually use
The agent builder required a way for non-technical operators to configure AI conversation logic without it collapsing into either a node-graph nightmare or an opaque black box.
What we landed on was a layered architecture: a base instructions layer that defines the agent's personality and scope, a script steps layer where operators sequence the conversation progression and set stop and transfer conditions, and an intelligence layer where the LLM uses contextual reasoning to gather required information naturally if it needs to deviate from the script.
The design challenge was making that three-layer mental model legible through the UI without dumping all of it on the operator at once. The solution was a tab and sub-tab structure that maps directly to the architecture: Base, Script, Transfer, Stop — each as a dedicated tab, with the Script layer containing its own sub-navigation for the different steps within a conversation flow. Operators work one layer at a time, in a sequence that mirrors how an actual conversation is constructed — not how the underlying system is built.
The second decision was progressive reveal. Fields and configuration blocks only surface when they're contextually relevant — when a feature is enabled, its dependent settings appear; when it's off, they don't exist on the page. The outbound/inbound radio is the clearest example: selecting Outbound reveals the voicemail configuration block; Inbound agents don't need it and never see it. This same principle runs throughout the builder — the operator only ever faces the decisions that apply to what they've chosen to do, which keeps the surface manageable regardless of how much configuration complexity exists underneath.
The result: a builder that could handle meaningful AI configuration depth while remaining usable by operators with no technical background.
2
Voicemail detection: what a customer complaint made visible
The first version of voicemail handling was fully automatic: the agent detected voicemails and left a message using the configured script, with no operator input required at either stage. The logic seemed reasonable — why would you ever not want to detect a voicemail, and if you detect one, why not leave a message?
A customer running an outbound campaign came back with a complaint. The agent had detected voicemails across the campaign and left messages on all of them, burning through their minutes. The campaign was relatively small, so the cost was contained — but the problem was real. They hadn't set a voicemail message because they didn't intend to leave one. The system assumed otherwise, because nothing in the design asked.
The issue wasn't the detection — it was that the decision to leave a message had never been exposed as a decision at all.
V2 separated the two. Detection stayed automatic (there's no reason to ever miss a voicemail on an outbound call), but what happens after detection became the operator's choice: a radio selector — drop the call, or leave a message. The voicemail message input only appeared when "leave a message" was selected, keeping the surface clean for operators who didn't need it.
V3 went further. Adding an inbound/outbound property at the agent level meant inbound agents could skip voicemail configuration entirely — it simply didn't appear. The feature went from a fully automatic assumption to a properly scoped decision tree, one that matched how operators actually think about the problem.
3
Marketing site: selling an audio product through a visual medium
The central constraint of the marketing site: the product's core value is in how it sounds, but the site is a visual medium. A single demo button doesn't solve this — it asks the prospect to opt in before they have any reason to.
The solution was layered across the scroll: the interactive orb on the hero offers zero-friction audio access immediately, with no form or commitment. Per-industry demo embeds lower in the page let prospects hear Synthesys solving their specific problem in context. Motion and copy throughout the scroll reinforce the voice metaphor for users who don't interact with either. No single mechanism carries the full weight — they compound as the user moves down the page.
05 - The discipline
Information a user can't act on is noise, not insight
When designing the latency display — how the platform surfaces AI response times to operators — the obvious reference was developer-facing AI platforms. They break latency down into its component parts: speech-to-text, LLM processing, text-to-speech, voice engine. Granular, technical, precise.
I was genuinely intrigued by it. For a moment I started modelling the display the same way. Then I stopped. Synthesys doesn't expose per-component adjustments to the operator. There are no controls mapped to STT latency or TTS latency independently. Showing that breakdown wouldn't give users anything to act on — it would just surface complexity they had no way to resolve. The detail that feels informative on a developer platform becomes friction on an operator platform, because the user context is completely different.
The display stayed simple: total response time, clearly labelled, without the breakdown. The right level of detail isn't the most detail — it's the detail that's actionable for the person looking at it.
This was the pattern across the project. Solutions from adjacent contexts arrived pre-shaped and plausible. The discipline was always the same: does this fit our user, or does it just look right because I've seen it before?
06 - Outcome
Live. At scale. Retained.
Across enterprise and SME
voice campaigns
The platform is handling real enterprise call volume — the kind of scale that surfaces design problems fast. 1M+ conversations a month, $200M+ in pipeline generated for customers, 100% client retention. Those numbers belong to the company; I'm citing them because they're the closest available signal that the product works under real conditions and that the design held up.


Synthesys was accepted into the NVIDIA Inception Program — a competitive selection of high-potential AI startups backed by NVIDIA's resources and network, not a directory — and named a Top 200 finalist for the UAE Future100. Both recognitions put the brand and product in front of serious scrutiny.
Beyond the core platform, I owned the full spectrum of brand artifacts: proposal templates, pitch decks, books, ad layouts, and Research Labs thought leadership content — all built from the same design library. The brand had to extend coherently beyond the platform into every surface Synthesys put in front of a customer or investor.
I also built the entire synthesys.app in Framer myself — design-to-production, no dev handoff — while running the Figma-to-engineering handover for the platform simultaneously.
What I can attribute to myself directly is trust — the kind that only accumulates through consistent delivery. Scope expanded five times over the course of the engagement. Requirements came in; work came back fast and implementation-ready. The founder didn't need to follow up. That reliability — not a single heroic output, but a consistent operating rhythm — is what kept the scope growing and kept me in the room.
End-to-end design ownership at startup pace
Design-to-production execution in Framer (built solo, no dev handoff)
Figma-to-engineering handover for the core platform
Building a design library (color tokens, typography, iconography) without oversight
Establishing CTA hierarchy and visual language across a complex modal-heavy product
Designing novel UX for an emerging product category
Full brand system ownership across product, site, decks, templates, and thought leadership
Replacing an external agency through audit quality
Questioning borrowed solutions before implementing them