Product: Namadeno
Platform: Mobile (iOS / Android)
Role: Product Designer (Full Ownership)
When I joined the project, SuperApp was in a complicated state:
The challenge was twofold:
User challenges: fragmented and confusing experience, lack of quick understanding of financial status and services
Team/Company Challenge: Lack of data and design, past ineffective project, need for independent decision-making
To start from this mess and build a reliable and scalable MVP that provides a simple, clear, and reliable user experience.
At the beginning of the project, there was no user data, usage reports, or previous research available. So I started the Discovery phase with a focus on stakeholder alignment and extracting the team’s tacit knowledge.
Instead of stopping because of a lack of data, I defined an operational research path.
Actions taken:
Since real user data was not available, pattern analysis and competitor comparisons became the basis for decision-making.
The analysis focused on:
Goal: To extract sustainable patterns and avoid repeating the mistakes of fragmented experience.
The output of the Discovery phase revealed several recurring patterns:
In fact, it wasn’t just a matter of designing multiple financial services, it was a matter of designing a single mental model for using multiple services in one app.
After the Discovery phase, it became clear that the main problem wasn’t just the multitude of services, but the lack of a single, understandable reference point for the user. Users needed to see their financial situation in one place before taking any action.
So I defined the product design direction based on a Dashboard-centric model — where the user first sees an aggregated picture of their assets and financial situation and then enters the services.
This decision allowed the experience to be shaped around the “user’s state” rather than a “list of services.”
The structure I defined:
The home page structure was defined as follows:
The purpose of this structure is to:
The design principles that led to these decisions:
To avoid reproducing the previous fragmented experience, I based my design on a few principles:
Given the lack of a usable previous structure, I designed the information architecture from scratch.
The goal was to bring together several disparate financial services into a coherent and predictable experience.
Instead of designing each service individually, I first defined a common structural framework.
I defined the product architecture in three layers:
1. Overview
Consolidated view of the user's financial situation: entry point and decision-making reference
2. Primary Services
6 main services with the highest priority and use: direct and fast access
3. Secondary and Micro Services
Infrequent or complementary services: access without creating cognitive clutter
This layering helped prevent service congestion on the home page, maintain scalability for future services, and create a clear mental structure for the user.
Designing a consistent user experience for services
Since all the services were under the same development team, it was possible to define a common flow pattern. So, I defined a consistent pattern for the services:
This pattern allowed:
Trade Offs
I rejected displaying all services on the home page at once: due to increased cognitive load
I limited the visual variety for each service: to maintain a cohesive experience
I removed excessive information from the dashboard: to prevent it from becoming a complicated reporting page
Building trust from the logo
I started with the logo gradient and turned it into a system:
The goal was to:
Elevating Main Dashboard Card
On the dashboard, there is a summary card that displays the following:
I decided to make this card visually dominant and separate from the rest of the elements because:
This wasn’t an aesthetic decision; it was a cognitive decision.
Structure of 6 main services
I ranked the top 6 services based on the following points:
I used the symmetrical grid pattern to:
I kept the microservices at a lower layer to:
From the very beginning of the project, two main tensions guided the design decisions. Every decision I made was a response to one of these two.
Challenge 1: Comprehensiveness vs. Simplicity
This product was a financial superapp. And superapps have a classic problem: the more services you have, the greater the risk of losing clarity.
If we showed all services on the front page:
But if too few services were displayed:
My Solution
Instead of adding or removing services, I layered the structure:
The Status card served as a cognitive stabilization point. The user first saw their status, then decided what to do.
This transformed the experience from a “list of services” to an “informed financial decision.”
Challenge 2: Consistency across different financial behaviors
The services varied greatly in nature, for example:
If each had its own unique experience, the user would have to learn a new pattern each time. In a financial product, this means friction.
My Solution
I defined a common flow pattern and this pattern was applied to all services:
Entry → Input → Review → Confirmation → Success
After using one service, the user used the others without stress.
The goal of this project wasn’t just to redesign the UI. The goal was to build clarity in a multi-service financial environment.
A clearer mental model
Before this structure, services were seen in a fragmented manner. After layering:
This reordering transformed the experience from “feature browsing” to “financial decision-making.”
Scalable Design Foundation
The visual system that was defined:
Stronger trust building
Unified visual identity and predictable behavior:
In fintech, Perception is a KPI in itself.
Reducing cognitive friction
The shared flow pattern resulted in:
In financial products, reduced cognitive friction = increased trust.
Designing without data taught me to focus on structure.
When I came on board, we had no behavioral data, no documented research, not even a successful previous version. In such a situation, the temptation is to quickly build a UI and move on.
But this project taught me:
When you don’t have data, you have to build a structure.
Instead of relying on numbers, I focused on enduring principles:
But even without these, building a cohesive foundation allowed the product to transform from a fragmented state into a scalable system.
This project for me wasn’t just about designing a super app. It was an exercise in:
Next, I would validate prioritization through behavioral data and refine service prominence based on usage frequency.
