✦ How I Work

Research first. Always.

My process isn't a diagram on a wall. It's a set of commitments I make to every project.

"The most important design work happens before Figma is open."

The brief is never the problem.

Every project I've worked on arrived pointing at symptoms. 'Build a travel app.' 'Make our healthcare information accessible.' 'Create an investment platform for young Indians.' These are symptoms. The real problem — the disease — is always something underneath. My first job on every project is to ask why until the real problem surfaces. This takes time. It saves more time later.

Users are not a formality.

I've seen how quickly 'user research' becomes a checkbox — three interviews, an affinity map nobody looks at, and then straight to Figma. That is not research. That is decoration. I run structured interviews because I genuinely believe that 50 real conversations reveal things that no amount of expert assumption gets right. Every design decision I make has a user quote or a data point behind it.

Design that doesn't ship has failed.

Beautiful Figma files that never see production are not design work — they're art projects. I stay through development reviews, QA, and launch. I care about what actually reaches the user, not what I handed off.

✦ Process

Six phases. Never skipped.

My Six-Phase Process

Adapted for every project. Never skipped.

Phase 01

Discovery & Framing

⏱ 1–2 weeks depending on project scope

Before I agree on a brief, I question it. I run stakeholder interviews — not just with the person who hired me, but with the people closest to the problem. I do a competitive audit to understand the landscape. I define the actual problem statement collaboratively. I write the HMW (How Might We) questions that will guide the entire project. Nothing gets designed until everyone agrees on what problem we're solving.

Produces

Stakeholder interview notes & synthesis · Competitive audit (3–6 competitors, scored) · Problem statement (one clear sentence) · HMW questions (3–7, prioritised) · Project brief reframe document.

Key principle

If the client and I can't agree on the problem statement, we're not ready to design. I push this conversation until it's resolved.

Phase 02

User Research

⏱ 2–3 weeks

I recruit participants from the actual target audience — not convenience samples. I design a research guide with open-ended questions that avoid leading the witness. I run semi-structured interviews, usually 45–60 minutes each. I do think-aloud usability tests when there's an existing product to evaluate. I take detailed notes and record sessions with consent. Then I synthesise everything into an affinity map.

Produces

Research plan & screening criteria · Discussion guide · 8–50+ interview recordings · Affinity map · Research synthesis document · 3–5 user personas grounded in research · Current-state journey map.

Key principle

I never generalise from fewer than 5 interviews. I note outliers rather than discarding them — outliers often reveal the most important design opportunities.

Signature move

I read back my synthesis to participants. 'Is this what you meant?' catches misinterpretations before they become design decisions.

Phase 03

Define & Reframe

⏱ 3–5 days

This is the most underrated phase in most design processes. It's where I take everything I learned in research and turn it into design direction. I run a structured synthesis session — sometimes alone, sometimes with stakeholders — to extract the core insights and translate them into design principles. These principles are not vague ('make it simple'). They are specific, testable, and traceable back to research ('users make decisions based on emotional vocabulary, not category labels').

Produces

Core insight statements (5–8 key findings) · Design principles specific to the project · Reframed problem statement · Success metrics · North star concept in one sentence.

Key principle

A design principle that could apply to any product is not a design principle. If it doesn't specifically reflect what your users told you, write it again.

Phase 04

Ideation & Architecture

⏱ 1–2 weeks

Only now do I open a design tool — and even then, it's usually just paper first. I run structured ideation: crazy-8s for rapid generation, dot-voting with stakeholders for prioritisation. I sketch multiple directions before committing to one. I build the information architecture before I design a single screen. Structure is the hardest part. Once it's right, the screens almost design themselves.

Produces

Rough sketches · 2–3 distinct concept directions · Information architecture diagram · User flow diagrams · Navigation structure · Content hierarchy.

Key principle

I test the information architecture before I test any visuals. If users can't find things, it doesn't matter how beautiful the screens are.

Phase 05

Design & Prototype

⏱ 2–4 weeks depending on scope

Lo-fi wireframes first. I test them before I add any visual design. Wireframe testing catches structural and navigation problems cheaply — before I've invested hours in visual polish. Only after lo-fi is validated do I move to hi-fi. The hi-fi phase is where I build the component library, establish the design tokens, and ensure consistency across every screen. I prototype key interactions so they can be tested realistically.

Produces

Lo-fi wireframes (tested first) · Wireframe testing report · Hi-fi screens for key flows · Interactive Figma prototype · Component library with variants · Design tokens · Responsive versions · Motion notes for dev.

Key principle

I never show hi-fi to users who haven't first confirmed the structure works at lo-fi. Visual design creates noise in structural testing.

Phase 06

Testing, Iteration & Handoff

⏱ 1–2 weeks

I run moderated usability tests on the prototype. I recruit fresh participants — never people who saw earlier versions, unless I'm specifically testing learning. I use task-based testing, not 'what do you think of this?' I measure task completion, time on task, error rate, and confidence. I document every finding, prioritise by severity, and iterate. Then I hand off to development with enough documentation that the implementation matches the design.

Produces

Usability test plan · Test session recordings · Usability testing report with severity ratings · Iterated hi-fi designs · Developer handoff file with annotations · Component documentation · Post-dev QA review.

Key principle

I measure confidence, not just completion. A user who completes a task but feels uncertain has not had a successful experience.

Signature move

Post-launch: where possible I follow up with analytics review and a second round of user interviews. Design work is never finished — it's shipped.

How I Run User Interviews

Because most people do this wrong.

I never ask "what do you want?"

Users are experts in their own problems, not in design solutions. Asking 'what features would you want?' gives you a wish list, not insight. I ask about behaviour: 'walk me through the last time you...' and 'what happened next?' The insight lives in the gap between what people say they do and what they actually do.

I listen for the problem behind the problem.

When someone says 'the app is confusing' that is not an insight. That is a symptom. I follow up: 'What were you trying to do when you felt confused?' 'What did you expect to happen?' The real problem is always one or two 'why' questions deeper than the first complaint.

I recruit for diversity, not convenience.

I use screener surveys to ensure I'm talking to people across the experience spectrum — experts and beginners, different age groups, different contexts of use. Edge case users often reveal the most important design opportunities.

I take verbatim notes.

Direct quotes are data. My synthesis documents are full of verbatim participant quotes, not my paraphrase of them. The raw language users choose tells you something the cleaned-up version does not.

I synthesise collaboratively.

Where possible, I run the affinity mapping session with the broader team. When the people who will build the product have personally placed the sticky notes, they make better decisions in every conversation that follows.

My Process Stack

The tools that support the thinking, not just the making.

Miro

Affinity mapping, journey mapping, collaborative ideation, research synthesis boards.

Notion

Research documentation, project briefs, decision logs, client communication.

Zoom + Otter.ai

Remote moderated research with automatic transcription for efficient synthesis.

Maze

Unmoderated usability testing for task flows and first-click tests at scale.

Dovetail

Qualitative research repository for tagging, theming, and searching across sessions.

Loom

Async design walkthroughs for remote clients without a meeting.

See it in practice.

Every case study on this site documents the full process, not just the final screens.

Case Study

Roamer

Read how reframing the brief from 'travel app' to 'help people stay lost intentionally' changed every design decision.

View Case Study →

Case Study

Synapsis

Read how 50+ remote user interviews with new Canadian residents reshaped the entire information architecture.

View Case Study →

Case Study

Genderverse

Read how NASA TLX evaluation methodology proved the design worked before launch — and why that mattered.

View Case Study →

Want to see how this applies to your problem?

I'm happy to walk through my research approach before we've even agreed on a project scope. Understanding the problem together is where good work begins.

Start a Conversation →View My Work

Let's build something that matters.

Available for senior UX roles, freelance projects, and long-term collaborations.

Get In Touch →apranjal816@gmail.com