Mohit Singh
Contact

Process

How I move from problem to product.

I'm allergic to skipping the boring upstream work. Before anything gets shaped I want to know what users actually do, what the business needs the thing to do, and what the system underneath can plausibly carry.

Human-centred design holds the spine. Product thinking decides where it points. AI sits in there as another material I'm still figuring out how to shape well. The rest of this page is how that plays out in a real project.

Understand

Start from context, not from the canvas.

Before I shape anything, I want a real read on the user and the ground around them. I sit with product, engineering, data, and sales, then pair that with interviews, tickets, and analytics. The goal isn't a research deck. It's finding the truth that changes what we build.

  • — Watch what people do, not what they say they do. The two rarely match, and the gap is usually where the real problem lives.
  • — Old research counts. Support tickets and sales call notes are a faster, cheaper second study most teams forget they already have.
  • — Talk to the team who answers the angry emails. They can tell you the top five user frustrations in a sentence each.

Outcome

A grounded read on the user, the market, and the room.

  • Stakeholder Sync
  • User Interviews
  • Contextual Inquiry
  • Personas
  • Journey Mapping
  • JTBD
  • Competitive Audit
  • Heuristic Eval
  • Product Analytics

Define

Frame the real problem before anyone builds.

Insights pile up fast. The job here is to cut. I line them up against business goals, separate noise from signal, and write a problem worth a sprint. Most requests arrive as a solution in disguise — my work is to walk the team back to the problem underneath, before we polish the wrong thing.

  • — Read the brief twice. Once for what it says, once for what it's hiding — the framing usually leaks the assumption that needs questioning.
  • — Insights only matter once they're tied to a requirement. A finding without a decision attached is just trivia.
  • — A useful problem statement is one the team can actually argue about. If everyone nods and moves on, it's too vague to build against.

Outcome

A prioritised problem the team can rally around.

  • Problem Framing
  • Requirements Mapping
  • Feature Prioritisation
  • Hypothesis
  • Risk Mapping
  • Success Metrics
  • OKRs

Strategy

Pick a direction the team can repeat from memory.

I stop discovering and start deciding. A north star, a few bets, the metric we'll judge ourselves on. I sketch concepts, blueprints, and flows so the direction is something the team can point at, not just describe. Cheap to fix on paper. Painful once people are building.

  • — If the team can't repeat the direction in one sentence, it isn't one yet — keep rewriting it until the PM and the engineer say the same thing back.
  • — Trade more screens for fewer, clearer bets. Three concepts arguing with each other beats ten polished ones that all agree.
  • — Pick the metric before the feature. Otherwise the feature picks the metric, and you'll measure whatever happens to move.

Outcome

One direction the team can build behind.

  • Experience Strategy
  • North Star Concept
  • Service Blueprint
  • Information Architecture
  • Concept Models
  • Roadmap
  • Metrics Definition

Prototype & Test

Build it rough. Test it real.

Prototypes are the cheapest way to be wrong in public. Rough enough to provoke a reaction, real enough to test. For AI features I also fake the model — sample outputs, failure states, the moments where a user has to decide whether to trust it. Then I put it in front of five real users and let the design get corrected before engineering opens a ticket.

  • — Make it just real enough to be testable, not a click more. Polish at this stage hides the problems you came here to find.
  • — Prototype the model behaviour, not only the screen. The interface usually isn't what breaks trust — the wrong answer at the wrong moment is.
  • — A failed prototype is a finding. Five users struggling with the same step is louder than any opinion in the review.

Outcome

A design corrected by real use, not opinion.

  • Wireframes
  • Lo-fi & Hi-fi
  • Clickable Prototype
  • AI Behaviour Sims
  • Wizard-of-Oz
  • Usability Testing
  • A/B Testing
  • Accessibility (WCAG)

Systemise

Build a system, not a stack of screens.

By the third version of a button I'd rather extend a token than redraw pixels. Tokens, components, variants, a11y baked into the primitives. AI patterns get the same treatment — explainability, confidence, human override as reusable parts, not re-decided per feature. The system is how work stays coherent when more hands join.

  • — Design the primitives once, compose them everywhere. The third time you copy a pattern, it should already be a component.
  • — An a11y baseline at the component level beats fixing it screen by screen. Contrast, focus, keyboard, label — built in once, inherited by everything that uses it.
  • — Treat AI patterns like components, not features. If two surfaces handle low confidence differently, the user feels it as the product being inconsistent about its honesty.

Outcome

A system the next designer can build on, not around.

  • Design Tokens
  • Components
  • Variants & States
  • AI Trust Patterns
  • A11y Baseline
  • Documentation
  • Contribution Model

Build & Ship

Build the real thing. Then ship it carefully.

The build is part of design. Where it makes sense I vibe-code working prototypes with Claude Code and Cursor, so the prototype is the real thing and handoff shrinks to a conversation. From there I pair with engineering through QA, edge cases, and the trade-offs that surface at the wire. I stay in the PRs. Drift is small until it isn't.

  • — Use AI where speed beats certainty — generation, scaffolding, microcopy variants. Humans stay on direction, risk, and the calls the model can't make.
  • — Pair with engineering instead of handing off and walking away. The decisions made at 4pm on a Friday are where most experience leaks happen.
  • — Sweat the moments after launch as hard as the launch itself. Empty states, errors, slow networks, and quiet failures decide whether users come back.

Outcome

Working software in users' hands, with the design intent intact.

  • Vibe Coding
  • Claude Code
  • Cursor
  • Dev Pairing
  • Design Specs
  • Figma → Code Handoff
  • Design QA
  • Edge-Case Docs
  • Launch

Carry

Leave the team further along than you found it.

Shipping starts the next loop. I watch live data against the metric we picked in Strategy, write down what surprised us, and feed the lessons back into the team and the system. Workshops, walkthroughs, short writeups — whatever helps the next project start ahead of this one. Teaching also keeps me honest; explaining a decision out loud is the fastest way to notice it wasn't a good one.

  • — Write down what surprised you, not just what worked. The surprises are the cheap research the next project gets for free.
  • — Feed learnings into the system, not just the retro doc. A pattern that hurt users twice should change a component, not a slide.
  • — Teach the why, not the deliverable. The team will reuse the thinking on problems you'll never see.

Outcome

Shared understanding the next project can build on.

  • Telemetry
  • Post-Launch Measurement
  • Retros
  • Field Notes
  • Team Upskilling
  • Internal Talks

How I think

Six things practice has actually taught me.

Not a manifesto. Just the things I notice myself coming back to, across very different projects and very different rooms.

  1. 01

    Empathy is the work, not the warm-up.

    The shortest path to a worse product is designing from your own assumptions. Time spent watching real users is the actual job. Everything else is decoration on top of it.

  2. 02

    Clarity beats feature count.

    A product that does five things well is almost always more useful than one that does fifteen things poorly. The discipline is in what you cut, not what you add.

  3. 03

    Trust gets built in the dull moments.

    How a product handles failure, latency, and the edge case nobody planned for tells the user more about it than any onboarding ever will. I design for those moments first, not last.

  4. 04

    Upstream thinking saves downstream weeks.

    An hour spent naming the problem well saves a week of rebuilding the wrong thing. The boring upstream work is where the real leverage lives, and it's almost always under-resourced.

  5. 05

    Technology is a material, not the point.

    AI, code, design systems are materials I shape with. The point is what shows up on the other end for the person who has to use the thing. If the user can't feel the leverage, the technology didn't earn its place.

  6. 06

    One rough version beats five polished ones in Figma.

    I learn more from a thing that's actually out there, being used badly and getting feedback, than from a beautiful prototype nobody touches. Side projects keep me in that rhythm, and the day-job work gets better because of it.

When it makes sense

Want to think through a problem together?

Happy to talk through scope, framing, or whether the process fits at all, before anyone commits to anything.