A fintech startup came with working backend logic and a clear understanding of what their product needed to do — help employees access lending and digital wallet services through a mobile app. What they didn't have was any of the surface that users would actually interact with: no brand, no interface, no design language. The harder problem wasn't producing screens. It was that financial apps carry a specific kind of weight. People using them are often already under money stress. An interface that feels confusing or cold at the wrong moment doesn't just frustrate users — it breaks trust in a category where trust is the entire product.
I started with the brand before touching the app, because the visual identity and the interface had to feel like the same thing. A warm, approachable brand sitting on top of a cold, corporate UI is a contradiction users feel immediately, even if they can't name it. The existing logo had the right instinct — I refined it rather than replacing it, then built a complete identity system outward from that foundation. For the app itself, I designed against one consistent question: does this screen reduce anxiety or add to it? That question governed hierarchy, language, and interaction decisions more than any other.
I kept the client's existing logo concept rather than starting over. The mark had the right values embedded in it — the business had made a considered choice. Replacing it would have cost trust with the founding team at the start of the engagement. Instead I refined the execution: tightened proportions, improved scalability, made it work across dark and light contexts. The result felt like theirs, because it was.
The color palette was a deliberate departure from standard fintech blue-and-grey. Cerulean blue stayed as the trust anchor, but pairing it with a warm yellow was a considered risk. Financial interfaces default to cold palettes because they signal seriousness. The argument here was that employees accessing financial services through an employer platform are already in a trusted context — the design could afford to feel warmer than a consumer bank app without sacrificing credibility.
I designed the component library before completing the full screen set. This slowed the early design phase but made everything that followed faster and more consistent. When the development team eventually builds against these files, they won't be interpreting one-off screens — they'll be assembling documented components. For a startup that will iterate continuously, that foundation is worth more than a larger screen count delivered faster.
We tested screens with real users before development started rather than waiting for a working build. This is a smaller thing operationally but a significant one for the product. It meant validating the onboarding flow and the repayment tracking experience against actual responses — not assumptions. Several interaction patterns changed based on that feedback. The development team is now building against a design that has been pressure-tested, not just approved internally.
screens validated with real users before a line of code was written
The product hasn't launched yet. What exists is a complete design foundation: refined brand identity, 35+ validated mobile screens covering onboarding, lending, cash-out, and peer transfers, a component library built for developer handoff, and user testing completed before development began. For a startup at this stage, the value of that foundation is that the development team isn't building in the dark. The design has been seen by real users, adjusted based on what they did, and documented for consistent implementation. That's a different starting point than most early-stage products have.
I'd push to define success metrics earlier — specific things the product will measure in its first three months live. Right now the design is strong, but we don't have a clear line between the design decisions we made and the numbers the business will eventually report. That connection should be built before launch, not after.