Ardor Cloud

Turning a powerful but overwhelming platform into
a single conversation

Turning a powerful but overwhelming platform into a single conversation

Role

Lead Product Designer

Collaborators

Founder/CEO

3 Engineers

CMO

Timeline

2025

8 months

TL;DR

Ardor Cloud lets people build production-grade software just by describing what they want. The power was there from day one, but so was the overwhelm. New users landed in a workspace full of tools and panels with no obvious place to begin.


As the founding and only product designer, I owned the experience end to end: research, UX strategy, AI interaction design, the UI system, and the roadmap. I took the product from 0→1, ran user interviews on a continuous loop, and led the strategic pivot to a chat-first experience, making conversation the way you build, rather than one feature among many.

Ardor Cloud lets people build production-grade software just by describing what they want. The power was there from day one, but so was the overwhelm. New users landed in a workspace full of tools and panels with no obvious place to begin.


As the founding and only product designer, I owned the experience end to end: research, UX strategy, AI interaction design, the UI system, and the roadmap.
I took the product from 0→1, ran user interviews on a continuous loop, and
led the strategic pivot to a chat-first experience, making conversation the
way you build, rather than one feature among many.

TRY IT OUT HERE

TRY IT OUT HERE

TRY IT OUT HERE

+50%

+50%

signup growth, month-on-month

signup growth,
month-on-month

~2 weeks

~2 weeks

shaved off design-to-ship time

↑ Feature engagement

↑ Feature engagement

after redesigning the AI Copilot to be transparent

after redesigning the
AI Copilot to be transparent

PROBLEM

A powerful platform with no front door

A powerful platform with no front door

Ardor could do a lot, and that was the problem. New users opened the product to multiple panels, tools, and entry points, with no obvious place to start. Confident users muddled through; everyone else stalled before they'd built anything.

The platform was also trying to serve two very different people through one interface: non-technical builders who wanted to describe an idea and watch it work, and developers who wanted control over and visibility into the actual code. It was stretched between both, and serving neither well.

The job wasn't to add more. It was to give the platform a clear starting point and one obvious way to move forward.

Ardor could do a lot, and that was the problem. New users opened the product to multiple panels, tools, and entry points, with no obvious place to start. Confident users muddled through; everyone else stalled before they'd built anything.

The platform was also trying to serve two very different people through one interface: non-technical builders who wanted to describe an idea and watch it work, and developers who wanted control over and visibility into the actual code. It was stretched between both, and serving neither well.

The job wasn't to add more. It was to give the platform a clear starting point and one obvious way to move forward.

DISCOVERY & INSIGHTS

Listening on a loop

I set up a continuous feedback pipeline, regular user interviews and usability testing, so decisions were grounded in what people actually did, not what we assumed. Three things surfaced again and again:

"I don't understand what the AI just did" - When the Copilot took actions or something broke, users wanted to see the reasoning, not just the result. Without visibility into what happened and why, they couldn't iterate confidently.

"I don't understand what the AI just did" - When the Copilot took actions or something broke, users wanted to see the reasoning, not just the result. Without visibility into what happened and why, they couldn't iterate confidently.

"I don't know where to start" - Users saw the platform's tools but couldn't figure out the right entry point for their task.

"I don't know where to start" -
Users saw the platform's tools but couldn't figure out the right entry point
for their task.

"It feels like a lot of separate tools" – Features lived in their own surfaces, so the product felt fragmented.

"It feels like a lot of separate tools" – Features lived in their own surfaces, so the product felt fragmented.

Some of these pain points sat at the intersection of design and engineering, platform reliability and AI accuracy weren't mine to solve alone. But how failures were communicated, and how users could recover from them, was
a design problem. That's where I focused: making AI behaviour legible so users could understand, trust, and course-correct.


These insights directly shaped the redesign of the Copilot as the primary entry point, and informed how we surfaced AI reasoning, error states, and recovery paths throughout the experience.

Some of these pain points sat at the intersection of design and engineering, platform reliability and AI accuracy weren't mine to solve alone. But how failures were communicated, and how users could recover from them, was a design problem.
That's where I focused: making AI behaviour legible so users could understand, trust, and course-correct.


These insights directly shaped the redesign of the Copilot as the primary entry point, and informed how we surfaced AI reasoning, error states, and recovery paths throughout the experience.

OPPORTUNITY

Make conversation the workflow

Make conversation the workflow

If people didn't know where to start, the answer was to let them start the most natural way possible, by saying what they wanted, and letting the platform bring the right tools to them.

This visual shows how the core building blocks came together.

The principles that guided it

1

Show the work.

The AI should always make its actions visible, what it did, why, and what changed, so people can trust it and correct it.

1

Show the work.

The AI should always make its actions visible, what it did, why, and what changed, so people can trust it and correct it.

2

Keep the user in control.

Automation should feel like steering, not surrendering. Every AI action stays
reviewable and reversible.

3

Bring the tools to the moment.

Bring the tools to the moment.

Instead of making people hunt through panels, surface the right capability inside the conversation, exactly when it's needed.

Instead of making people hunt through panels, surface the right capability inside the conversation, exactly when it's needed.

THE SOLUTION

How it came together

The interface moved through three stages: an early layered prototype, a more unified workspace, and finally the chat-first experience we shipped. Each stage was tested with real users before we committed to the next.

DECISION #1

One platform, one language

I brought the scattered surfaces under a single, consistent system, reskinning shadcn (an open-source component library) into Ardor's own design language. I built custom, handoff-ready components and paired them with AI-assisted handoff, so design and engineering worked from the same source of truth and shipped faster.

ARDOR UI (BEFORE)

ARDOR UI (BEFORE)

ARDOR UI (BEFORE)

ARDOR UNIFIED UI (NEW)

ARDOR UNIFIED UI (NEW)

ARDOR UNIFIED UI (NEW)

How I prototyped it

Rather than testing flat mockups, I prototyped the key flows directly in code. The split-screen code view is the clearest example, chat on one side, live code on the other. A static Figma frame couldn't tell us whether that interaction actually felt right, because all the value was in how the two sides moved together. Building it in real code, with AI-assisted tooling, let me test the real thing with users in days and hand it to engineering nearly ready to ship, which is a big part of how design-to-ship time dropped by about two weeks.

DESIGN DECISION #2

AI you can actually see

When we observed how users interacted with the platform, we noticed two recurring patterns: users would click around trying to find the right tool, often getting overwhelmed by features presented all at once, and when they did use the Copilot, they were unsure what it was doing or why, which made it hard to trust or iterate on its outputs.


This told us the platform needed both a clearer entry point and a more transparent AI experience. The Copilot needed to be positioned as the main way users interact with the platform, but only if users could actually see and understand what it was doing. That's what drove the redesign of the prompt box, chat panel, and ultimately the shift to a chat-first entry point.

1

Prompt Box

Restructured how users communicate with the Copilot, making AI actions and
reasoning visible rather than opaque.


Restructured how users communicate with the Copilot, making AI actions and reasoning visible rather than opaque.

REDESIGNED PROMPT BOX TURNS AI INTERACTIONS FROM A BLACK BOX, INTO A VISIBLE WORKFLOW.

REDESIGNED PROMPT BOX TURNS AI INTERACTIONS FROM A BLACK BOX, INTO
A VISIBLE WORKFLOW.

REDESIGNED PROMPT BOX TURNS AI INTERACTIONS FROM A BLACK BOX, INTO A VISIBLE WORKFLOW.

2

Chat Panel

The chat panel evolved from a simple messaging interface into a control surface for AI-driven work.

By exposing progress, intermediate steps, and concrete outputs in context, the experience helps users stay oriented, intervene when needed, and build confidence in AI-assisted changes without breaking flow.

3

Chat–First Entry Point

Elevated chat from a side panel to the platform's front door. Users begin by planning, scoping, and defining requirements through conversation with the Copilot and as their intent becomes clear, the platform surfaces the right tools like canvas, deployment, and services to support the next step.

Elevated chat from a side panel to the platform's front door. Users begin by planning, scoping, and defining requirements through conversation with the Copilot and
as their intent becomes clear, the platform surfaces the right tools like canvas, deployment, and services to support the
next step.

DESIGN DECISION #3

Built for real developer workflows

To design effectively for a platform that builds and runs real software, I needed to deeply understand the underlying systems. Ardor sits at the intersection of AI, infrastructure, and developer tooling, where poor abstractions can quickly break user trust.


I invested time in learning how large language models behave in practice, how GitHub-based workflows operate, and how deployment, observability, and billing function in production environments. I then translated this understanding into product designs for GitHub integration, deployment and logging views, and billing flows that balanced abstraction with necessary visibility.


This work grounded Ardor in real-world developer expectations. Users could move from experimentation to production with fewer surprises, while the platform maintained the simplicity required for less technical builders.

To design effectively for a platform that builds and runs real software, I needed to deeply understand the underlying systems. Ardor sits at the intersection of AI, infrastructure, and developer tooling, where poor abstractions can quickly break
user trust.


I invested time in learning how large language models behave in practice, how GitHub-based workflows operate, and how deployment, observability, and billing function in production environments. I then translated this understanding into product designs for GitHub integration, deployment and logging views, and billing flows that balanced abstraction with necessary visibility.


This work grounded Ardor in real-world developer expectations. Users could move from experimentation to production with fewer surprises, while the platform maintained the simplicity required for less technical builders.

AI-ASSISTED DEPLOYMENT FAILURES, SUMMARISED FOR CLARITY WITHOUT LOSING TECHNICAL TRACEABILITY

AI-ASSISTED DEPLOYMENT FAILURES, SUMMARISED FOR CLARITY WITHOUT LOSING
TECHNICAL TRACEABILITY

AI-ASSISTED DEPLOYMENT FAILURES, SUMMARISED FOR CLARITY WITHOUT LOSING TECHNICAL TRACEABILITY

GitHub Integration

I designed the GitHub integration to align with developers’ existing mental models, making repository connection, syncing, and deployment feel familiar and predictable rather than abstracted or opaque. The experience balances automation with visibility, ensuring users understand what’s connected, what’s being synced, and how changes flow into production.

For deeper technical details, see the full documentation

I designed the GitHub integration to align
with developers’ existing mental models, making repository connection, syncing,
and deployment feel familiar and predictable rather than abstracted or opaque.
The experience balances automation with visibility, ensuring users understand what’s connected, what’s being synced, and how changes flow into production.

For deeper technical details, see the full documentation

READ MORE

READ MORE

READ MORE

MY ROLE

Turning ambiguity into shared direction

Turning ambiguity into
shared direction

Brainstorm workshops at Ardor are treated as working sessions rather than discussions. As the only UX designer, I collaborate closely with engineers, founders, and marketing to sketch, prototype, and iterate in real time—collapsing feedback loops and turning ambiguity into concrete decisions. These sessions help align user needs, AI behavior, and technical constraints early, ensuring the product evolves through collective ownership rather than isolated handoffs.


My final focus at Ardor was evolving the chat-first direction from concept to execution. The insight that conversation should be the primary interface unlocked a broader rethinking of how every surface in the platform relates to user intent. Instead of organising the platform around modes or tool categories, we're designing
around a simple principle: users start with a conversation, and the platform assembles the right context and tools around that conversation.

Brainstorm workshops at Ardor are treated as working sessions rather than discussions. As the only UX designer, I collaborate closely with engineers, founders, and marketing to sketch, prototype, and iterate in real time—collapsing feedback loops and turning ambiguity into concrete decisions. These sessions help align user needs, AI behavior, and technical constraints early, ensuring the product evolves through collective ownership rather than isolated handoffs.


My final focus at Ardor was evolving the chat-first direction from concept to execution. The insight that conversation should be the primary interface unlocked a broader rethinking of how every surface in the platform relates to user intent. Instead of organising the platform around modes or tool categories, we're designing around a simple principle: users start with a conversation, and the platform assembles the right context and tools around that conversation.

COLLABORATIVE BRAINSTORM WORKSHOPS

COLLABORATIVE BRAINSTORM WORKSHOPS

COLLABORATIVE BRAINSTORM WORKSHOPS

RETROSPECTIVE

What I learned designing an AI-native product

What I learned designing an
AI-native product

Over the past 8 months at Ardor, I've learned that designing for AI is less about novelty and more about responsibility. AI accelerates iteration and expands what users can build, but it also amplifies confusion when intent, context or system behaviour is unclear. The most impactful design work often came from slowing down to make AI actions legible so users could trust, steer and build alongside the system. Designing for AI ultimately means designing for evolving mental models, where clarity, control, and adaptability matter more than polished interactions alone.

AI has unlocked unprecedented possibilities within a single tool, requiring a rethink of traditional UI paradigms. Interfaces will become more dynamic and adaptive, shifting with user intent and context to maintain clarity, focus, and flow throughout the workflow.

Over the past 6 months at Ardor, I've learned that designing for AI is less about novelty and more about responsibility. AI accelerates iteration and expands what users can build, but it also amplifies confusion when intent, context or system behaviour is unclear. The most impactful design work often came from slowing down to make AI actions legible so users could trust, steer and build alongside the system. Designing for AI ultimately means designing for evolving mental models, where clarity, control, and adaptability matter more than polished interactions alone.

AI has unlocked unprecedented possibilities within a single tool, requiring a rethink of traditional UI paradigms. Interfaces will become more dynamic and adaptive,
shifting with user intent and context to maintain clarity, focus, and flow throughout the workflow.

Over the past 6 months at Ardor, I've learned that designing for AI is less about novelty and more about responsibility. AI accelerates iteration and expands what users can build, but it also amplifies confusion when intent, context or system behaviour is unclear. The most impactful design work often came from slowing down to make AI actions legible so users could trust, steer and build alongside the system. Designing for AI ultimately means designing for evolving mental models, where clarity, control, and adaptability matter more than polished interactions alone.

AI has unlocked unprecedented possibilities within a single tool, requiring a rethink of traditional UI paradigms. Interfaces will become more dynamic and adaptive, shifting with user intent and context to maintain clarity, focus, and flow throughout the workflow.