Nobody cares how good you are at Figma

A new problem statement landed on my desk last week.

It wasn't a screen to redesign. It wasn't a flow to fix. It wasn't even a research project in the usual sense.

The product was already built. Design done. Development done. Sitting there, ready to meet real users.

And the ask was this:

"We have a career counselling bot. We need to pilot it on-ground across India. 3000+ UG students, multiple states, 40 course streams and many more. Tell us how. Build us the strategy."

And I froze.

For context: I'm not new to this. I've spent years doing on-ground user research across 11–12 states and 250+ districts — solo, across healthcare, education, justice, service delivery, agriculture, women's empowerment. I know context. I know users. I know how to read a room that doesn't share my language or my assumptions.

So this wasn't a freeze of inexperience. It was a freeze of recognition — that the question being asked wasn't the kind of question I'd ever been formally trained to answer.

The ask wasn't "go discover something."

The ask was "now that we've built it, test & prove it works — at scale, across diversity, with metrics attached."

Different muscle entirely.

Being good at Figma doesn't make you good at strategy

Here's what I've realised about my own work:

I'm great at two ends — the deep, contextual research at the start, and the executional craft at the finish. Wireframes, flows, prototypes, Figma. I can do both confidently.

But the bit after the product is built, before it scales — the validation strategy — I'd never owned end-to-end.

Discovery research, I know.

Usability testing on a wireframe, I know.

But designing a pilot for a finished product — one that has to survive contact with 4,000 students across 40 streams and test & prove it actually works for all of them, not just for English-speaking metro kids — that's a strategy job, not a design job. And nobody had taught me to do it.

I'd been calling myself a designer-researcher. Someone else had always defined the what gets validated and the what counts as success. I'd shown up brilliantly for the how.

Are you hiding behind your Figma file?

The more I sat with it, the more I realised the strategy had to answer three questions — and answer them in a way that connected. Not three separate exercises. One coherent thing.

Pillar 1: Who exactly are we validating this with?

The product was already built for "students." But that's a meaningless category at this scale.

I had to build a persona framework that was actually useful for validation, not pretty for slides. Seekers, Builders, Deciders — mapped to academic year, mapped to specific pain points. A first-year B.A. student who feels she's in the wrong course is a completely different validation case than a third-year Btech student a month away from placement. If the product works for one and fails the other, that's not "a 50% success rate" — that's a critical insight about who the product is actually ready for.

Personas as the unit of validation. Not decoration.

Pillar 2: How broadly do we have to test it for the answer to be honest?

If the pilot accidentally only captures English-speaking metro students from one or two cities, the data lies. We'd celebrate a "successful pilot" that would fall apart the moment the product hit a Tier-3 college in Bihar.

So I had to design diversity coverage deliberately — stratified sampling across geography, language, gender, urban vs rural, institution type, and course stream. 4,000 students, 40 course strata, mapped to real enrolment ratios from AISHE data. Not "let's get a diverse sample" as a value statement — here's the structure that forces diversity into the sample whether we like it or not.

Diversity as a sampling constraint. Not a sentiment.

Pillar 3: What does "the product approach works" actually mean?

Not "users liked it." That's the most useless metric in product validation.

I had to define concrete success thresholds — psychometric completion rates, average message depth per persona, pivot clarity for the "accidental student" segment, recommendation satisfaction above 85%. Tied to personas. Tied to the things the product was claiming it could do.

If we hit these, the approach scales. If we don't, we know exactly which persona, which stream, which geography it failed in — and what to fix next.

Success as a falsifiable claim. Not a vibe.

Here is the doc if someone really wants to get into it <Pilot Strategy>
 

I knew how to do every individual piece of this. What I didn't know was how to weave the three pillars into one coherent validation strategy that a business team could fund and a partner team could execute.

That's the gap. Not skill. Synthesis.

Nobody teaches the part that actually matters

Think about how most of us grow as designers — even those of us with deep research backgrounds.

Bootcamps, internships, projects, even years of fieldwork — they teach you the craft. How to interview. How to synthesise. How to wireframe. How to prototype. How to push pixels until they're crisp.

Nobody runs a course called "How to take a finished product and design the strategy that proves it works at scale."

Because that part isn't a tutorial. It's a muscle. And you only build it by doing it badly a few times first.

The result is a generation of designers — including senior ones — who can produce beautiful deliverables, who can run beautiful research, but who still go quiet the moment someone asks: