Background
Flux's API is used by banks to enrich their transactions with instant digital receipts, allowing bank users to see not only how much they spent where, but exactly what they bought.
Flux's first partner was Starling Bank, shortly followed by Monzo and, finally, by Barclays.
When we begun working on the project we quickly realised all the jobs receipts do, including the variety of data they were displaying in a simple plain text format. We set out not to simply add receipts to banking apps, but to do something useful for the user with the data that's been hidden in them.
Connecting the receipt data to banks allowed us to rethink, among the rest:
- The retailers refund process
- Product recalls
- Stamp card based loyalty
- Offers based on previous purchases
Responsibilities
I worked closely with banks and merchants to define the requirements for digital receipts:
- Developed content guidelines for receipts
- Worked closely with compliance on data consent flows for onboarding and privacy management
- Run testing sessions
- Detailed flows for implementing common receipt actions (e.g. initiating a return)
- Explored use cases for item-level data, like rewards linked to purchases
Research
We looked at a lot of receipts. We looked at receipts from grocery stores — long, and messy. We looked at receipts from restaurants — with menus and sub-items. We looked at receipts from takeaways — with all their custom modifications, additions and tweaks. We studied what online stores were already doing with item-level data, and what high street retailers were missing out on.
Off this research, I worked on documenting the most common cases. Our documentation ranged from content specs for receipts, to user journeys covering the most common actions.
The documentation included some low fidelity receipt mockups to show the range of data banks would have to account for:
- Return receipt
- Discounted items
- Coupon
- Tax handling
- Composite items (e.g. a menu with sub-items)
With some of our partner banks, I was able to run joint usability sessions to validate our decisions.
Challenges
- Balancing our decision to be an ingredient brand — an API, mostly invisible to the final bank user — with the need to be perceived as a trustworthy entity with whom users would feel comfortable sharing transactions with.
- Existing in another company app. Users mostly interacted with us, our receipts and services, through an app and interface we didn't control. We chose to focus on producing good guidelines and flows to suggest the interaction patterns, aiming for a consistent UX while allowing our partners to adapt the UI to their brand.
- Defining a content structure that could accomodate for the variety of data receipts host — from discounts to return instructions.
Video interview
Designs
Native banking app
In support of our bank API documentation, I designed a generic banking app covering:
- Onboarding and offboarding a user to the service
- Managing privacy settings
- Viewing a receipt
- Returning an item
- Viewing and collecting loyalty points
- Item level offers behaviour
Our webview
Alongside our native bank integration I designed a web app — it afforded us a place to test experimental features with users quickly, without having to wait for banks to implement them.
Partners implementation
A couple of examples of how Flux receipts ended up being implemented by our bank partners. These designs belong to their respective design teams.
