Mozhgan
Akbari.
I design products that cannot afford confusion.
Complex workflows, enterprise tools, systems at scale.
Designing products that already have users, constraints, and history.
Five years of designing enterprise banking, fintech, and operational products. Most of my work has been inside existing systems: products with real users, established workflows, technical limitations, and business constraints.
I enjoy working in those environments because the challenge is rarely creating the perfect solution from scratch. It is understanding what already exists, finding the real problem behind the request, and designing something the team can actually build and users can actually adopt.
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.
Currently, I work on a corporate banking platform used by 58,000 organizations, designing complex financial workflows and internal operational tools.
One pattern I've noticed in my own work: strong evidence before a decision, strong reflection after it, and not enough measurement defined before launch. I'm fixing that at the design stage rather than the retrospective.
The decisions, not just the screens.
Each case opens the reframe, the evidence behind it, the trade-offs I owned, and what I would do differently.
Selected screens.
UI design and 3D work. A look at the surface.
How I work.
Evidence earns scope
I don't challenge a brief because I disagree with it. I go get the data that gives the team a reason to reconsider it, then bring back a problem worth solving instead of an opinion.
Systems over screens
Component logic, token architecture, and a governance model the team actually uses. A design system is organisational memory: previously solved problems staying solved.
Trade-offs, documented
Live products force compromises. I make them deliberately, write down what they cost, and leave the reasoning behind, so the next person inherits a decision, not a mess.
Designed to be adopted
The cleanest model is worthless if the team needs a meeting to use it. I design inside the real constraint space (existing code, live operations, fixed deadlines) and optimise for what ships.
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.