Year
2024
Team
Product Designer
Contribution
UX Design, Interaction Design, Prototyping
Overview
There's a moment in every project where the numbers stop being numbers and start being people. For me, on this project, it was reading a survey response from a single mother who had borrowed £500 from a friend to cover her nursery bill. Not a loan. Not a credit card. A friend. Because that was her only option.
That's the UK childcare market in one sentence. The most expensive in the world. Average nursery costs of £14,300 a year against an average salary of £32,000 - nearly 45% of gross income, for one child, at one nursery. And costs rising 7 times faster than wages since 2008.
Little Steps Financing was built to change that. A 0% interest, FCA-regulated platform that pays nursery fees directly and collects equal monthly repayments from parents over up to 4 years. No interest. No hidden fees. The idea was simple. The product was not.
This case study focuses on process, decisions, and design thinking. Original screens are confidential. The visuals here are my own recreations built to communicate the work accurately.
Process
Discovery: What the Research Told Us
When I came onto this project, LSF had already done the hard work of validating demand. A Pollfish survey of 100 UK parents confirmed what the founders suspected: 42% of parents find childcare fees difficult or very difficult to pay. 57% had borrowed to cover costs at some point — a quarter of them from friends or family. When LSF tested the concept of spreading fees at 0% interest, 74% said they'd opt in. Only 2% said definitely not.
The problem wasn't awareness. It wasn't even willingness. The problem was that no product like this existed. LSF was the first BNPL application on recurring childcare fees. The first to finance high sums in this category. And shortly into the project, they became one of the few fintechs accepted into the FCA Innovation Sandbox — regulatory validation that set a high credibility bar before a single user had logged in.
That acceptance shaped how I approached every design decision. This wasn't a side hustle tool. It was a financial product that needed to earn trust the moment someone landed on it.
The Design Problem: Two Users, One Platform
LSF has two completely different users who never interact directly but are deeply dependent on each other. Parents need financing. Nurseries need reliable payment.
Most products in this space pick one side to design for well. I decided both deserved a first-class experience — and that meant resisting the temptation to build a single dashboard with a role switcher. Instead, I built two fully separate products that shared one design system underneath.
The parent experience lives in sage green — warm, calm, trustworthy. The nursery experience in a dark sidebar with amber accents — operational, businesslike, no-nonsense. Same component library. Different emotional register. Because a parent applying for financing and a nursery operations manager checking their commission report are not doing the same thing when they open an app, even if the app is technically the same one.
The first real sign this was the right call came when LSF signed their first nursery partnership with London Early Years Foundation (LEYF) — one of the largest nursery chains in the city. Having a product that felt purpose-built for nurseries, not bolted on, helped build the trust needed to get that agreement signed.
The Hard Part: The Application Flow
The parent application is where most of the design complexity lived — and where the most important UX decisions were made.
A parent applying for childcare financing is not relaxed. They're returning to work after maternity leave, managing tight budgets, and navigating a product that asks them for their salary, bank details, and employer information. The instinct in fintech is to gather everything upfront. I did the opposite.
I split the application into four steps, each with a clear purpose and a deliberate emotional pacing:
Step 1 — who you are (name, date of birth, relationship status)
Step 2 — where you live (address, contact details)
Step 3 — the nursery and children
Step 4 — financial details (salary, bank account — saved for last, once trust is established)
Every step auto-saves. If a parent gets interrupted by their child mid-form — and they will — they come back to a resume banner, not a blank page. The progress bar shows percentage completed, not steps remaining. These are small things. They add up.
Step 3 is where the real complexity was.
Most parents have one child. Some have two at the same nursery. Some have two at different nurseries, on different schedules, with different fee structures. The application needed to handle all of this — and the repayment schedule calculation needed to update in real time as children were added or removed.
I built Step 3 around a repeatable child card. Each card captures the child's name, nursery, age, days per week, monthly fee, and payment start month. A parent with one child sees one card. They can add another with a single tap — and when they do, the combined monthly repayment at the bottom of the screen recalculates immediately. Not after they submit. Not on the next page. Right there, before they decide whether to proceed.
There's also a rule that had to be surfaced carefully: if a returning parent reduces the number of days compared to their previous agreement, the system flags it with an inline warning before they advance. This is a business rule, but the UX challenge was making it feel informative rather than punitive. It's a nudge, not a blocker.
The 30-day processing rule was similar. FCA regulations mean applications can't be processed immediately. Rather than hiding this in terms and conditions or letting parents select a start date and hit an error, the date picker simply disables dates within 30 days of today. A tooltip explains why. Transparency as trust, not transparency as bureaucracy.
The Joint Application Flow
One of the most nuanced flows in the product is the joint application.
When a parent selects "Joint applicant" and submits, their co-applicant receives a separate email with a unique link to their own form. This was important to get right for two reasons.
First, the primary and co-applicants may not be in the same room, or even in agreement about the details. The co-applicant's form shows them the nursery name, fee breakdown, and proposed repayment schedule — all read-only. They can see exactly what they're signing up for. They can't change it. This protects both parties and avoids the kind of quiet friction that happens when financial decisions get made for someone rather than with them.
Second, the co-applicant's bank account is only used as a fallback — if the primary applicant's direct debit fails, the nominated co-applicant account is tried. I made sure this was explained in plain language at the point of entry, because nothing destroys trust in a financial product faster than a surprise deduction from an account someone didn't expect to be touched.
Once both forms are submitted, both accounts move to "Under Review" status simultaneously. The shared transparency was intentional: it mirrors the shared commitment.
Outcome
What Shipped
By the time the pilot went live, LSF had real parents making real payments across 5 LEYF nurseries in London. That's the moment I think about when someone asks me what this project was. Not the design system. Not the component library. Not the Figma file. Real parents. Real nurseries. Real payments.
Getting there required a product that worked for both sides without either feeling like an afterthought. It required a registration flow that didn't lose people at the bank details step. It required a repayment calculator that updated in real time as families added children. And it required a joint application process that two adults could move through independently without it becoming a source of tension.
What I'd Do Differently
I'd test the multi-child flow with real parents earlier. The add-child interaction and the live cost recalculation felt right on screen — but there's a version of this where someone with two children at different nurseries gets confused about which card applies to which child. I'd want to watch that live before shipping it with confidence.
I'd also run a formal accessibility pass on the status badge colours. The amber-on-white combination for pending states sits close to the WCAG threshold. I have a suspicion, not a certainty. That needs to be a certainty.
But none of that changes the core of what this project was: a real financial product, built for people who needed it, shipped to real users. That's the job. We did it.
