title: next joy @ banco next subtitle: kids banking product with specific ux, security, and parental-control requirements role: senior ios engineer team: "[team size]" stack: [swift, swiftui, uikit, accessibility] period: "[year—year]" year: "[year]" status: shipped order: 2
context
next joy is the kids' banking product from banco next (bradesco). banking for children aged 10-16 is a fundamentally different design problem from adult banking. every screen needs to balance simplicity with security, fun with compliance, and independence with parental oversight.
the app runs alongside the main next banking app but has its own ux patterns, its own visual language, and a separate set of regulatory requirements around minor accounts, transaction limits, and parental consent flows.
the problem
building a banking app for kids means solving several constraints simultaneously:
→ simplified ux — screens need to work for users who may be interacting with financial concepts for the first time. no jargon. clear feedback on every action.
→ parental controls — every sensitive action (transfers, card activation, spending limits) requires parent approval through the linked adult account. this creates a two-device, two-user flow for single actions.
→ security without friction — biometric auth, session management, and transaction signing need to be as secure as the adult app, but the ux can't feel intimidating.
→ accessibility first — the target age group includes users with diverse needs. voiceover, dynamic type, and high-contrast support were requirements, not nice-to-haves.
the approach
accessibility drove architecture decisions from the first commit:
→ built a component library where every element had accessibility baked in — not as an overlay, but as a property of the component itself
→ parental consent flows used a polling + push notification pattern — the kid initiates an action, parent gets a notification, approves on their device, kid's app updates in real-time
→ transaction screens used progressive disclosure — show the essential info first, let users expand for details. reduces cognitive load for younger users.
what shipped
→ full banking experience for minors: balance, transfers, card management, spending history
→ parental control suite: approval flows, spending limits, transaction notifications
→ 98% accessibility score across all screens
→ real-time sync between parent and child accounts
what i learned
designing for kids forced better engineering decisions. the simplicity constraints — no jargon, clear feedback, progressive disclosure — produced a codebase that was more testable and more maintainable than the "adult" counterpart. the accessibility requirements pushed us to build a component system that the broader team later adopted.
by escaleira / 2026