Re-architecting a complex accounting SaaS around how people actually work.
An accounting and GST platform used by business owners, accountants and chartered accountants. The engine was powerful; the experience exposed too much of it. I rebuilt the product's information architecture, design system and invoice workflow — and the design function around it.
Outcome snapshot
The redesign created measurable movement.
Product context
Accounting software shouldn't require an accountant to operate a business.
Munim is an accounting and GST platform that helps businesses and accounting professionals manage sales, purchases, inventory, financial records, and GST workflows.
It serves an entire ecosystem, not one user:
Business owners → Employees → Accountants → Chartered Accountants
The underlying accounting engine was already powerful. The challenge was making that power understandable.
Before Munim 2.1
The product was powerful. The experience exposed too much of that power.
Many users arrived from traditional accounting software like Tally, carrying established expectations with them. The interface surfaced dense forms, complex accounting logic, and large data structures — sometimes on older, low-resolution computers.
A single invoice could expose 20+ input fields and accounting logic in one view.
The challenge wasn’t a lack of functionality. It was the translation between system complexity and human understanding.
Problem map
Munim had a product problem disguised as a UI problem.
EXPERIENCE Poor navigation · weak information hierarchy · complicated forms · long workflows · poor onboarding · low discoverability · weak feedback · difficult error recovery.
PRODUCT The dashboard didn’t align closely enough with what users actually needed · invoice creation exposed too much complexity · large tables were hard to read · search was limited · existing accounting functionality was difficult to operate.
DESIGN INFRASTRUCTURE No coherent Figma architecture · no formal design system · inconsistent components · duplicate patterns · poor responsive foundations · inconsistent implementation.
Discovery
I started with evidence, not assumptions.
I pulled from several sources at once, because a single source always tells a flattering story.
- GA4 — product usage and behavior
- Microsoft Clarity — heatmaps and behavioral observation
- User interviews — people actively running their businesses on Munim
- CA research — Chartered Accountants and domain experts
- Support — recurring frustrations and support signals
- Stakeholders — business expectations and competing hypotheses
Users
Different users. Different mental models. One product.
Business owners — need visibility and control without becoming accounting experts. Chartered Accountants — need accurate financial information and efficient accounting/GST workflows. Accountants — manage day-to-day records and data entry. Employees — work with sales, purchases, inventory, and business records. Administrators — need broader system control.
Behavioral signals
The strongest signals came from behavior.
Users repeatedly interacted with Sales Invoice, Customer, and Stock.
They struggled with invoice creation, customer onboarding, and financial reporting.
Insight: some business owners relied on their CA to create invoices — which created a dependency between the person making the transaction and the person recording it.
The turning point
I thought I was redesigning an interface.
I was actually redesigning a mental model.
Users were bringing established accounting habits and expectations into Munim. The product was exposing its internal complexity instead of translating that complexity into understandable workflows.
Design around the user’s mental model — not the system’s internal architecture.
Prioritization
I turned observations into an execution system.
There were more problems than the team could solve at once, so I prioritized by impact × effort × urgency — solve what moves the product first, polish what doesn’t, later.
MEDIA / IMPACT–EFFORT MATRIX — invoice creation, onboarding, information architecture, tables, search, visual polish.
Hero workflow
Reimagining the workflow at the center of the product.
Invoice creation was one of the most important workflows in Munim, and the interface exposed a large amount of accounting functionality at once.
For users, that created a simple question:
Where do I start?
The workflow problem
The person closest to the transaction wasn't always the person creating the record.
Some business owners relied on their CA to create invoices. That created a gap between the person making the sale and the person recording it — and the CA might not know what was sold, to whom, or when.
The result was extra reconciliation effort on both sides.
Business Owner → Transaction → missing or delayed record → CA → Reconciliation → GST
The problem wasn’t only usability. It was workflow integrity.
Design hypothesis
What if the product didn't assume accounting expertise?
A user should be able to understand Munim’s core capabilities without needing an accounting expert beside them.
Design goals
- Reduce cognitive load
- Establish hierarchy
- Simplify invoice creation
- Improve discoverability
- Preserve accounting power
- Introduce complexity progressively
- Make core actions understandable
Exploration
I explored the problem before committing to a solution.
I studied established accounting products and workflows — Zoho Accounting, Vyapar, QuickBooks, and others — not to copy them, but to understand information hierarchy, invoice patterns, interaction conventions, accounting workflows, and the expectations users were already carrying.
Solution direction
From "everything at once" to "the right thing at the right time."
01 — Clear hierarchy. Make important information obvious. 02 — Progressive complexity. Expose advanced capability without overwhelming the first interaction. 03 — Strong grouping. Organize related information into meaningful sections. 04 — Predictable interaction. Keep important actions visible and consistent. 05 — Responsive foundations. Design for the hardware users were actually working on.
Before → After
One workflow. Rebuilt around the user.
| BEFORE | REASONING | AFTER |
|---|---|---|
| Dense | Group | Clear hierarchy |
| Complex | Prioritize | Focused workflow |
| Low hierarchy | Progressively reveal | Predictable interaction |
| High cognitive load | Simplify | Reduced cognitive load |
MEDIA / BEFORE + AFTER INVOICE — the strongest frame in the case study. Give it room.
System first
I didn't redesign the product screen by screen.
I redesigned the system behind the screens.
The existing Figma environment had no coherent architecture and no formal design system. Components and patterns were inconsistent. Before scaling the product, I established the foundations required to design it consistently.
Design system architecture
The system became the blueprint.
FOUNDATIONS — typography · color · spacing ↓ TOKENS COMPONENTS — buttons · inputs · tables · dropdowns · forms ↓ PATTERNS ↓ PRODUCT FLOWS ↓ SCREENS
The design system was not simply a component library. It became shared product infrastructure.
Why the system mattered
Four people had four reasons to care.
Designers — reusable patterns and faster decisions. Developers — clearer implementation behavior. Product — a shared visual and interaction language. Users — more predictable interactions.
Before building more screens, build the system that makes better screens possible.
Designing for reality
Responsive design wasn't a visual preference. It was a product requirement.
Some CA users worked on older, lower-resolution machines, so the interface had to work inside real hardware constraints — not a designer’s 5K monitor.
I designed with auto layout, component states, structured spacing, responsive behavior, and reusable patterns.
Prototyping
When the interface is complex, static screens aren't enough.
The invoice experience contained multiple states, inputs, and interactions. Interactive prototypes let stakeholders and developers understand the workflow, the interaction, validation, states, and responsive behavior — before a line of code existed.
Design × Engineering
A design isn't finished when it looks good in Figma.
The product needed to be understandable, buildable, maintainable, and scalable. I worked closely with developers to translate design architecture into implementation.
Workflow: Problem → Research → Hypothesis → Prototype → Engineering review → Iteration → Development → QA → Release
MEDIA / FIGMA + CODE — split-screen: design on one side, implementation on the other.
Validation
I didn't want stakeholders to approve a picture.
I wanted them to understand the experience.
Prototypes created a common language between design, product, engineering, stakeholders, and users. After release, GA4 and Clarity were used to observe how the redesigned experience actually behaved.
MEDIA / PROTOTYPE + CLARITY — prototype left, behavioral evidence right.
Outcome
The product gave us signals after launch.
~15K → ~50K
Users
100K+
Invoices per month
~60s → ~30–40s
Invoice creation
9
Designers led
Reported project measurements from the Munim period.
Product transformation
The transformation wasn't one screen.
Before: space-heavy navigation · weak hierarchy · complex workflows · inconsistent components · no coherent Figma architecture · difficult invoice creation · large data structures · limited discoverability · inconsistent implementation.
After: clearer navigation · structured hierarchy · more user-oriented workflows · reusable component system · structured design foundation · simplified invoice experience · better information presentation · clearer interaction patterns · stronger design–development alignment.
Design leadership
The system couldn't live inside my Figma file.
It needed to live inside the team.
I led 9 designers and reviewed work across the design function, identifying inconsistencies in components, auto layout, design structure, interaction patterns, and product thinking. I introduced clearer boundaries, documentation, and reusable patterns so the team could work inside a shared system.
A design system is successful when the whole team can make consistent decisions without depending on one designer.
From design system to AI workflow
The design system later became more than a design system.
The original Munim 2.1 work predates most of my current AI-assisted workflow. But the structured foundation created something valuable: a consistent system that could later be read and reused by AI-assisted tools.
Design System → Documentation → Structured rules → LLM / AI workflow → Design exploration → Prototype → Code
Be explicit about the timeline: Munim 2.1 was not originally designed with AI. This is the later evolution of the system and of my practice — don’t let the page imply otherwise.
Learning 01: Architecture
Strong products need strong foundations.
When the foundation is weak, every new feature increases complexity. A strong architecture creates space for better product decisions.
Weak foundation: more features → more complexity. Strong foundation: more features → more reusable structure.
Learning 02: Domain knowledge
Domain knowledge changes design quality.
Accounting is a domain where small misunderstandings have meaningful consequences. Working alongside CAs and real users taught me the difference between designing an interface and designing a workflow people can trust.
Learning 03: Evidence
Evidence makes design decisions stronger.
Observation → Evidence → Reasoning → Decision → Measurement
There will always be multiple opinions. The job of product design is to turn evidence into repeatable decision-making.
The bigger change
Munim 2.1 wasn't just a visual redesign.
Before: Feature → Screen → Development. After: Problem → Evidence → Hypothesis → System → Experience → Validation → Outcome.
The role of design shifted from “make the interface better” to “make better product decisions.”
Final result
From a CA-centric accounting experience toward a more user-oriented product.
Munim already had a powerful accounting foundation. My contribution was to build the layer that connected that capability to how people actually worked.
Outcomes
- Stronger product architecture
- Scalable design system
- More understandable workflows
- More structured invoice experience
- Responsive and prototype-ready foundations
- Evidence-based product decisions
- Stronger design–development workflow
- A shared design language across a 9-person design team
Closing
I didn't redesign Munim to make accounting software look better.
I redesigned the experience so the power of the product could become accessible to the people using it.
Mitul Jetani — Product Designer
Project details
| Project | Munim Accounting |
| Company | Identixweb |
| Role | Senior Designer → Product Design Lead |
| Team | Design · Product · Engineering · Marketing · CAs · Active users |
| Design team | 9 designers |
| Disciplines | Product Design · UX Strategy · Research · Information Architecture · Design Systems · Prototyping · Analytics · Developer Collaboration · QA |
| Tools | Figma · GA4 · Microsoft Clarity · PostHog · Adobe tools · AI-assisted workflows |