Mozhgan
Akbari.
Designing clarity in complex systems.
Enterprise workflows, financial products, and design 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.
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 with opinion. I bring evidence that helps the team reconsider the problem, then align on what is worth solving.
Systems over screens
I design reusable decision systems, not just individual screens. Components, tokens, and governance turn solved problems into shared team knowledge.
Risk before polish
In high-impact workflows I make uncertainty visible before optimising the experience. The best decision is often preventing the wrong action, not just making the right one easier.
Trade-offs, documented
Live products require compromises. I make them explicit, document the cost, and leave the reasoning behind so the next decision starts from context, not confusion.
Designed to be adopted
The cleanest model is worthless if the team needs a meeting to use it. I design within real constraints: existing code, operational needs, and delivery pressure, because adoption is the measure of success.
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.