Alex Daniels — Fintech & Fleet Product Design

The handoff is where most products quietly become a different product.Design finishes, files go over the wall, and three weeks later the build has an extra confirmation step nobody approved, a fee shown after the amount instead of before it, and an offline state that just spins. Nobody lied. A developer hit a case the design didn't cover, made a reasonable call under deadline, and moved on. Multiply that by two hundred decisions and you have software that works and doesn't feel like what you signed off.In operations and finance products that gap costs more than elsewhere, because most of the product is edge cases — the lost signal, the declined payment, the expired document, the route that changes mid-shift. Those are the screens a handoff never specifies and a deadline always rushes.Running two vendors makes it worse: now there's a seam, and each side can point at the other.We don't hand off. Design and engineering sit in the same team and the same weekly cycle, so edge cases get resolved once, by two people who both own the outcome.In two months you get a working product — designed, built, integrated, tested and deployed. Code and design files are yours.How it runs:— Week 1–2: discovery, core flows, and the constraint map — integrations, providers, regulatory or operational limits — locked by design and engineering together, so nothing gets specified that can't ship— Week 3–5: design and build in parallel, with weekly working builds you can actually use, not screenshots— Week 6–8: edge states, QA, performance, security, deployment and handoverWhat you get:— Full UX and UI in Figma, with a component library— Production frontend built against that library— Backend and API work, or integration with your existing stack— Integrations: telematics and ELD providers, payment rails, KYC and verification services, ERP and third-party APIs— Admin, dispatch and support tooling— Responsive web, plus native mobile where the product needs it— Testing, deployment, documentation and handover— Your code, your repos, your design filesTypical engagements: MVP design and development, fleet management and logistics platform build, driver and field app development, telematics product build, fintech and payments product development, neobank and digital banking apps, B2B SaaS platform launch, internal tools and admin systems, product rebuild and re-platforming, design-to-code delivery.We work as one team at U1CORE — design and engineering together, so what gets approved is what gets shipped. Platforms in this portfolio have processed $720M+ in production payments.

Banking products are judged on the screens nobody shows in a pitch.The hero section and the card animation win the deck. What decides whether someone moves money through the product is duller: whether the fee appeared before or after the amount, whether "pending" came with a time, whether the failed transfer said what to do next, whether the balance matched what they expected to see.Get those wrong and no visual quality recovers it. People don't articulate distrust in a financial product — they just don't complete the transfer, and the funnel shows a drop nobody can explain.The other half is constraints. What your licence allows decides what onboarding looks like. Your KYC tier decides what a user can do before verification. Your rails decide what "instant" honestly means. Design that starts from an aesthetic and meets those later gets rebuilt twice — once by compliance, once by the partner bank.In four weeks you get a complete, buildable product: every screen on the money path, every state behind it, and a design system your team can extend.What we design:— Onboarding and account opening, with progressive KYC— Identity verification, document capture, rejection and retry— Account or wallet home: balance, activity, primary actions— Send, request, top-up, withdraw and transfer flows— Checkout and payment flows, with fee disclosure before commitment— Authorisation: 3-D Secure, SCA, biometrics, confirmation— Cards: virtual and physical, limits, freeze, PIN, replacement— Transactions: history, detail, search, filtering, statements, export— Investment and portfolio views where the product needs them— Refunds, chargebacks and dispute flows— Every edge state: empty, pending, failed, expired, blocked, insufficient funds— Operator side: support console, transaction oversight, compliance review— Responsive web and native mobile— Full design system, component library and developer-ready Figma handoffTypical engagements: fintech product design, neobank and digital banking apps, payment platform and payment gateway design, digital wallet and crypto wallet products, card and BIN programmes, B2B payments and payouts, remittance and cross-border transfers, embedded finance, lending and BNPL, investment and trading interfaces.Work runs as part of U1CORE — design and engineering in one team, so what gets approved is what gets shipped. Platforms in this portfolio have processed $720M+ in production payments.

A driver app has eight seconds. Not of attention — of opportunity.That's the window between the engine starting and the moment the driver decides whether to use the app or call dispatch. Lose it once and the call becomes the habit; lose it for a month and the app exists only as a line in the budget while every hour of operations runs through a phone.Field software fails in ways office software never does. The screen is in direct sunlight. The hand is gloved, cold, or holding something. There's no signal in the depot basement and none on the third of the route that matters. The person using it is standing, tired, at the end of a shift, and is not going to scroll a form with fourteen fields to log a damaged pallet.Most driver apps are designed on a desktop and reviewed on a desktop. Everything above gets discovered after launch, from adoption numbers nobody can explain. In three weeks you get an app designed for the place it's actually used — and specified tightly enough that the build doesn't reintroduce the problems.What we design:— Shift start: what the driver sees first, and what can be done in one tap— Vehicle inspection: photo capture, defect logging, pass and fail paths— Route and navigation: today's stops, sequence, handoff to the map app people already trust— Job and task flow: accept, start, complete, with proof of delivery or service— Document handling: licences, permits, expiry warnings before they block the shift— Incident and damage reporting, fast enough that it actually gets used— Messaging with dispatch, and when the app should speak first— Hours, earnings and performance views— Offline behaviour: what works with no signal, what queues, what syncs, and how the driver is told— Field conditions: contrast for sunlight, target sizes for gloves, one-handed reach, large-type mode— Every state nobody designs: no jobs, no signal, sync failed, expired document, route changed mid-shift— Design system and developer-ready Figma handoff for iOS and AndroidTypical engagements: driver app design, fleet and logistics mobile apps, last-mile delivery apps, field service management, courier and dispatch apps, ride-hailing driver experience, vehicle inspection and ELD workflows, warehouse and yard mobile tools, technician and inspector apps.Work runs as part of U1CORE — design and engineering in one team, so offline and sync behaviour is designed with the people who have to build it.

Operations software has a problem consumer apps don't: the same component has to work in a quiet office and in a moving vehicle.A dispatcher's screen is dense by necessity — forty vehicles, twelve statuses, everything visible at once. A driver's screen is the opposite: one decision, large targets, readable with the sun on it and a glove on the hand. Most teams solve this by building two libraries. Two libraries drift. Within a year the same status means something different on each side, and support is explaining that the driver sees "assigned" while dispatch sees "en route".Then the third surface appears — the admin panel — and gets whatever was left over. That isn't untidiness. It's why every new feature takes longer than the last one, and why nobody can add a screen without opening three files to check how the last person did it.In three weeks you get one system all three surfaces are built from: tokens, components, states, and the rules for which density applies where — delivered in Figma and specified so developers can build against it.What you get:— Audit of what exists across driver, dispatch and admin, with duplications and conflicts listed— Design tokens: colour, typography, spacing, elevation, radius, with light and dark themes— Core components: buttons, forms, inputs, selects, navigation, modals, toasts, empty and error states— Operations-specific components: data tables with sorting, filtering and bulk actions, status and severity badges, map and marker patterns, timeline and route views, alert and exception banners, permission-aware layouts, document and expiry states— Density rules: how one component behaves on a control-room screen and in a driver's hand— A shared status vocabulary so office and road see the same thing named the same way— Outdoor and glove-use rules: contrast, target size, motion— Usage documentation, naming conventions and contribution rules— Figma library with variants, auto-layout and variables, plus a developer handoff specTypical engagements: fleet management design system, logistics and TMS component library, driver app and dispatch console consistency, telematics interface system, B2B SaaS and admin panel libraries, enterprise software design tokens, Figma library rebuild, design-to- code handoff, legacy operations software modernisation.Work runs as part of U1CORE — design and engineering in one team, so the system is specified against what actually gets built, not against an ideal.

Fleet software gets built for the office and used on the road. That gap is where most roadmaps go wrong.The people deciding what to build sit at desks. The people the product actually serves are in a cab with one hand free, in a depot at six in the morning, in a yard with no signal. Features designed in the first context quietly fail in the second — and because drivers don't file tickets, nobody finds out until adoption numbers come in flat.So the backlog grows in the wrong direction. More dashboard widgets for managers who already have enough. Another report nobody opens.Meanwhile the thing that would move the number — a driver flow that takes eight seconds instead of forty — never gets prioritised, because nobody in the room feels its cost.In two weeks you get a product direction built from both contexts: what to build, for whom, in what order, and what each choice is worth in vehicles, hours or fines.Week one — I go through your product the way each role does, read your adoption and utilisation numbers, review three to five competitors in your category, and interview your team plus, where possible, two dispatchers and two drivers.Week two — two working sessions, then the written strategy.What we work through:— Which role is the real constraint: driver, dispatcher or operations manager— Driver adoption: why the app gets bypassed, and what would change that— Dispatch and route planning: what decisions happen outside the software today— Telematics: which data is worth surfacing, and which is noise— Compliance and document workflows, and what they cost when they fail— Integrations: telematics providers, ELD, ERP, fuel cards, and what each one makes possible— Pricing and packaging for fleet operators of different sizes— The roadmap, reordered — with what to cut named explicitlyYou get:— Written product strategy with a sequenced quarter-by-quarter roadmap— The constraint named, with the evidence behind the call— Competitor review of 3–5 fleet or logistics products, flow by flow— Core user flows and information architecture for each role— Personas grounded in observation, not assumption— A "not now" list: what to stop working on, and why— Two 90-minute working sessions plus a follow-up threadTypical engagements: fleet management product strategy, TMS and logistics platform discovery, driver app adoption, dispatch and route planning software, telematics product definition, last-mile and delivery operations, field service management, compliance andELD workflows, MVP scoping for fleet and logistics startups.Work runs as part of U1CORE — design and engineering in one team, so the strategy comes with a realistic view of what it takes to build.

The clearest sign your fleet software is failing isn't a complaint. It's the dispatcher's phone.Drivers stop opening the app and call instead. Dispatch keeps a whiteboard next to the screen because the dashboard can't answer the one question asked every morning — which vehicles can run tomorrow.Somebody exports to Excel to work out driver hours. A compliance document expires because the alert arrived in a list nobody reads. None of those people will raise a ticket. They adapted. The workaround became the process, the process became training, and now new drivers learn the workaround as if it were the product.That's where your real requirements live — not in the backlog, but in what your team does instead of using the thing you paid to build. In one week you get those workarounds found, named and costed, plus a ranked list of what to change so they stop being necessary.How it runs: I watch the people who use it daily — a dispatcher through a shift, a driver through a run — and observe what they actually do, not what they say they'd like. Then I audit the product against that: driver app usability in a moving vehicle, one-handed and gloved; shift start and vehicle inspection flows; dispatch and route assignment; the fleet dashboard and whether its hierarchy matches the real question; exception and alert handling; compliance and document expiry; telematics data and whether anyone can act on it; maintenance scheduling; reporting and exports; and the handoffs between office and road where work quietly falls out of the system.What you get:— Every workaround documented: what people do instead, and why— Time cost per workaround, per person, per week— The dashboard reviewed against the questions it's actually asked— Driver app reviewed under real conditions, not desktop preview— Ranked fix list, ordered by hours recovered rather than effort— What to remove: the screens, metrics and alerts nobody uses— A written audit document your team can act on, plus a 60-minute walkthrough callTypical engagements: fleet management dashboard audit, driver app UX review, dispatch and route planning usability, telematics interface review, logistics platform audit, compliance and document workflow, transport operations tooling, last-mile and field service apps, TMS and fleet software modernisation.Work runs as part of U1CORE — design and engineering in one team, so the fixes are specified in a form developers can build from.

About this ServiceMost products fail before a single screen is designed. Not because the idea is wrong — but because nobody took the time to answer the right questions first. Who exactly is the user? What's the core flow that creates value? Where does the market leave a gap you can own?Skipping discovery means building on assumptions. And assumptions are expensive to fix after development starts.U1CORE's Product Discovery & Strategy gives you a research-backed foundation before design begins — so every decision that follows is grounded in real user needs, market reality, and a clear product direction.What You GetStakeholder alignment session — goals, constraints, success metricsMarket & competitor research (3–5 players analyzed)User personas based on research and interviewsCore user flows & information architectureUX audit of existing product or competitor referencesProduct roadmap with prioritized feature listFinal strategy deck delivered in Figma + PDFProcessKickoff & stakeholder interviews (60 min) — we map your business goals, assumptions, and what success looks likeMarket & competitor research — we analyze your space, identify patterns, gaps, and benchmarks worth beatingUser research & personas — we define who your real users are, what they need, and where current solutions fail themInformation architecture & flows — we map how your product should be structured and how users move through itProduct roadmap — you get a prioritized plan: what to build first, what to validate, what to deferStrategy presentation — we walk you through everything live and align on direction before design beginsBest forStartups and product teams building a marketplace, SaaS, or fintech platform from scratch — or those who have an idea but need clarity on what exactly to build, for whom, and in what order.