Maryam Mehrizi: A Product Designer

Approach

How I work — principles, rituals, and the frameworks I reach for.

I treat design as a business decision. That means writing things down, sharing trade-offs early, and being clear about what I am (and am not)optimizing for. This page exists so you know how I think before we ever get on a call.

Principles

Six things I optimise for on every project.

Frame before you design

Half of design work is rewriting the brief. I spend the first week turning a feature request into a problem statement with a success metric, and a working hypothesis about which user, which moment, which behaviour.

Decisions, not deliverables

I document trade-offs as a one-pager per project: the options, the chosen path, the rejected paths, the reason. Future me, PMs, and engineers can audit why we chose what we chose six months later.

Cheapest possible test

Five users on the right task tells me more than a week of synthesis. I'd rather ship a rough prototype this week than a polished mock next month. The unit of progress is a question answered, not a screen produced.

Design systems are leverage, not output

I contribute to shared systems when the same problem shows up three times — not before. Premature systems are tax, not asset. When I do contribute, I bring the token, the pattern, and the migration plan together.

Pushback is information

When a PM or engineer disagrees, the gap is usually a missing constraint, not a personality clash. I optimise for surfacing that constraint fast , through research recordings, journey maps, or a written rubric the team can argue with directly.

Cut more than you ship

Every project I run has a documented cut list. What got killed, what got deferred, what we said no to and why. Prioritisation is the part of the job that doesn't end up in the portfolio screenshot — so I keep the receipts.

Rituals

The recurring practices that keep teams aligned without ceremony.

Weekly trade-off doc

Every Friday: one page per active project covering open decisions, last week's calls, and the data behind them. Shared with PM and Eng leads.

PM/Eng pre-mortem

Before a major spec lands, I run a 30-minute pre-mortem: 'this shipped in 6 weeks and failed — why?' Surfaces 80% of risks cheaper than reviews do.

Design critique with constraints

I run critique by reading the constraints first, then the work. Forces feedback to engage with trade-offs, not taste.

Designer 1:1s with prompts

When mentoring, I send three questions 24 hours ahead. The 1:1 starts from their thinking, not mine.

Frameworks I reach for

A small toolkit, used often.

· JTBD (lightweight, behaviour-first) for problem framing

· Pyramid of intent — Functional → Usable → Pleasurable — for scope-cut decisions

· Trade-off tables with explicit rejected options for every meaningful decision

· Cognitive-load proxies (confusion moments / session) for rule-heavy enterprise UX

· Pre/post metrics paired with qualitative quotes — never one without the other

What I expect from a team

A PM who'll argue about the problem. An Eng lead who'll show me constraints early. A leader who measures outcomes, not output.

If that sounds like your team, we'll probably do good work together.