Native iOSTransactions UIFintechDesign SystemFigmaUX/UIMobileBranch Workflow

iOS transaction screens — list, search and detail views

Project Overview

Incard is a London-based fintech building what it describes as a financial OS for digital-first businesses — combining multi-currency accounts, corporate cards, cashback, and real-time spend visibility in a single platform. Having raised a £10m Series A, the product is scaling fast across the UK and EU, serving e-commerce brands, agencies, and high-growth startups.

This project was the Incard 2.0 redesign of the Transactions section — a ground-up rethink of one of the most data-heavy and interaction-critical areas of the app, informed by real customer feedback from the 1.0 product. Business owners and finance leads rely on this section daily to track spend across multiple cards and linked accounts, reconcile payments, and drill into individual transaction details. The challenge was designing something that handles genuine financial complexity while still feeling fast, clear, and native to each platform.

Process & Foundation

The Transactions project benefitted from a significant amount of groundwork I had already invested in during my first months at Incard. Before this feature work began, I had led the migration of the entire product design system to the new Incard 2.0 brand — updating component libraries, colour systems, typography, and shared UI patterns across both iOS and web. That investment meant this project started from a solid, consistent foundation rather than having to resolve system-level decisions mid-feature.

Transaction List View

The transaction list is the entry point — where users land and scan first. The design needed to work across two distinct modes: Incard native transactions and linked external bank accounts. Each mode has its own data shape, visual treatment, and navigation behaviour, and users can switch between them seamlessly from the top action menu.

Key design decisions focused on scannability at pace. Merchant identity sits at the top of the visual hierarchy with the amount prominent to the right. Supporting metadata — card used, date group, account type — lives in a quieter secondary layer so it’s accessible without adding noise to the primary scan pattern.

Left to right: scrolled state · default not-scrolled · action menu (account switcher)

Transaction Row Component — 83 Variants

Before a single list screen could be finalised, the transaction row component had to be fully defined. Every transaction type surfaces differently — different icons, directional indicators, amount colours (debit black, credit green, declined struck through), and secondary FX amount labels. 83 distinct named variants were documented across 12 categories.

The 83 variants span 12 transaction categories — not every type supports every status, so valid permutations had to be mapped explicitly:

Search

Search was designed to work naturally within the iOS keyboard interaction model — activating inline without modal navigation. Both light and dark modes were fully designed, with real-time “typing — no results” states, populated results states, and the “done tapped” confirmation state handled distinctly.

Search light mode · search dark mode (in progress)

Filters

The filter system was one of the most structurally complex parts of the project. Users needed to filter by date range (including a custom date picker), status, category, merchant, merchant type, team member, card, and linked account — each with its own selection sheet and scroll behaviour.

Applied filter chips persist above the transaction list so users always know what’s active and can remove individual filters without clearing everything. A detailed chip label spec defined exactly how each filter type should display once applied.

Custom date picker · main filter sheet · merchant selection

Transaction Detail Views

Each transaction type required its own detail screen — because the data fields, layout, and available actions differ significantly between a card payment, outbound transfer, ATM withdrawal, FX exchange, direct debit, cashback, reward redemption, or Incard fee. Designing for each type individually rather than forcing them into a single template was the right call.

Card payment with FX · card payment no FX · outbound transfer no FX

Notes, Categories & Attachments

Beyond viewing a transaction, users need to annotate and categorise it for accounting and reconciliation. The detail screen supports free-text notes (with character limit states), spend category assignment, receipt attachments (up to 5, with type chooser sheet and max-5 lock state), and accounting codes — all with their full range of states designed.

Notes sheet · category tapped · 1 attachment uploaded

Export & Action Menu

The export flow lets users download a transaction statement for a selected period. The export sheet and its scrolled state were designed alongside the transaction list action menu — which handles account and view switching.

Action menu · export transactions sheet

Web Application — Transactions

Alongside the native iOS work, the transactions section was also designed for the Incard web application. The web context introduces a different interaction model — a full-width data table with filtering, pagination, and a side panel for transaction details that slides in over the table without a full navigation change.

The web design solves the same underlying complexity as iOS — the same 12 transaction categories, same status states, same filter system — but within a desktop layout where greater real estate allows for higher data density and a persistent detail panel alongside the list.

Web transaction table — default view, filter states, and date selection

Transaction detail side panel — Status, Details, and Vendor tabs

Timeline states — Pending (Under Review) · Declined · Pending (Verified) · Completed

Reflection

What made this project rewarding was the compounding nature of the work. The time invested in rebuilding the Incard design system earlier in my tenure paid clear dividends here — components, tokens, and patterns that were already in good shape meant design decisions could focus on the right problems rather than resolving system debt mid-feature. That kind of upstream investment is easy to undervalue until you see the difference it makes in practice.

The process structure — IA workshops, heuristic reviews, staged feedback cycles, and interactive prototypes for complex flows — meant that by the time high-fidelity screens were being produced, the fundamentals were already solid and agreed. Stakeholder alignment was significantly easier as a result. The prototypes in particular proved their worth: showing how a filter sheet behaves in motion, or how the account switcher transitions, consistently resolved questions that static screens left open.

Designing the same feature across two platforms also forced useful clarity about what is genuinely universal versus what is specific to a context. The side panel pattern on web, the table density, the keyboard-native filter interactions — these all differ materially from the iOS sheet-and-modal approach. Each platform decision had to be deliberate rather than a direct port, and the result is a transactions experience that feels right on each rather than compromised on both.

Above all, this project reinforced that the quality of a financial product is measured as much in its edge cases as in its primary flows. A declined transaction, an empty filtered result, a max-5 attachment lockout — these are the moments users remember, and where vague or absent design erodes trust. Covering every one of these deliberately, rather than leaving them to be improvised in engineering, was the most important discipline of the entire project.

iOS NativeWeb AppFintechUX/UI DesignFigmaTransaction DesignDesign SystemMobile App