VisuallyMeta

Writing

Field Notes

Working notes, experiments and thinking on AI, product and design.

  1. Superadmin Revamp

    The requirement came after a partner wanted to be a middleperson and sell the dialer to their contacts. For this we need to share superadmin access to the partner. Now obviously we can't share everything with them.
    This is also a challenge, when we set up the dialer on-premise.

    I always ask my teammates to keep suggesting improvements and difficulties from time to time. I was already keeping tracks of changes required in superadmin and how it is too complex to use. But more the complexities these were the main points that made me go for revamp:

    • Security: We needed to define the roles properly within the organization to avoid any leaks, espionage, or mistakes to a tenant account that might hamper their organization.
      • Meta Data: To keep track of all the changes done to any tenant and by whom.
      • More layers of authentications like 2-factor.
        • Root Cause Analysis (RCA): If any tenant asks, about certain system related problem, instead of searching in database, we would be able to check this screen, download the complete call trace or multiple traces, and provide the RCA to the clients.
  2. When the requirements are met but the client still wants more

    Context: A bank needed a video calling and scheduling platform for its relationship managers, connected to its existing CRM, with notifications and support for customers in India and abroad. My job was to build a full working prototype, not mockups.

    Why banks need this now

    Two shifts made video banking a priority rather than a nice-to-have:

    1. Bank calls became one-way.
    TRAI now requires banks to make service and transactional calls from the dedicated 1600 number series, so customers can tell a genuine bank call from a fraudulent one. That helps with trust, but these numbers don't take incoming calls. A customer who misses an RM's call can't simply call back. The bank needs a channel where the conversation is scheduled and two-way.

    2. Banks are competing for NRI customers.
    The RBI's special FCNR(B) deposit window in 2026 let banks offer NRIs higher rates on foreign currency deposits, and lenders began engaging more actively with NRI customers across key overseas markets. Those customers are in different time zones and countries, often unable to visit a branch, and expensive to reach by international phone call. A scheduled video call with their RM fits their situation far better. socialnews

    Regulation made outbound calls more trustworthy but harder to call back. NRI demand made distance the main obstacle. Video banking addresses both.

    What I did

    • Built the prototype end to end with Claude Code.
    • Covered every requirement in the brief.
    • Demoed it live to stakeholders as a working product rather than a slide walkthrough.

    What happened

    The prototype met their needs as written in the brief. The client still wasn't satisfied. They wanted a "cherry on top": something beyond the brief, and in some cases beyond what current technology can do.

    Meeting the requirements isn't the same as meeting the expectation. A brief records what a client can put into words, not what they imagine.

    What I'm thinking about

    • Was the gap in the brief or in the moment? A working prototype makes the possibilities feel real, so the client starts imagining further. That reaction suggests the prototype did its job.
    • Separating the impossible from the unfamiliar. Some of what sounds impossible is possible but hasn't been done in banking yet. Finding the one feasible thing in the wish list could be the real cherry.
    • Where to draw the line. Chasing features the technology can't yet deliver risks the project. The skill is saying "not yet" in a way that keeps the client excited.

    Status: Open. Let's see where it goes.

  3. The clients ignored the charts

    What happened: I showed clients the redesigned monitoring dashboard: an Overview tab full of charts, and an RTM tab with five sub-tabs (Agents, Inbound, Outbound, Campaign, OBD). The Overview tab got almost no reaction. RTM got all the questions.

    What they actually asked for:

    • Which agents are idle right now?
    • Who has been on an unusually long call?
    • Which campaigns have run out of leads?
    • Filter inbound calls by queue status.

    Supervisors didn't want to see how the day was going. They wanted to know what needed their attention right now.

    What changed:

    • A right-side drawer for each row in Agents, Inbound, Outbound and Campaigns, with live actions in it: Monitor, Whisper, Barge.
    • Advanced filters for each tab, with an estimated record count shown before the filter is applied. Supervisors can see the size of a query first, which also keeps API calls efficient.

    Workflow note: Screens were built in HTML with Claude Code first, then ported into Figma for refinement.

  4. Analytics: Clara Dashboard

    We started on flat, comfortable ground. The scope for Analytics was strong — clean charts, solid metrics, everything a dashboard is supposed to have. We felt good. The line was steady and high.

    Then we fell into the hole.

    The problem was quiet at first, easy to miss: we had designed the whole thing from our side of the glass. We were thinking like people who build charts, not like people who live with results. And a customer who has run their Agentic AI Voice Platform for a month doesn't open Analytics to admire charts. They walk in carrying real weight — business questions:

    "Is my AI actually helping my business?"
    "Where am I losing opportunities?"
    "How can I improve my agents and campaigns?"

    Our beautiful scope had no answer to any of that. That was the bottom of the hole.

    Climbing out meant flipping the entire frame — designing for the people who'd actually use it, and more specifically, for the perspective each person brings based on their job:

    • The campaign / operations manager — "Is it working?"
    • The sales / growth owner — "Am I making money?"
    • The inbound / support lead — "Are we dropping the ball?"
    • The product / AI owner — "Does it feel good to the caller?"

    Once the questions led the design instead of the charts, everything reorganized around them. We came out of the hole standing higher than where we started — not with a prettier dashboard, but with one that actually answers for itself.

  5. Starting with Cloud Telephony

    Doing product design for the dialer is teaching me a lot. And with the world moving and adapting to AI, I'm taking a big risk. My deadline for Cloud Telephony is 20 days, and I want to use AI and Claude Code not just to design, but to implement the frontend directly. With current AI capabilities, it feels doable — in fact, I've already tried building a dummy app entirely with Claude Code.

    The risk is clear: if I commit to the AI approach and it fails, it derails my timeline and leaves me unable to fall back on designing and delivering in Figma within the deadline.

    But I'm going to give it a shot. Let's see.

  6. Starting with Clara Design

    Now that the information architecture is done and the full flow has been shared with every stakeholder — feedback folded in, use cases refined — I've started fine-tuning the design against our brand guide.

    The setup was half the fun: I connected the Figma plugin to Claude Code and handed over my design file, which it read and turned into a clean Markdown reference for Claritel's brand colors.

    Then I fed that same design file back into Claude Code and got to work. I also brought in Wonder — an AI-first design app — and was able to generate design directly from my inputs. A few skills pulled the weight along the way: emilkowalski/skill, /impeccable init, and Leonxlnx/taste-skill.

    Hope to share the result soon.

  7. Designed the Information Architecture

    Working on a user flow is one thing. Refining its information architecture — stress-testing every button, every feature, the core flow itself against our requirements — is another entirely. There was a lot to fine-tune. It felt like designing a car, then making sure people could actually open the door, sit down, and drive.

  8. Onboarding for Clara

    Designed this onboarding screen for Clara — and the process is worth talking about more than the output. I used Claude Code to build the frontend directly, pulling inspiration and code from ReactBits. No Figma first. No handoff. Just straight from idea to working interface. The workflow is shifting, and I'm leaning into it.

  9. Working on Clara

    Sat down with the product expert to map out Clara from scratch — user flows, feature set, the full architecture of an Agentic AI Voice platform. The kind of session where you walk in with assumptions and walk out with a completely different mental model of what the product needs to be.

  10. Empty states are a product decision

    I almost treated empty states as an afterthought. But when I started listing them out for Claritel, I realized every empty state is a moment where the user either gets unstuck or gives up.

    I catalogued 20+ empty states and success states, each with specific trigger conditions, headline copy, and CTAs.

  11. The layer AI won't add unless you make it

    Our left nav was a flat list of ~14 items. Technically fine. Design-dead. Audio Library sat invisibly disconnected from IVR Design — even though it exists to feed IVRs. No badges on actionable items, no grouping, no semantic relationships.

    AI shipped the list. It won't tell you the list has no meaning. Grouping related destinations, surfacing pending callbacks, giving inactive items a reason to relate to each other — that's the thinking you have to bring. The build is cheap now. Knowing what deserves to be built is the whole game.