Research through design

We ignored every rule my design school taught me. Yet Zeliot didn’t collapse. In design, structured processes, long discovery phases, deep user research, clear problem framing, perfectly polished prototypes, they’re ideal. But they’re also a luxury. In a startup, you rarely have that time. What you have are constraints and uncertainty. Clarity is partial and the pressure to move is constant. So we built, launched, observed, and adjusted on the fly. And through doing, we learned more than any textbook could teach us. This isn’t conventional wisdom. It’s earned. 

From Theory to Survival Mode 

Stepping into a startup right after design school broke my myth of clean design. 

In school, design is clean. Linear. Defensible. You move step by step and justify every decision. At Zeliot, process didn’t lead the work. Action did. We weren’t following a framework. Process emerged after the fact, shaped by constraints, speed, and what the market demanded that week. Structured processes, long discovery phases, polished prototypes, they’re ideal. But, they’re also a privilege most startups don’t have. We skipped research decks, detailed user journeys, and neatly mapped systems. Not because they don’t matter. Because in reality, we had to move fast.

If we were wrong, the launch could fail. Our reputation could take a hit. Users could churn. The product could flop. In a startup, mistakes aren’t academic. They’re expensive. 

And that’s the part no one romanticizes. It was messy. It was uncomfortable. It was risky. But it worked. 

The Prototype as Research   

Research Through Design vs Research For Design 

Research for design: study users first, then design. 

Research through design: design first to uncover the real problem. 

In startups, you rarely get the luxury of long discovery phases. The prototype is the research. At Zeliot, we treated every design cycle like a micro-process: 

Even here the process often started with brief dissection, the single most important step in turning chaos into clarity: 

1. Brief Dissection 

We’d take the incoming brief, usually high-level, ambiguous, and from sales, marketing, product, or customer teams, and break it into base-level points. This felt more like creating a brief out of a brief. 

The goal: extract what’s actually actionable, uncover hidden assumptions, and identify conflicting priorities. 

This often involved puzzling out tiny details that weren’t visible in the original brief. For example: “What does success look like here? Who exactly is the user? What constraints are non-negotiable?” Everyone had to participate. Stakeholders often argued; debates weren’t distractions, they were diagnostic tools. This step leveled the team, ensuring that the next phase of building started from a shared, grounded understanding instead of abstract theory. 

2. Tactical Brainstorming 

Short, focused sessions where rebuttals and debates clarified priorities and surfaced constraints (shoutout to my lead - Sachin for bearing with me during these). 

3. Prototype to Probe 

Using the refined brief, we built quickly: workshops, landing pages, program outlines, basically anything that could reveal real user motivation. Each artifact doubled as a research tool. 

4. Observation & Insight 

We observed how stakeholders and users responded. Questions, hesitations, and engagement surfaced motivations no report could capture. 

5. Iterate & Align 

Insights from the prototype informed the next brief. The cycle repeated, turning action into structured knowledge. 

Often, sales, marketing, product, and customer teams could debate strategy for hours, but the requirements were never framed from a product perspective, let alone design perspective. Our brief dissection leveled everyone down to actionable points, puzzling them into the actual design brief we’d next use to build. 

Action created insight. Somehow “making” became “research”. Learning wasn’t in reports, it was embedded in every artifact we produced. 

Pressure-Cooked Clarity 

Constraints That Shaped Our Process 

Startups are defined by what you don’t have. At Zeliot, our constraints didn’t block design, they shaped it. 

We were working with: 

• No time for deep ethnography 

• No budget for formal user studies 

• High uncertainty about markets and users 

• Constant pressure to deliver output 

These limits forced us to move fast and smart. They created rapid experiments, learning in the wild, and making thinking visible through artefacts. Every prototype, workshop, and launch doubled as a research tool. 

How We Responded:

• Ambiguity as Signal: Confusion wasn’t a problem; it was the cue to act. 

• Output as Thinking: Each artifact, copy, program, workshop captured our reasoning. 

• Public Reaction and Competition as Data: Stakeholder and user responses revealed hidden assumptions. 

• Narrative as Strategy: Storytelling and framing became tools to guide alignment and clarify intent. 

Constraints forced clarity by compression. Rapid cycles surfaced gaps that weeks of discussion might have hidden. Scarcity forced prioritization. Pressure made each move deliberate. 

In short: pressure-cooked clarity was our method. Not perfect, not tidy, but smart, adaptive, and functional under real startup conditions. Constraints didn’t block design. They shaped it.  

Where It Worked 

Impact, Not Process. Precisely what design schools detest. At Zeliot, the proof wasn’t in polished decks or perfect frameworks, it was in what actually worked. 

Leads came in from content and plans we hadn’t fully mapped. Engagement spiked in print media we hadn’t pre-validated. Workshops and events were applied in the field, influencing real decisions. And people actually used what we built, and they did so because the outputs met their needs, not because we had followed a textbook process. 

Every prototype, every launch, every quick brainstorm fed directly into impact. Our method didn’t produce neat process charts, it produced results. And that was enough to show that doing first, learning fast, and iterating constantly works when stakes are real. 

Seeing the Unseen 

Scrappiness worked, but it wasn’t perfect. Momentum sometimes hid uncertainty. Assumptions survived longer than they should have. These weren’t disasters. They were latent risks, reminders that fast, action-led design carries invisible tension. 

At Zeliot, nothing major ever backfired. Still, the lesson is clear: this approach works until it doesn’t. Alignment can feel like insight. Confidence can mask gaps. Every execution carries unseen risk. 

Recognizing these blind spots isn’t regret, it’s critical awareness. It’s knowing that speed and improvisation can produce clarity and impact, but only when paired with reflection and vigilance. 

Aligned in Motion 

At Zeliot, design is alive. It emerges from doing, not planning. Execution is research. Action is learning. Results speak for themselves. 

To be clear: I’m not condemning traditional processes. They’re valuable, and they work, especially when you have the time and resources to follow them. The goal here is to show that design can still work without them, and that in startups, the struggle is real, but it’s navigable with your own process. 

We skipped, launched, revealed, exposed, and pivoted. Momentum hid uncertainty. Alignment sometimes masked assumptions. And yet, through action, through artifacts, and through market reactions, we learned. We iterated. We delivered. 

None of this would have worked without a flat, collaborative team structure. Everyone could challenge ideas, speak their mind, and surface the gaps that the prototypes would later expose. The speed and trust in the team made tactical chaos possible and kept it productive. 

Startups don’t need more process. They need awareness of where research is actually happening. At Zeliot, it happens in execution, in prototypes, in live programs, and in the open, collaborative tension of a team aligned around action. That’s how clarity emerges. That’s how we win.