Banking is complex.
The next step shouldn’t be.
Think about everything that needs to happen before a bank can open an account. Someone needs to find the right customer, collect the right information, and understand what still needs attention. My job was to make that work easier to follow.
I was the Sole Product Designer on Abaaly’s in-house Core Banking System. I owned the design end-to-end, connecting research, product structure, detailed workflows, and a shared visual language across customer and account work.
Team
Sole Product Designer · End-to-end ownership
Product, business analysis, engineering, QA, banking operations, compliance & risk
Links
Screens and decisions, below
Request a walkthrough of the product design.
A shared workspace connects customer records and the work around them.
Long tasks become a sequence people can understand.
Related journeys share patterns without losing their specific requirements.
Overview
Let me take you behind the counter.
A core banking system is where a bank manages the customer and account work behind its services. It is an operational workspace, used by people who need to be accurate while moving through a busy day.
The bank had outgrown parts of its subscription platform. Customization limits, integration constraints, vendor dependency, and ongoing costs were pushing it toward an in-house product. That created a bigger design question: how should this new system fit the way people actually work?
This was a new product, so I had to think beyond individual screens. A customer record, an onboarding flow, and an account journey had to make sense together. Otherwise, a polished interface would still leave people stitching the process together in their heads.
One designer. A whole product to connect.
Being the only designer meant carrying the thread from early discovery into the smallest interaction details. I worked on the information architecture, user flows, wireframes, interface design, prototypes, and reusable patterns. I also needed to explain how those choices supported the larger product direction.
I worked with partners across product, business analysis, engineering, QA, and banking functions. Their expertise shaped the constraints; I translated those constraints into an experience we could discuss at the level of a real task. Design ownership sat with me. Banking knowledge and delivery were shared work.
From discovery -> understanding requirments to detailed product design
Customer workspace -> onboarding -> and account opening
Challenge
Different responsibilities. One connected job.
The business wanted more control over its platform. The people using it needed something more immediate: a clear way to get through their work. I had to connect those two needs.
A customer service officer, an operations colleague, and a compliance specialist can look at the same record and need different things from it. Designing only for the person entering data would leave the rest of that journey unresolved.
Choose a perspective below to see the job the interface needs to support.
A customer service officer moves between finding a record, collecting information, and continuing the next task. The interface needs to preserve enough context that each transition feels connected.
A recognizable customer workspace and a clear entry into customer creation.
Can someone identify the right record and begin the correct next task without losing their place?
Operational work depends on knowing the state of a task. A completed screen is only part of the picture; the next person still needs to understand what is ready and what remains unfinished.
Visible task stages and consistent placement of the next action.
Can someone explain the current stage and continue the work without having to reconstruct the previous steps?
A simpler-looking interface cannot come at the expense of necessary checks. Risk and identity information still need a clear place in the journey, with enough context to support careful decisions.
Explicit identity, risk-profile, and review stages within the onboarding flow.
Can the relevant information be found and reviewed without treating a visually complete form as an approved customer?
That became the central tension: reduce the effort of understanding the interface while preserving the detail the job requires. Less on a screen is not automatically less work for the person using it.
Discovery & strategy
I started with the job, then shaped the screens.
I used stakeholder conversations, workflow reviews, branch observations, and requirements workshops to understand the operational context. Looking at the existing system helped me connect business requirements with the practical shape of customer and account tasks.
What mattered most was turning that learning into priorities. I kept coming back to three questions: where do people lose context, where does a task become hard to follow, and which patterns need to stay familiar as the platform grows?
Related customer and account tasks need a recognizable place to begin and return to. My priority: keep the product frame stable as the task changes.
A large set of requirements is easier to approach when related information is grouped meaningfully. My priority: show the current stage and the work still ahead.
New modules should not ask people to learn a completely different interface. My priority: reuse navigation and task patterns where they support the job.
The first thing I needed to design was the relationship between tasks.
I mapped the information architecture and explored how the dashboard could organize the platform. That helped me work at two levels: what someone needs in the current view, and how that view connects to the wider system.
For me, this is where systems thinking becomes practical. A navigation decision changes what is easy to find. A form structure changes what feels like one task. A shared component changes how consistently the next module can behave.
Design decisions
Here’s the thinking behind the interface.
Three choices hold the experience together: a stable workspace, a visible sequence for long tasks, and familiar patterns across related journeys. You can see the result in the screens. Open each decision to explore the reasoning and its trade-off.
01 / Keep the workspace stable as the task changes
The choice. I carried a consistent navigation and interface frame across customer and account work. The content changes with the task; the surrounding structure stays recognizable.
Why it matters. When someone moves from finding a customer to creating an account, they already have a sense of where they are. The interface can support that continuity instead of making every module feel like a separate product.
A stable frame can become crowded if every destination competes for attention. Consistency needs a clear hierarchy, not equal weight everywhere.
Ask someone to find a customer and continue a related task. Watch for pauses, wrong turns, or loss of context.
02 / Give customer onboarding a visible sequence
The choice. I organized onboarding into stages covering personal information, identity, address, risk profile, review, and OTP verification. The current step gets focus while the wider sequence remains visible.
Why it matters. A long form asks people to estimate how much work remains. A meaningful sequence gives them a clearer picture of what they are doing now and what comes next.
Splitting a form adds transitions. Returning to an earlier stage, preserving entries, and correcting errors need as much care as the forward path.
Ask someone to correct an earlier detail before review. Check whether the route back is clear and whether the information stays intact.
03 / Make account opening feel familiar, with its own rules
The choice. I used the shared product frame and a staged pattern for account opening. That creates a relationship with customer onboarding while keeping account-specific requirements visible.
Why it matters. Familiar patterns let people bring what they have already learned into the next task. The interface can spend more of its attention explaining what is different.
Familiarity can also create assumptions. A customer record and an account are different things; their labels, requirements, and confirmation need to make that distinction clear.
Check whether someone can explain what has been created, which customer it belongs to, and what still needs to happen.
The design system was part of the product work.
As the sole designer, I also had to think about what would happen after the first set of screens. Shared navigation, form patterns, and interface components gave the product a common design language.
The value was in the relationship between those pieces. If a pattern appeared in more than one workflow, it needed to behave in a way that made sense in both. I treated consistency as a way to support understanding, with room for the requirements of each task.
Solution
Take a look around. The details tell the story.
The product direction comes together across three connected moments: finding the customer, setting up their record, and opening an account. Switch between the views below, then open a screen for a closer look.
The customer workspace brings the record list, search, filters, and the entry into customer creation into one frame. It gives the next task a recognizable starting point.
At the risk-profile stage, the current task sits within a visible sequence. Earlier and upcoming stages give the screen its place in the journey.
Account opening uses the same visual frame and a recognizable staged structure. The information inside it belongs to the account being created.
A quick tour, if you prefer to watch.
This short presentation moves between the supplied design screens. It is a visual introduction; the full interaction paths will sit in the prototype. Play or pause it whenever you like.
The little moments worth showing in motion.
Outcomes & learnings
What I brought to the product and what I’d do next.
I turned a broad ambition for an in-house banking platform into a connected design direction. The work covered the structure of the system, the detail of customer and account journeys, and the patterns that joined those journeys together.
That is the contribution I want you to see here: I can take responsibility for a complex product, move between the system and the screen, and explain why the pieces belong together.
I made the direction concrete through information architecture, workflows, prototypes, and detailed interfaces that the team could examine.
I carried customer context and recognizable task structures across customer setup and account opening.
I established a common design language to support consistency as the product grows.
What this design brings together.
The design brings customer setup, progress, and account work into one connected workspace. To evaluate the next iteration, I would focus on accuracy, clarity of progress, and unnecessary backtracking.
My contribution was the end-to-end product design: a shared structure, connected workflows, and reusable patterns across customer and account work.
Three opportunities I’d explore next.
These are proposed directions, not features I am claiming to have shipped. Each one follows from the same goal: help people keep their bearings while doing careful work.
Explore a concise summary of what is complete, what needs attention, and who takes the next step.
Explore incomplete entries and correction paths, then test whether people can recover without starting over.
Test shared patterns with longer records and uncommon scenarios before extending them to more modules.
What this project changed about how I design.
I pay closer attention to the space between tasks now. A screen can be clear on its own and still leave someone unsure when they move forward. Designing across those transitions is where the product starts to feel connected.
I would bring the same care to evaluation as to the interface: watch someone complete a real task, understand where they hesitate, and use that evidence to choose the next improvement.