mobile application
FINANCe MANAGEMENT
Real-time financial control for executives who can't be at a desk.
Real-time financial control for executives who can't be at a desk.
Real-time financial control for executives who can't be at a desk.
A Client needed their board to manage the company's entire financial operation, approvals, vendor dues, reconciliation, revenue , from a single mobile app. No existing product fit. We the designed from zero, building a platform complex enough to handle enterprise finance and simple enough to work for its users.
A Client needed their board to manage the company's entire financial operation, approvals, vendor dues, reconciliation, revenue , from a single mobile app. No existing product fit. We the designed from zero, building a platform complex enough to handle enterprise finance and simple enough to work for its users.
A Client needed their board to manage the company's entire financial operation, approvals, vendor dues, reconciliation, revenue , from a single mobile app. No existing product fit. We the designed from zero, building a platform complex enough to handle enterprise finance and simple enough to work for its users.
My Role
Product Designer
Platform
iOS + Android
Timeline
~2 Month
A conglomerate's finances were scattered across spreadsheets, calls, and disconnected tools
A conglomerate's finances were scattered across spreadsheets, calls, and disconnected tools
The board and chairman, a large Nigerian conglomerate, had no central system for financial oversight. Approvals went through calls. Vendor dues lived in spreadsheets. Reconciliation required someone to manually pull data from multiple sources. The company had the complexity of enterprise finance and none of the infrastructure to manage it on the go
The board and chairman, a large Nigerian conglomerate, had no central system for financial oversight. Approvals went through calls. Vendor dues lived in spreadsheets. Reconciliation required someone to manually pull data from multiple sources. The company had the complexity of enterprise finance and none of the infrastructure to manage it on the go
The brief was to build a single mobile platform that gave C-level executives real-time visibility and decision-making control across every financial dimension of the business. The constraint that sharpened everything came early: the primary users were older Nigerian male executives, accessing the product on phones, often in demanding environments. Small tap targets, dense type, and deep navigation were not viable.
The brief was to build a single mobile platform that gave C-level executives real-time visibility and decision-making control across every financial dimension of the business. The constraint that sharpened everything came early: the primary users were older Nigerian male executives, accessing the product on phones, often in demanding environments. Small tap targets, dense type, and deep navigation were not viable.
That constraint wasn't a footnote, it became the lens for every layout decision in the product. Large, forgiving tap targets. Cards as the primary interaction unit. Information hierarchies that answered the most important question first, before requiring deeper navigation. The insight arrived informally through a stakeholder conversation, but its implications were structural.
Design System. Built for one product. Designed to scale across four.
Design System. Built for one product. Designed to scale across four.
The design system decision was made with a scope larger than Finas alone. The same company had three additional products in the pipeline, all under the same brand, same visual identity, same user base. A system scoped only for Finas would have created four disconnected products. The decision was to build the foundation once, correctly, so every subsequent product could inherit it rather than reinvent it.
The design system decision was made with a scope larger than Finas alone. The same company had three additional products in the pipeline, all under the same brand, same visual identity, same user base. A system scoped only for Finas would have created four disconnected products. The decision was to build the foundation once, correctly, so every subsequent product could inherit it rather than reinvent it.
Before a single screen was designed, the complete system was established: color tokens mapped to semantic roles, a type scale built on Sora with defined weights for every information tier, spacing and radius values locked to a consistent grid, shadow definitions scoped to elevation levels, and a component library covering every card type, input state, status indicator, and interaction pattern. Within Finas itself, that same system kept two designers working in parallel producing output that read as a single unified product.
Before a single screen was designed, the complete system was established: color tokens mapped to semantic roles, a type scale built on Sora with defined weights for every information tier, spacing and radius values locked to a consistent grid, shadow definitions scoped to elevation levels, and a component library covering every card type, input state, status indicator, and interaction pattern. Within Finas itself, that same system kept two designers working in parallel producing output that read as a single unified product.
The system wasn't built to document what existed, it was built to scale what would be built next. Finas was the first product. The three that followed didn't need to establish their own visual language. They inherited one. That's the compounding value of a design system scoped beyond the immediate brief.
The home screen had one job: give a chairman the full financial picture in under ten seconds
The home screen had one job: give a chairman the full financial picture in under ten seconds
An executive opening Finas between meetings isn't browsing, they're scanning for what requires their attention right now. The dashboard had to answer three questions immediately: where does the money stand, what's waiting for approval, and is anything off. Anything that required navigation to discover was considered a design failure.
An executive opening Finas between meetings isn't browsing, they're scanning for what requires their attention right now. The dashboard had to answer three questions immediately: where does the money stand, what's waiting for approval, and is anything off. Anything that required navigation to discover was considered a design failure.
The layout was structured in strict priority order. Total balance at the top — the single most critical figure — followed by payables and receivables as immediate-read numbers. Pending approvals surfaced inline with actionable controls directly on the card, so a decision could be made without navigating anywhere. Bank report and revenue by source below that. Recent activity at the bottom for audit awareness. Every tier earned its position by frequency of need.
The layout was structured in strict priority order. Total balance at the top — the single most critical figure — followed by payables and receivables as immediate-read numbers. Pending approvals surfaced inline with actionable controls directly on the card, so a decision could be made without navigating anywhere. Bank report and revenue by source below that. Recent activity at the bottom for audit awareness. Every tier earned its position by frequency of need.
Surfacing approve and decline directly on the approval card wasn't a convenience feature. it was the entire product philosophy compressed into a single interaction. The executive's job is to decide, not to navigate. The detail screen existed for those who needed the audit trail. The action never required it.
Complexity wasn't reduced. It was organised.
Complexity wasn't reduced. It was organised.
The Outcome
The Outcome
10+
10+
Modules shipped under one cohesive design system
Modules shipped under one cohesive design system
0 → 1
0 → 1
Complete product designed and delivered from scratch
Complete product designed and delivered from scratch
2
2
Designers, one system, no drift across modules
Designers, one system, no drift across modules
What I’d Do Differently
What I’d Do Differently
Closer proximity to users earlier
Closer proximity to users earlier
C-level users were accessible but rarely consulted during early design. Getting structured input from them in the first few weeks would have sharpened decisions we had to revise later.
The decisions around what documents to require and how to sequence them were made on research and client input, not actual user testing. The gap between what a client thinks their users will accept and what users actually accept is often significant. Even a small round of testing with the target demographic would have sharpened those calls.
A scope freeze before the first screen
A scope freeze before the first screen
Modules were added progressively without a clear scope freeze. A tighter brief at the start would have reduced rework and let us go deeper on the highest-value areas first.
Modules were added progressively without a clear scope freeze. A tighter brief at the start would have reduced rework and let us go deeper on the highest-value areas first.
Location
Ahmedabad,
India
Socials
Contact
jaysuthar.design@gmail.com
Location
Ahmedabad,
India
Socials
Contact
jaysuthar.design@gmail.com