Bareerah Iftikhar
/ Methodology

How I ship — Frame · Explore · Ship · Hold.

Four phases, the decisions I make at each, the artifacts that leave my hands, and the numbers I hold myself to after launch. This is the shape of the work — not the marketing version.

/ Principles

Four commitments.

Sharpened across 43M-user consumer fintech, B2B onboarding at scale, and 0→1 PropTech built with AI. They apply to every phase below.

01

Research is a tool, not a ritual.

Studies exist to move a roadmap. If a test won't change a decision, I don't run it. A fifteen-minute call with the ops lead often gets us there first.

02

A design system earns its weight on Monday morning.

Tokens, components, and one shared vocabulary — measured in the Slack threads they end. I ship primitives an engineer can build against in an afternoon.

03

AI is a design material.

Not a feature bolted onto a screen. I design the loop between human intent and machine autonomy — when the product should defer, interrupt, or disappear.

04

The work isn't done at handoff.

Design ships when it's in production, instrumented, and holding under load. I sit with engineering through the sprint and check the funnel a week after release.

/ The four phases

Decisions, artifacts, outcomes.

Every case study on this site maps to this loop. Timelines flex; the phases don't.

01Week 1 · 3–5 days

Frame.

Get out of the brief and into the constraint. Before pixels, I nail down what actually moves the number, and what would prove we're wrong.

TARGET · WAGER · DISPROOF
Decisions
  • What's the one metric this quarter has to move, and who owns it after I leave?
  • Which users, ops workflows, and regulatory rails are non-negotiable — and which are assumptions dressed up as requirements?
  • The 60% we won't ship: the scope we cut on purpose so v1 can leave the building.
Artifacts
  • One-page problem memo — the target, the wager, the disproof condition.
  • 5–8 stakeholder & operator calls, synthesised into a single failure-mode map.
  • Baseline funnel + qual snapshot: where users drop, and what they say when they do.
Outcomes
  • A written thesis every function (eng, PM, ops, legal) can quote back.
  • Kill list of features we agreed not to build — signed off, not just discussed.
  • A number we're chasing, with the mechanism we believe will move it.
/ In practiceQashio · KYB rework
Artifact

PostHog funnel audit + 6 abandoned-applicant interviews synthesised into a single failure-mode map.

Decision

Named the real failure mode as "waiting on each other," not "the form is too long" — which killed the shorter-form redesign we'd almost committed to.

02Weeks 2–3

Explore.

Cheap divergence, fast convergence. Three real options in front of humans by day 5 — not one polished mock in week four.

Decisions
  • Which interaction model carries the load: form-first, table-first, canvas, or agent-in-the-loop?
  • Where AI defers vs. decides — and how the user takes the wheel back.
  • Which primitives get pulled into the system and which stay bespoke.
Artifacts
  • 3 divergent flows, prototyped to the point of clickable — not pretty, honest.
  • Concept tests with 5–7 users or operators; screen-recorded, timestamped notes.
  • Component + token plan, with a written rationale for each new primitive.
Outcomes
  • One direction chosen with the tradeoff written down — so nobody re-litigates it in month three.
  • Two directions killed with evidence, not opinion.
  • Design-system deltas queued for eng review before the sprint starts.
/ In practiceQashio · KYB rework
Artifact

Two rejected iterations — accordion sections, then a linear stepper — documented with the reasons each failed before the sectioned-tile approach earned sign-off.

Decision

Broke KYB into four sections with independent state and inline compliance comments — instead of a shorter linear form. The rejected iterations became the argument for why.

03Weeks 4–8 (varies)

Ship.

Design lives in the pull request, not in Figma. I pair with engineering daily, cut scope in the sprint, and instrument before launch — not after.

LIVE
Decisions
  • What ships in v1 vs. v1.1 — and what's a fast-follow vs. a fake promise.
  • Which states are worth engineering perfectly (loading, empty, error, offline) vs. good-enough.
  • The exact events, funnels, and thresholds we need to know if it's working on day 8.
Artifacts
  • Production-fidelity flows, with edge states, copy, and motion specced.
  • QA notes and a bug bar I sign off on personally — not delegated.
  • Analytics plan: events, funnels, guardrail metrics, and the dashboard link.
Outcomes
  • Feature live, instrumented, with a launch checklist closed by design + eng + PM.
  • A day-8 review scheduled before launch — not a maybe, a calendar hold.
  • Zero P0 regressions carried into the next sprint.
/ In practiceQashio · Receipt Inbox
Artifact

Internal usability run with the finance team on hundreds of real receipts — before general availability. Surfaced a missing preview panel in the map-receipt flow.

Decision

Added the preview panel and renamed status labels (Mapped → Attached, Unmatched, Duplicate) after beta feedback. Both shipped before GA rather than as a v1.1 promise.

04Weeks 9–12 + ongoing

Hold.

The interesting part starts after launch. I keep design accountable to the number for at least six weeks — patch, sharpen, or roll back.

LAUNCH
Decisions
  • Did the number move? If not, is the design wrong, the audience wrong, or the instrumentation wrong?
  • Which sharp edges get patched this sprint vs. absorbed into the next cycle.
  • What we retire — features that shipped and didn't earn their maintenance cost.
Artifacts
  • Post-launch memo: what shipped, what moved, what surprised us, what's next.
  • Prioritised patch list, with severity tied to the guardrail metric — not to loudness.
  • System updates absorbed back into tokens, components, and docs — so the next team gets the compounding.
Outcomes
  • The target metric moved — or we know exactly why it didn't, in writing.
  • A shorter next cycle, because the primitives and playbook already exist.
  • Confidence, not vibes, going into the next quarter's bet.
/ In practiceJazzCash · Send Money
Artifact

30- and 90-day post-launch reviews with product + growth, against a live funnel dashboard wired in during the ship phase.

Decision

Kept Send Money accountable to the transaction-success metric for a full quarter after launch — patched two friction points in the review step rather than declaring victory at +15% and moving on.

/ FAQ

How I run research.

The questions I get most from hiring teams and founders. Short answers, no tools grid, no rebranded double-diamond.

01

Do you always run a discovery phase?

No. If the roadmap is clear and the number is on the line, I go straight to Explore. A study exists to change a decision — if it won't, I don't run it. A fifteen-minute call with the ops lead often gets us there first.

02

How do you choose between qual and quant?

Quant tells me where the problem is; qual tells me why. I usually start with a funnel audit before I book any interviews, then interview the users the funnel is quietest about. Six moderated sessions is my default — enough to see a pattern, cheap enough to run in a week.

03

How do you research when there's no budget for user interviews?

Interview the team closest to the pain — Customer Success, Sales, Ops. They talk to the users I'd be talking to. I did exactly that for Qashio's Receipt Inbox, and the CSM session produced a pain-point map I could design against in the same week.

04

How do you know when research is enough?

When another interview stops changing the design. If interview five moves the flow and interview six only confirms it, I've hit saturation. If I still don't have a hypothesis I'd be willing to be wrong about, I keep going.

05

How do you handle stakeholders who don't want research?

I ask them what would change their mind. If nothing would, we don't need research — we need a decision memo. If something would, that's the study. Framing research as a way to close an argument, not open one, gets most teams to yes.

06

Do you write research reports?

Rarely. I write a one-page decision memo: the question, the evidence, the recommendation, the disproof condition. Reports live in Drive. Memos live in a Slack pinned message and drive the sprint.

/ See it applied

The deep cases live behind a request.

Public cases show the shape of the methodology. Confidential cases — the Qashio KYB rework, Receipt Inbox, the PropTech 0→1 build — include the decisions I can't publish. I'll share them with hiring teams and select clients on request.