I Was Asked to Design PAPSS. I Ended Up Helping Build It.

“Design the PAPSS payment experience.”

Simple enough, right?

Not quite.

The project was for a prominent banking group operating across Sierra Leone, Ghana and The Gambia. I was asked to work alongside another designer on a new PAPSS payment experience covering both mobile and internet banking, for individual and corporate users.

The timeline?

One week.

Well... eventually 1 week and 4-5 days.

And somewhere between Figma, React, Angular, Bolt, StackBlitz, Claude, Codex and a rapidly approaching deadline, this became one of the most interesting projects I've worked on.

First, what exactly is PAPSS?

PAPSS stands for Pan-African Payment and Settlement System.

At a high level, it is a payment infrastructure designed to make cross-border payments between participating African countries faster and more seamless, reducing some of the friction that traditionally comes with sending money across borders.

For a banking customer, the idea is simple:

You should be able to send money to another African country without feeling like you're navigating a completely different financial system.

But behind that simple experience is a fairly complex system.

The PAPSS architecture we were working with involved banking channels communicating with the bank's PAPSS middleware, which then communicates with the PAPSS infrastructure. The system also connects with internal banking services such as core banking, authentication and notifications.

That meant I couldn't simply design a few screens and call it a day.

I needed to understand what was actually happening behind those screens.

The first challenge: designing something we had to understand

Our first responsibility was the obvious one:

Design the experience.

But the more I studied the PAPSS requirements, the more I realised that the UI was only the visible part of the problem.

A customer might see:

PAPSS Transfer

But behind that action are things like:

Destination country Participating bank Beneficiary account Beneficiary name enquiry Exchange rates Payment type Transaction purpose Transaction nature Transaction limits Charges VAT Authentication Transaction status Notifications

The transaction flow also required the system to validate the beneficiary before the customer continued, retrieve exchange rates, calculate applicable charges and present a transaction summary before authentication.

So our first task wasn't actually “make it beautiful.”

It was:

Understand the system well enough to make the complexity invisible to the user.

Designing the experience

We started designing the individual screens and flows.

The customer journey essentially moved through:

Transfer → PAPSS → Account → Country → Bank → Beneficiary → Payment Details → Transaction Information → Review → Authentication → Processing → Result

The beneficiary verification step was particularly important.

A customer enters an account number.

The system communicates with the PAPSS infrastructure.

The beneficiary is verified.

Then the customer needs to clearly understand:

“This is who you are sending money to.”

From there, the customer chooses the payment type, enters the amount, sees the exchange rate, selects the transaction purpose and nature, adds a narration, reviews the charges and finally authenticates the transaction.

The challenge was making all of that feel like one simple banking journey rather than a form that never ends.

And we had to think about this across both mobile and internet banking experiences, including individual and corporate use cases.

Then came the demo problem

By around the fourth day, we had made significant progress.

But there was a problem.

We needed to show the experience working.

A normal Figma prototype could demonstrate the interactions, but we wanted something closer to a real product experience.

We could prototype everything from scratch, but with the deadline, we knew that wasn't going to give us the smoothness and flexibility we wanted.

So we tried something different.

Figma Make.

We used the designs we had already created and started turning them into working interfaces.

And this was the moment where my role started shifting.

I wasn't only thinking:

“How should this screen look?”

I was also thinking:

“How should this actually behave?” From Product Designer to Design Engineer

This is where my role as a Design Engineer became much more relevant.

The goal wasn't to become the primary developer.

The goal was to understand enough about implementation to make the transition between design and engineering faster.

We implemented the demo interfaces using React.

By the fourth day, we had something we could actually demonstrate.

And when we sent it to the team...

They were surprised.

Not because the designs were unexpected, but because they were expecting designs and suddenly had something that behaved much more like a product.

Of course, they had feedback.

There were changes.

We implemented them.

And then...

Our AI credits ran out.

When the AI stopped being available

This was probably one of my favourite moments of the entire project.

We were stuck for a while.

Then we remembered something:

Figma Make also had a coding mode.

So instead of waiting for another AI agent, we started working directly with the code.

My colleague, who I was working with on the project, had a strong understanding of React, which helped significantly.

I used Claude and Codex as coding assistants while we worked through the changes.

This was different from asking AI:

“Build this entire application.”

We were using it much more deliberately.

We already knew what we wanted.

We already had the designs.

We understood the interaction.

AI helped us translate decisions into implementation faster.

That distinction matters.

Then came Angular.

Just when we thought we were done, another requirement appeared.

The team needed the code. to see if it's something that could help them hasten their task

Specifically, for the internet banking implementation, they expected Angular.

Our demo had been built in React.

And honestly, this was where things became interesting.

Neither of us was deeply familiar with Angular.

We tried using Bolt to reproduce the experience in Angular.

There was another limitation: we were working with the constraints of a free/freemium AI environment, and eventually those limits became a problem too.

We then explored using Bolt + StackBlitz to produce the Angular version.

It worked to a degree, but it wasn't giving us the same level of fidelity and behaviour we had achieved with the React implementation.

And we were getting very close to the submission deadline.

Stakeholders were already asking.

The team needed something.

So once again, Claude and Codex became part of the workflow.

AI wasn't the solution. It was the accelerator.

This project taught me something important about AI-assisted development.

AI is incredibly useful when you know what you're trying to build.

It becomes much less useful when you're asking it to make product decisions for you.

We had already done the difficult product work:

Understanding the requirements Understanding the payment flow Mapping the user journey Designing the screens Understanding the interaction Knowing what the final experience should look like

AI helped us move faster between those decisions and code.

It didn't decide what PAPSS should do.

It didn't decide what the user should see.

It didn't replace the developer.

It helped us close the distance between design intention and working interface.

Eventually, we were able to provide the requested mobile and internet banking experiences.

The mobile and web demos we created for the design/design-engineering process were primarily built around React.

The production technology direction, however, was different.

The web implementation needed to work with Angular.

That meant the development team ultimately had to work from the designs and specifications we provided, rather than simply taking the React demo and dropping it into production.

And that's okay.

A demo is not production.

That distinction is important.

Our responsibility was to prove the experience, communicate the interaction and accelerate the team's understanding of what needed to be built.

The engineering team could then implement it properly within the bank's technology stack i think they used was flutter for mobile Angular for web & .net for the backend.

Then came the feedback I didn't expect

After everything was delivered, something happened that stayed with me.

The development team lead told us:

“The design team deserves accolades for this product than we do because they did the perfect work and even helped us hasten our work.”

That meant a lot.

Not because it was praise.

But because it validated the way we had worked.

The design wasn't sitting in Figma waiting for engineering.

Engineering wasn't working in isolation from design.

We were moving together.

1. Banking UX is more than beautiful screens.

When you're designing financial products, every field exists for a reason.

Every validation has a consequence.

Every status matters.

You need to understand the system behind the interface.

2. Designers need to understand technology.

I don't think every designer needs to become a full-stack developer.

But understanding how products are actually built changes the way you design them.

When you understand APIs, state, components, validation and frontend behaviour, you start designing differently.

3. Design engineering can reduce the gap between teams.

There is often a huge gap between:

“Here's the design.”

and

“Here's the implementation.”

Design engineering allows you to operate somewhere in between.

You can explore an interaction.

Build a realistic demo.

Test an idea.

Communicate behaviour.

And sometimes even help engineers move faster.

4. AI works best when paired with product thinking.

Claude, Codex, Figma Make, Bolt and other AI tools were useful throughout this project.

But the tools weren't the reason we succeeded.

The product thinking came first.

We knew what we were building.

The AI helped us get there faster.

5. Constraints can change your workflow.

We ran out of AI credits.

We had to change tools.

We had to work with React.

Then we had to deal with Angular.

We had to work with a deadline.

We had to respond to stakeholder feedback.

None of that was part of the original “perfect workflow.”

But that's what real product development looks like.

You adapt.

And this changed something in our team.

Before this project, design and development could naturally feel like two stages:

Design → Development

After this project, we started seeing something different:

Design ↔ Engineering

Design could understand implementation earlier.

Engineering could understand interaction earlier.

And designers could use AI-assisted development to create functional demonstrations instead of relying entirely on static prototypes.

That's probably the biggest thing I took away from the PAPSS project.

I didn't become a developer because of it.

I became a better designer because I started understanding the distance between what we design and what users eventually experience.

And I think that's where the future of product design is becoming increasingly interesting:

Designers who can think in systems. Engineers who understand experiences. And AI that helps both sides move faster.

PAPSS started as a payment integration project.

For me, it became a lesson in what it means to be a Product Designer who can also build.