Resume
Resume

Super App Admin Dashboard Design for Namadno Financial

Designing a management and control system for a multi-service financial ecosystem

Product / Department: End-to-end back-office panel design for CRM teams and the Namadeno product

Platform: Admin Dashboard (Desktop)

Role: Product Designer (Full Ownership)

Project Overview

After the expansion of the financial super app Namadno, with the increase in services and user growth, the need for a comprehensive and structured back-office panel became an operational necessity.
As a Product Designer, I was responsible for the end-to-end design of this dashboard for the CRM and Product teams.
This project was carried out over a period of several months and included:

  • Complex information architecture
  • Defining the access model
  • Standardizing operational patterns
  • Designing the financial status system
  • And aligning the needs of multiple teams with different logics

This was not a UI project. This project was designing an “operational control system” for a multi-service financial ecosystem.

Context and Complexity

SuperApp included the following domains:

  • Banking
  • Credit
  • Investing
  • Insurance
  • Wallet
  • Customer Club
  • Education and Content
  • Wealth and Asset Management

Each has:

  • Independent financial logic
  • Different operating cycle
  • Specific system conditions
  • And different risk levels

At the same time, the panel had to respond to two teams with different mindsets:

CRM Team

  • Focus on solving the user’s immediate problem
  • Quick access to histories
  • Possibility of operational intervention

Product Team

  • User Behavior Analysis
  • Performance Indicator Monitoring
  • Usage Patterns Analysis

Main challenge

How can a multi-domain system with high financial sensitivity be transformed into a structure that is both controllable and understandable?

Problem Framing

Initially, the panel was defined based on a list of services. However, this approach resulted in:

  • Scattered navigation
  • Hard to understand the overall system
  • Operator confusion between modules

The problem wasn’t just the variety of services; the problem was that each service had several different types of operations, status, and financial models.

The following areas also had financial and security risks:

  • Inventory management
  • External transaction review
  • User activity control
  • Roles and access management

At this point I decided to redefine the problem:

Instead of designing based on service, I should design based on “operational interaction type.”

Strategic Restructuring

I redesigned the information architecture in three layers:

Observability Layer

Dashboard, reports, user behavior, transactions Focus on the big picture and decision-making

Governance Layer

Role management, application management, wallet settings, capital management Focus on controlling the system structure

Execution Layer

All banking operations, investments, credit, insurance, users focus on direct action

Result:

  • Reduced cognitive complexity.
  • Specifieed the access level.
  • It clarified the operator's mental path.
  • Scalability made the future possible.

Role-based System Design

Given the financial nature of the system, accessibility design became a critical decision.
From the beginning, I based the design on the following:

  • Role hierarchy
  • Permission granularity
  • Module-level restriction
  • Action-level validation

This was the most time-consuming part of the project because:

  • Each financial domain required a different level of access
  • Some operations had direct financial risk
  • Human error had to be prevented

Financial System Challenges

The financial management sector was the most complex, including the following challenges:

  • Multi-step transactions
  • Different statuses (Pending, Failed, Settled, Reversed…)
  • Interaction with external services
  • Banking error management

I decided:

  • Define a standard State System for all transactions
  • Design a timeline-based transaction view
  • Enable multi-step verification for high-risk transactions
  • Include log visibility as part of the design experience

These decisions transformed the panel from a demonstration tool into a reliable system.

Design Systemization

Due to the large number of modules (more than 20 operational modules), if each of them had an independent structure, the system would be extremely unstable.
So I defined the following patterns:

  • Common Search Pattern
  • Status Display Pattern
  • Action Pattern
  • Logging Pattern

This standardization resulted in:

  • Reduce operator training time
  • Easier future development
  • Homogeneous work experience across the entire system

Time and Iteration

This project took several months and involved multiple iterations for the following reasons:

  • Multiple financial domains
  • Need to align with technical team
  • Review risk scenarios
  • Repeatedly redesign information architecture

A large portion of the time was spent on:

  • Redefining the structure
  • aligning with the product team
  • reviewing financial edge cases
  • and reviewing the access model

This project was not a quick design; it was a multi-stage analysis and redesign process.

Current status and impacts

The system is now implemented and fully connected to the CRM team.

Formal KPIs are being collected and will be measurable in the coming months.

However, structurally:

  • Established information architecture
  • Standardized access model
  • Manageable financial structure
  • The system is ready to develop new services

Key Learnings

  • Financial panel design is a “risk control” design, not just a page design
  • Security and accessibility must be built into the architecture from the beginning
  • The operator’s mental structure is different from the technical structure of the system
  • Complex systems require layering, not listing

Back to Home