Mozhgan Akbari · Product Designer
Hard problems. Obvious screens.
Products shaped bywhat users actually do.
The decisions, not just the screens.
Each case shows the reframe, the evidence behind it, and the trade-offs I owned.
Selected screens.
Designing products where a wrong decision costs more than a bad experience.
The screen is rarely the hard part. The hard part is deciding what the system should make easy, and what it should make impossible.
Background
Six years of designing digital products across banking, fintech, and other platforms: corporate payment workflows, back-office tools, a multi-brand design system, crypto trading experiences, and automation tools for operators. What connects them is complexity and consequence, not one industry.
What the work looks like
Some of it starts from nothing: a design system, a rule builder for operators who do not write code, a feature nobody had scoped yet. Some of it starts inside a live product with real users, established workflows and technical limits. Both begin the same way, by understanding the problem before proposing a solution.
In practice
That means working closely with Product, Engineering, and Support. I look for evidence before proposing solutions, read support patterns to understand where users struggle, and stay involved through implementation because that is often where design decisions meet reality.
Now
I work on a corporate banking platform for organizational customers, designing complex financial workflows and internal back-office tools. In parallel, I share design ownership of several smaller, sensitive banking systems.
How I work.
Problems arrive tangled. I leave a structure the team can build on.
Evidence earns scope
I bring evidence, not opinion: support tickets and watching people work. That is what gets a team to rethink the problem.
Systems over screens
I design reusable components and tokens, so a problem solved once stays solved for the whole team.
Risk before polish
Where a mistake is costly, I first make the wrong action hard, then make the right one easy.
Trade-offs, documented
Every compromise is written down with its cost, so the next decision starts from context.
Designed to be adopted
I design within real constraints: existing code, operations and deadlines. If the team can't ship it, it isn't done.
Bring the team along
Engineering, product and support see the work early. A design they helped shape is one they’ll push to ship.
AI handles the volume. The judgment stays mine.
AI for volume, me for the risky part
Clustering a thousand support tickets is work nobody should do by hand. I let AI group them, then read the highest-risk cases myself before any of it became a design decision.
A prototype instead of a spec
Requirements become something clickable in hours. On a consumer banking bot, that let the PM and me settle scope the same day rather than argue about a document, and production UI reached handoff two days later.
A design team of agents
I built a multi-agent setup in Claude Code: a lead agent scopes the problem and briefs seven specialists across research, UI, design systems, testing and handoff, connected to Figma through MCP. Every output comes back to me.
AI speeds up my exploration. Evidence and judgment drive my decisions.
The next problem worth solving.
I'm considering product design roles where the work involves real complexity: regulated domains, enterprise tooling, fintech, multi-stakeholder systems. If you're building something where every decision compounds, let's talk.