I make complex systems clear — for users, product teams, and the leaders funding them.

Hi, I'm Ashish. For the last thirteen years I've been drawn to the products most people would rather not open: claims platforms, accounts-payable systems, banking apps for customers who still trust a branch more than a screen. They're rarely glamorous. They're also where design changes someone's actual working day.

I started out designing marketplace and commerce interfaces, and for a while I thought the job was making screens better. Working on payments and banking taught me otherwise. At Genpact I spent 35 hours sitting beside invoice processors, watching them copy numbers between two windows because nobody had ever designed the space between those windows. That's when the work changed for me: the interface was fine; the process and the policy were the product.

Since then I've kept following that thread through consulting at EY and Accenture, service design at LTIMindtree, and now leading design across insurance, lending and digital services. My job is to make complicated systems legible — to the people doing the work, the engineers building it, and the leaders funding it. Usually that starts with research and constraints rather than screens, and treats service architecture, design systems and stakeholder alignment as the real deliverables rather than the finishing layer.

The work I'm proudest of usually began by questioning the brief. "The Store Locator bounces" turned out to be an adoption problem, not an interface one — nine in ten customers didn't know the feature existed, so a prettier map would have changed nothing. A claims "UI redesign" turned out to be four roles quietly coordinating over email because the service had no designed touchpoint between them. Getting those diagnoses wrong would have wasted a year of a team's life.

Leading a team hasn't pulled me away from the craft. I still sit in critique, still open the file, still argue about a component's states — because I don't think you can set a quality bar you can't demonstrate. What changes at this level is that you're designing the conditions too: how work gets prioritised, how decisions get recorded, how a system stays coherent when six business lines all want something slightly different this quarter.

Lately most of my curiosity goes into what AI does to our craft. Not the demos — the boring, useful parts: compressing research synthesis, drafting heuristic evaluations, catching design-system drift before it ships. I'd rather learn that medium by building with it than by having opinions about it, which is what the AI Lab is for. Some of it works. Some of it taught me where the limits are, which was just as useful.

I'm based in Pune and work with teams wherever they are. If you've got a product that everyone agrees is too complicated and nobody agrees how to fix, that's usually my kind of problem.