E-commerce · Fintech · BNPL
Paysmosmo
Fixing the checkout people kept abandoning, and the trust problem behind it.
Paysmosmo (branded SmoSmo in the app) had a good idea: let Nigerians buy electronics and pay for them over six months. But a confusing checkout, a broken mobile experience and disconnected financial tools were pushing users away before they ever completed a purchase. We had 8 weeks to fix it.
The new checkout, on mobile
We designed for phones first, because that’s where people shop. This is the redesigned journey, in order: the welcome screen, home, the store, a product page, the cart and the order summary.
The journey ends at the order summary, where you can use your savings as collateral and request the order.
My role
There were two of us designing Paysmosmo, and we made the decisions together: one of us would suggest something, we’d talk it through, and we’d agree before moving on.
With a website and a mobile app, a lot of people had a say. We worked with at least 12 stakeholders.
The problem
Nigerians already stretch their budgets by borrowing from family, saving in informal circles and buying on credit from local shops. Paysmosmo wanted to make that digital: buy what you need today and pay it back over six months. The idea was sound. The product wasn't.
The platform had the right parts (a store, BNPL payments, savings and investments), but they didn't work together, and some were broken.
A checkout nobody could finish
Multiple unclear steps, no progress indicator, and no sight of the monthly instalment or total repayment until the very last screen. The stakeholders’ own testing showed it wasn’t converting.
A site that didn't work on phones
It was built for desktop. On phones, where most people browsed, buttons overlapped and forms were nearly unusable.
Financial tools that felt bolted on
Savings and investments sat in a side menu nobody opened, with no link to buying anything.
No visual consistency
Different parts looked like different products. When you're deciding whether to trust a site with your payment details, that matters.
Research and discovery
We spent the first two weeks on research, to find out what was actually going wrong before we designed anything.
Stakeholder interviews
Talking to the founders and the product manager, we learned three things:
- The checkout wasn’t converting. Their own testing showed it, but with no analytics, nobody knew which step people left at.
- Savings mattered to the business model, but the design hid it.
- The real users weren’t young professionals. They were traders and small business owners in their late 20s to 40s, with irregular income.
Conversations with users
We spoke to eight current and potential users:
- Trust came first. “How do I know the site won’t just take my money?” came up in almost every conversation.
- They wanted the full cost upfront: the monthly payment and the total. The old product only showed it at the last step.
- Everyone said they’d use it on their phone.
- Most had never found the savings feature. “I thought that was just for transfers,” one person said.
Feedback and competitors
Existing user feedback said the same things. We also looked at AliExpress and Jumia for shopping, and CDcare and CredPal for BNPL in Nigeria. The ones people trusted most showed security at every step.
We thought the problem was the checkout. It was the whole product: it didn’t feel safe, and the checkout was where people gave up. So the redesign had to fix that feeling, not just the steps.
What we designed
Three principles guided the 8 weeks, and each one became a change in the product.
01
Mobile is the primary canvas
We started every screen at phone size (375px) and scaled up, with desktop as the adaptation. It forced us to decide what really had to be on screen.
02
Transparency before commitment
People should know the monthly cost, total cost and repayment schedule before any step they can't undo. The old checkout had seven steps and no progress indicator. The new one follows the app: create an account, browse the store, pick a product, check your cart and request the order. The key change was showing the monthly price on the product page and again in the cart, so by checkout the commitment wasn't a surprise. It was a confirmation.
At payment, we added what users told us they needed to feel safe: how funds are held, a security badge and a clear cancellation policy.
03
Connect spending and saving
Savings shouldn't feel like a separate product. They moved out of the side menu and into the moment after you buy. After a BNPL order, you can set up automatic savings for your next instalment, so next month's payment is ready without you thinking about it.
Design process
A component library
Midway through, we realised the inconsistent visuals were hurting trust, not just looks. So we paused feature design for three days and built a component library from scratch: buttons, inputs, cards, navigation, errors, empty and loading states, and the BNPL plan selector.
Iterations
Two of many component iterations: the navigation bar and the product card.
High-fidelity designs
More of the mobile app first, then the website.
Empty states
We designed the screens people see before there’s anything to show. Each one says what will appear there and, where it helps, what to do next, like adding a shipping address.
Savings in the app
Savings sit in the same app as the store, so buying and saving aren’t two separate products any more.
The website
The three landing pages: one for the whole product, one for the savings tools and one for the store.
The part that didn't happen
Eight weeks in, the designs were production-ready. Then the client withdrew.
The component library was documented, the prototype covered every core flow, and engineering were already building. I won't pretend that wasn't frustrating. This was a product I believed in.
It never launched, so there are no results to show. Here’s how I would have measured it, each tied to a problem we found:
- Checkout completion. Of everyone who starts checkout, how many finish? The old one wasn’t converting, so this is the main one.
- Where people drop off. The old flow had no analytics. A short, clear flow would show exactly which step loses people.
- Mobile conversion. Most people shop on their phones, where the old site barely worked. I’d compare mobile and desktop side by side.
- Plan views to purchases. If showing the monthly cost on the product page helps, more people who see a plan should buy.
- Savings set up after a purchase. How many BNPL buyers turn on automatic savings for their next payment.
- On-time repayments and payment questions. Fewer missed payments and fewer “will this take my money?” messages would show the trust problem was fixed.
In a food delivery app, a confusing screen is annoying. When people are paying for something over several months, it's a reason to leave and never come back. I've taken that into every financial product I've worked on since.
Want to talk about this project? I'd genuinely like to hear from you.