Making the conversation visible

Context

Hoomanlabs sells AI voice agents that make and take phone calls at scale: debt collection, lead qualification, support, recruitment screening. The platform has run [10M+] calls across lending, e-commerce, travel, and logistics.

The people on these pages are not who the category was built for. They're collections leads at NBFCs, support managers at D2C brands, recruiters screening at volume — operators with a number to hit and no engineering budget to hit it with. They'd been sold on replacing a call centre. Then they opened a product that assumed they could write a system prompt.

The product already existed and already had customers. That's the harder brief: four live surfaces to redesign without breaking the people already depending on them — and a component library underneath that had quietly become the ceiling on how good any of them could get.

The problem

Three problems, and the third is the reason the first two kept not getting fixed.

The builder asked people to think in the wrong shape. A call is a graph, but operators don't think in graphs — they think in scripts. First I greet them, then I check I've got the right person, then it depends. The product asked them to declare that structure up front, in the abstract, before hearing a single call. For a developer that's fine. For a collections lead it's a blank page with stakes.

A bad call and its cause lived on different planets. Call logs told you what happened on one call. Usage dashboards told you aggregate minutes. Neither answered the only question an ops manager actually has — which part of my script is losing people, and what do I change — and nothing connected a call that went wrong to the place you'd go to fix it.

And the four surfaces didn't look related. Mantine was the right call when the team picked it; it bought speed at the stage where speed was the whole strategy. But every screen carried its defaults, and years of one-off overrides on top had drifted the surfaces apart. Design work kept terminating at the same wall — a spec came back as "the library can't do that," a compromise shipped, and over enough compromises the compromises were the product. The data-dense screens suffered worst: call logs and campaigns needed density and custom cells the library's table wouldn't give.

Operators don't think in graphs. They think in scripts, and the product was asking them to think in the wrong shape.

Why now

Every new customer needed hand-holding through their first agent, which doesn't scale past a handful of logos. The voice models had gotten good enough that the interface was the bottleneck, not the AI. And the redesign was the only moment the migration would ever get funded — nobody approves a quarter of "rewrite the components and change nothing." Coupled to a redesign, it's just how the redesign ships.

Research & framing

I interviewed ops leads at customer accounts directly, and worked backwards through support tickets and what the founders and CS team already knew — the recurring questions nobody had connected into a pattern yet.

I also studied how Bland, Vapi, Retell, ElevenLabs Agents, and [regional players — name them] structure agent creation. Nearly all of them design for a developer building on behalf of a customer. Hoomanlabs' users had no developer. That gap was the opportunity.

Then I walked the full lifecycle: an operator writes an agent, attaches a contact list, launches a campaign, reviews the calls that went badly, edits, relaunches. The reframe that reset everything: the loop is the product, not the launch. Creation was the moment the product had been designed for. Repair is the moment users actually live in.

Design principles

• Show the conversation, not the configuration. If it can be said the way you'd say it to a person, don't express it as a setting.
• A bad call points at its own cause. Review and repair belong on the same rail.
• Density is a feature, not a compromise. These are people reading hundreds of calls a day, not browsing.
• Own the primitives. A component we can't change is a design decision someone else already made for us.

User flow

The full agent lifecycle — blank canvas to a campaign that's actually working, plus the recovery path that closes the loop when it isn't. The dark nodes are the additions that turned a one-way launch into a loop.

Design solution

Three acts: the Agent Builder, the operational surfaces around a live campaign, and the systemic move — replacing the foundation all of it stands on.

Making a conversation something you can see

The canvas now starts from the happy path, not an empty graph. A new agent opens with a spine already laid down — greet, verify, ask, close — and branches grow out of it as the operator remembers the ways a real call goes sideways.

Each node holds two things: what the agent says, and what it listens for. The instructions field is framed as briefing a new hire rather than prompting a model — same underlying content, and it changed the sentences people wrote. [What changed, if you noticed it.]

The version that didn't work: a wizard. Before the canvas, I explored a step-by-step form builder — answer a sequence of questions, get an agent. It tested well right up until a conversation branched, which is immediately. Real calls fork on the second turn: wrong person, no answer, call me later. A wizard can express a sequence and not a shape, and a phone call is a shape. Killing it is what made the canvas non-negotiable.

From one call to a thousand

Transcript, recording, summary, and outcome on a single screen — the transcript as the spine, everything else anchored to timestamps in it.

The move that mattered: each transcript turn links back to the builder node that produced it. Reviewing a bad call is one click from fixing its cause. That link is what makes the loop in the flow diagram real rather than aspirational, and it's the improvement I'd point to first.

Hinglish shaped the transcript design. Calls code-switch constantly — a sentence starts in Hindi and lands in English. I render Hindi in Devanagari and English in Latin, mixed inline, exactly as the caller spoke it. Romanizing everything would have made a tidier column and a less true one; an ops lead scanning a transcript is checking whether the agent sounded right, and a transliterated sentence doesn't let you hear it. [What you traded to get this — font stack, line height, mixed-script alignment.]

Campaigns wrapped the launch itself: contact upload, scheduling, retries, pacing, live monitoring. [Compliance constraints — calling windows, DND — if they shaped the design.]

Insights answers the aggregate question the same way the call console answers the single one: drop-off by conversation stage, plotted against the flow the operator built rather than against abstract KPIs. A chart reading "62% of calls end at the identity-check node" names the problem, names the node, and puts the fix one click away. "Average handle time: 47s" names nothing. [Confirm this is the shape you shipped.]

Mantine → shadcn/ui, without a rewrite quarter

The systemic move. Mantine is a library you theme; shadcn is source you own — Radix primitives underneath for accessible behaviour, Tailwind tokens on top, and component files sitting in the repo where they can be edited. The practical difference: the design system stopped being a Figma file nobody opened and became variables the product actually reads.

Three things forced it. The surfaces had drifted apart — defaults plus years of overrides had left four screens that didn't look like one product. The theming ceiling meant Hoomanlabs couldn't look like Hoomanlabs. And the data-dense screens — call logs, campaigns — needed density and custom cells the library's table wouldn't give at any amount of configuration.

The strategy was to never let it become a separate project. One rule held it together:

No screen migrated without being redesigned. No redesign shipped on Mantine.

That coupling is why it's still moving. Migration work is the easiest thing in the world to defund halfway; attached to a redesign customers were waiting for, it has cover the whole way. We went surface by surface rather than big-bang, which kept every release shippable and meant the product was never half-broken in front of customers. [Which surface first, and why.]

The honest cost. We own the maintenance now. There's no upstream release that fixes our components while we sleep, and accessibility is our problem rather than a vendor's promise. [What you did about that.] Worth it, but it's a trade, not a free upgrade.

Process & iteration

Sole designer across all four surfaces, working with [N] engineers who built it. Owning research through launch meant the reframe survived the trip — nothing got translated into someone else's summary between the customer interview and the shipped screen. It also meant every unmade decision was mine, and there were a lot of them.

[N] iteration rounds per surface. The wizard exploration above was the biggest thing I killed; [anything else worth naming].

Impact

No clean before/after metrics — instrumentation landed after the surfaces did. What I have instead:

• The surfaces shipped, redesigned and migrated, live in production and still rolling forward.
• The product stopped looking borrowed. Four surfaces that read as one product instead of four eras of one.
• Sales changed how they demo. [What specifically changed — live builds instead of slides, a deal that turned on it.]
• Onboarding stopped needing hand-holding for a customer's first agent. [Or the specific support question that disappeared.]
• Design velocity changed shape. New surfaces stopped starting with "can the library do this."
• [The real customer quote goes here.]

Reflection

If I ran it again I'd migrate the shared primitives before touching any surface. Going surface-first put the user pain first, which felt right and meant the earliest screens got built on components that were still moving — some of them got redone. The boring layer first would have felt slower for a few weeks and been faster by the end.

The lesson that generalised: a redesign is the only affordable moment to replace a foundation, but inside that window the foundation still has to go first. Couple the two efforts to get the migration funded, then sequence them the other way round.