John Konnakkottu

The Challenge

Although the product was still in its conceptual phase, the preexisting design already felt dated and inconsistent. The color palette and interface design didn't convey the trust or professionalism expected in a product that would handle large financial transactions.

We returned to the drawing board to turn the product into something credible and clear - something that could be used confidently in investor demos and customer pitches while preparing the foundation for a full product development cycle.

The Challenge

Although the product was still in its conceptual phase, the preexisting design already felt dated and inconsistent. The color palette and interface design didn't convey the trust or professionalism expected in a product that would handle large financial transactions.

We returned to the drawing board to turn the product into something credible and clear - something that could be used confidently in investor demos and customer pitches while preparing the foundation for a full product development cycle.

The Challenge

Although the product was still in its conceptual phase, the preexisting design already felt dated and inconsistent. The color palette and interface design didn't convey the trust or professionalism expected in a product that would handle large financial transactions.

We returned to the drawing board to turn the product into something credible and clear - something that could be used confidently in investor demos and customer pitches while preparing the foundation for a full product development cycle.

Approach

I started with the basics - a design system in Figma that defined type, color, spacing, and reusable components. Once that was in place, designing screens became quick and consistent.

Using our product requirements and user insights from over 30 interviews with potential customers, I mapped out the key workflows for account creation, single payments, batch payments, approvals, reporting, auditing, customer management, and vendor management. I studied similar products like Stripe and LemonSqueezy to identify established patterns that could work in our market.

Senior leadership and I huddled weekly to review progress and strategy, while I shared more detailed Loom updates on the design with the broader team. Because the development team worked primarily in French, I documented components and interface text in both English and French to keep communication clear.

Approach

I started with the basics - a design system in Figma that defined type, color, spacing, and reusable components. Once that was in place, designing screens became quick and consistent.

Using our product requirements and user insights from over 30 interviews with potential customers, I mapped out the key workflows for account creation, single payments, batch payments, approvals, reporting, auditing, customer management, and vendor management. I studied similar products like Stripe and LemonSqueezy to identify established patterns that could work in our market.

Senior leadership and I huddled weekly to review progress and strategy, while I shared more detailed Loom updates on the design with the broader team. Because the development team worked primarily in French, I documented components and interface text in both English and French to keep communication clear.

Approach

I started with the basics - a design system in Figma that defined type, color, spacing, and reusable components. Once that was in place, designing screens became quick and consistent.

Using our product requirements and user insights from over 30 interviews with potential customers, I mapped out the key workflows for account creation, single payments, batch payments, approvals, reporting, auditing, customer management, and vendor management. I studied similar products like Stripe and LemonSqueezy to identify established patterns that could work in our market.

Senior leadership and I huddled weekly to review progress and strategy, while I shared more detailed Loom updates on the design with the broader team. Because the development team worked primarily in French, I documented components and interface text in both English and French to keep communication clear.

Design Decisions

A lot of small design choices shaped how JoonaPay feels, but one of the most important was the payment modal.

In the first wireframe iteration, single and batch payments were treated as two separate flows. It seemed logical at first - each had slightly different steps and approval paths. But as we started sketching and reviewing the wireframes, the duplication became obvious. Maintaining two nearly identical flows would complicate both the interface and development.

I simplified the structure to a single, unified modal. A payment would start as a single transaction by default, and become a batch payment automatically when the user added more vendors. This kept the mental modal consistent while reducing friction. The user never had to design between 'single' or 'batch' upfront - the interface adapted naturally to their action.

The change also made approvals and scheduling more consistent. Both now share the same logic, with clear visual hierarchy for payer, payees, and timing. In testing with internal stakeholders, this design felt simpler and faster to use while still handling the same complexity under the hood.

Beyond the modal, other design decisions followed the same principle: reduce choice friction and make the interface feel predictable.

The command bar gives users global access to search, navigation, and frequent actions without leaving their workflow.
Table layouts use consistent column logic across modules, so sorting and filtering behave the same everywhere.
Dialogs, toasts, and confirmations all share one interaction pattern, minimizing cognitive load across the product.

Each of these decisions, and many more, were small in isolation but together made the interface feel stable and familiar.

Design Decisions

A lot of small design choices shaped how JoonaPay feels, but one of the most important was the payment modal.

In the first wireframe iteration, single and batch payments were treated as two separate flows. It seemed logical at first - each had slightly different steps and approval paths. But as we started sketching and reviewing the wireframes, the duplication became obvious. Maintaining two nearly identical flows would complicate both the interface and development.

I simplified the structure to a single, unified modal. A payment would start as a single transaction by default, and become a batch payment automatically when the user added more vendors. This kept the mental modal consistent while reducing friction. The user never had to design between 'single' or 'batch' upfront - the interface adapted naturally to their action.

The change also made approvals and scheduling more consistent. Both now share the same logic, with clear visual hierarchy for payer, payees, and timing. In testing with internal stakeholders, this design felt simpler and faster to use while still handling the same complexity under the hood.

Beyond the modal, other design decisions followed the same principle: reduce choice friction and make the interface feel predictable.

The command bar gives users global access to search, navigation, and frequent actions without leaving their workflow.
Table layouts use consistent column logic across modules, so sorting and filtering behave the same everywhere.
Dialogs, toasts, and confirmations all share one interaction pattern, minimizing cognitive load across the product.

Each of these decisions, and many more, were small in isolation but together made the interface feel stable and familiar.

Design Decisions

A lot of small design choices shaped how JoonaPay feels, but one of the most important was the payment modal.

In the first wireframe iteration, single and batch payments were treated as two separate flows. It seemed logical at first - each had slightly different steps and approval paths. But as we started sketching and reviewing the wireframes, the duplication became obvious. Maintaining two nearly identical flows would complicate both the interface and development.

I simplified the structure to a single, unified modal. A payment would start as a single transaction by default, and become a batch payment automatically when the user added more vendors. This kept the mental modal consistent while reducing friction. The user never had to design between 'single' or 'batch' upfront - the interface adapted naturally to their action.

The change also made approvals and scheduling more consistent. Both now share the same logic, with clear visual hierarchy for payer, payees, and timing. In testing with internal stakeholders, this design felt simpler and faster to use while still handling the same complexity under the hood.

Beyond the modal, other design decisions followed the same principle: reduce choice friction and make the interface feel predictable.

The command bar gives users global access to search, navigation, and frequent actions without leaving their workflow.
Table layouts use consistent column logic across modules, so sorting and filtering behave the same everywhere.
Dialogs, toasts, and confirmations all share one interaction pattern, minimizing cognitive load across the product.

Each of these decisions, and many more, were small in isolation but together made the interface feel stable and familiar.

Design System Detail: Indicators

Most of the product decisions in JoonaPay were guided by a shared design system. It defined structure, spacing, and component behavior early, which helped to keep the interface consistent as new features were added.

Rather than show every component, the example below highlights how I documented one element - the process indicator. It’s used anywhere the user moves through a multi-step flow, such as onboarding or scheduling payments.

The documentation shows the component’s anatomy, dimensions, and text alignment, along with the states we defined:

Design System Detail: Indicators

Most of the product decisions in JoonaPay were guided by a shared design system. It defined structure, spacing, and component behavior early, which helped to keep the interface consistent as new features were added.

Rather than show every component, the example below highlights how I documented one element - the process indicator. It’s used anywhere the user moves through a multi-step flow, such as onboarding or scheduling payments.

The documentation shows the component’s anatomy, dimensions, and text alignment, along with the states we defined:

Design System Detail: Indicators

Most of the product decisions in JoonaPay were guided by a shared design system. It defined structure, spacing, and component behavior early, which helped to keep the interface consistent as new features were added.

Rather than show every component, the example below highlights how I documented one element - the process indicator. It’s used anywhere the user moves through a multi-step flow, such as onboarding or scheduling payments.

The documentation shows the component’s anatomy, dimensions, and text alignment, along with the states we defined:

Impact

The new design gave the product a clear structure and sense of trust that was missing before.

Early demos helped the founder position JoonaPay more confidently with investors, venture capitalists, and potential customers. The consistent visual language and interaction patterns also made it easier for the engineering team to implement new screens without design drift.

The design system also cut iteration time and made decisions simpler. Developers now use the same components across the various screens which has reduced confusion and improved consistency.

The product hasn't launched publicly yet, but is in the hands of potential customers for trialing purposes.

Impact

The new design gave the product a clear structure and sense of trust that was missing before.

Early demos helped the founder position JoonaPay more confidently with investors, venture capitalists, and potential customers. The consistent visual language and interaction patterns also made it easier for the engineering team to implement new screens without design drift.

The design system also cut iteration time and made decisions simpler. Developers now use the same components across the various screens which has reduced confusion and improved consistency.

The product hasn't launched publicly yet, but is in the hands of potential customers for trialing purposes.

Impact

The new design gave the product a clear structure and sense of trust that was missing before.

Early demos helped the founder position JoonaPay more confidently with investors, venture capitalists, and potential customers. The consistent visual language and interaction patterns also made it easier for the engineering team to implement new screens without design drift.

The design system also cut iteration time and made decisions simpler. Developers now use the same components across the various screens which has reduced confusion and improved consistency.

The product hasn't launched publicly yet, but is in the hands of potential customers for trialing purposes.

Reflection

JoonaPay reinforced how much structure matters when you’re moving quickly. Starting with a design system early gave the rest of the product a clear backbone and kept every decision consistent.

Working with a distributed, bilingual team also taught me the value of clear documentation and visual communication. Translating designs and annotations into French wasn’t just about language - it was about making sure intent was never lost.

Reflection

JoonaPay reinforced how much structure matters when you’re moving quickly. Starting with a design system early gave the rest of the product a clear backbone and kept every decision consistent.

Working with a distributed, bilingual team also taught me the value of clear documentation and visual communication. Translating designs and annotations into French wasn’t just about language - it was about making sure intent was never lost.

Reflection

JoonaPay reinforced how much structure matters when you’re moving quickly. Starting with a design system early gave the rest of the product a clear backbone and kept every decision consistent.

Working with a distributed, bilingual team also taught me the value of clear documentation and visual communication. Translating designs and annotations into French wasn’t just about language - it was about making sure intent was never lost.