The Setup
Freshworks (then Freshdesk) had built a successful customer support platform, but customers kept asking for phone support capabilities. Rather than integrate a third-party solution, the company decided to build its own cloud call center product: Freshcaller.
I joined as the sole designer on this zero-to-one initiative. There was no existing product to iterate on—just a business opportunity and a mandate to figure out what to build.
The challenge was designing for a domain I didn’t know. Call centers have complex workflows, specialized terminology, and users who spend their entire workday in these tools. Getting it wrong would mean building something that looked right but didn’t actually work for real call center operations.
The Bet
My bet was that understanding existing workflows—not imagining new ones—would be the key to a successful v1. Call center agents and managers had years of muscle memory from existing tools. Our product needed to feel familiar enough to adopt while being simple enough to differentiate from bloated enterprise competitors.
I proposed a research-first approach: interview existing Freshdesk customers about their phone support needs, understand their current call handling workflows, and identify the pain points we could solve. Only then would I start designing.
This seems obvious, but it wasn’t the default. The temptation in zero-to-one projects is to start sketching immediately based on competitive analysis. I pushed for user research before wireframes.
The Messy Middle
The research phase with Freshdesk customers revealed patterns I wouldn’t have guessed. Call center work is deeply interruptive—agents need to access information while actively talking to customers. Every click, every screen transition, every moment of confusion costs them. Speed and clarity trump features.
I started with wireframes, deliberately keeping fidelity low to explore different approaches quickly. The early concepts went through multiple rounds of testing with both internal employees and external customers. I built prototypes in InVision to simulate real workflows and watched users struggle through them.
One key insight from testing: the relationship between call history, contact details, and active conversations needed to be visible simultaneously. My early designs treated these as separate views, forcing users to navigate between them. The solution was a three-pane layout that kept everything accessible at once.
I also designed an embeddable widget version of Freshcaller that could be integrated into other Freshworks products or external applications. This required thinking about the product at two scales simultaneously: full application and minimal footprint.
The Outcome
Freshcaller launched and acquired its first paying customers. Over my three years on the product, we iterated based on customer feedback, adding features while maintaining the simplicity of the core experience.
The product is still active today at freshcaller.com, though it has evolved significantly since my time there. What I’m proudest of isn’t any specific feature—it’s that we shipped a functional product in a complex domain by doing the research upfront.
This project taught me the difference between designing for a domain you understand versus one you don’t. When you’re new to a domain, your intuitions are unreliable. Research isn’t just validation; it’s education. The wireframing and prototyping phase moved faster because I’d invested time understanding the problem space first.
My Role
I was the sole designer on Freshcaller for its entire zero-to-one phase. I conducted user research with Freshdesk customers, defined the information architecture, created wireframes and prototypes, did the complete visual design, and worked directly with frontend developers on implementation—including writing HTML and CSS myself.
The breadth of ownership was both challenging and formative. There was no design system to lean on, no established patterns to follow.
Working this closely with engineering shaped how I think about design handoff. When you’re writing code alongside developers, you understand implementation constraints viscerally. That understanding has made me a better collaborator on every project since.