Customers can see the financial record of a payment but may still lack enough context to recognise the real world purchase.
Product Design · UX
Lloyd’s Insights Concept
A concept for making everyday banking transactions easier to understand, remember and act on through transaction memory, predictive spending and contextual cashback.
At a glance
Mapped the uncertainty journey, explored alternatives, moved from low fidelity to high fidelity and used assumption mapping, impact mapping and MoSCoW to focus the Alpha.
Independent Alpha concept. The prototype is testable, but real customer validation and production feasibility are still outstanding.
Service development lifecycle
Discovery → Alpha → Beta → Live
I use Discovery, Alpha, Beta and Live to make the maturity of the work explicit. In Discovery I would use the first half of the Double Diamond to widen the evidence base before defining the problem. Alpha is where I narrow that learning into testable hypotheses and prototypes. Beta would only begin once the riskiest assumptions have been reduced enough to justify building a working service, and Live would continue the research rather than treating launch as the finish line.
Discovery
The original trigger was a repeated behaviour in my own banking: revisiting a transaction and still not remembering what it was for. That is useful problem discovery, but not sufficient evidence of a wider customer need. The missing Discovery work is customer interviews, support themes, transaction recognition behaviour and existing product data.
Alpha
This case study is currently here. I explored multiple ways to reduce reconstruction effort, moved from flows to low fidelity and high fidelity prototypes, and identified the assumptions most likely to break the proposition.
Beta
A Beta would require validated user need, technical feasibility, privacy and security review, accessibility testing, design system integration and measurement inside a working service.
Live
Live would mean measuring whether transaction recognition actually improves, whether customers use annotation over time and whether support or fraud related uncertainty falls, then iterating from real behaviour.
Current stage: Alpha. Anything beyond this point is shown as a proposed next step, not a claimed delivery result.
The behaviour I noticed
The problem did not arrive as a product brief. It came from repeatedly reviewing my own transactions and realising that the bank could tell me how much I spent, but not always enough context for me to remember what the purchase actually was. When a merchant description was vague, I had to reconstruct the transaction across receipts, messages and other apps.
I turned that observation into a problem statement rather than a feature request: customers can see the financial record of a payment but may still lack enough context to recognise the real world purchase. The Jobs to be Done framing became: when I revisit an unfamiliar transaction, help me recover what it was for quickly so I can decide whether it is expected, needs action or can be ignored.
The potential user need is not “customers need transaction notes.” The deeper need is confidence when reconstructing past spending. I would synthesise interviews, support themes and behavioural data into need statements, then use assumption mapping to separate what is known from what is both uncertain and consequential. That keeps the most dangerous assumptions at the front of Alpha rather than hiding them behind polished UI.
User need → problem → hypothesis → test
A repeated personal behaviour exposed the problem and existing banking transaction histories show the context in which it occurs. I treat that as a signal for Discovery, not as representative customer research.
Other customers also experience avoidable uncertainty when merchant information is not enough to recover the real world context of a payment.
If customers can add or recover useful context with very little effort, they will recognise historic transactions more confidently and need fewer external memory aids.
Interview customers about recent unrecognised transactions, observe their current recovery behaviour, then task test whether they discover annotation, understand it and consider the effort worth the future benefit.
Process
I treated the concept as an extension of an established banking experience rather than a visual redesign. I journey mapped the moment where confidence breaks: a customer notices an unfamiliar payment, tries to recover the context, checks external sources and may eventually contact support or report fraud. I then sketched a lightweight service blueprint around that journey so the interface idea stayed connected to merchant data, receipt storage, privacy, support and fraud operations behind the screen.
Early wireframes
The early wireframes test hierarchy before styling. The transaction detail remains the anchor, personal context is added as a secondary layer, and predictions sit separately so the app does not blur factual transaction data with inferred behaviour.
Design system and states
Rather than inventing one off UI, I considered how each feature would exist as a reusable component with default, completed, eligible, ineligible, low confidence and high confidence states. That matters in banking because a component has to behave predictably across many merchants, account types and customer circumstances.
Category picker exploration
I later took one small behaviour deeper: recategorising a payment. The exploration maps the journey from noticing that a category feels wrong through finding the payment, choosing a better category, committing the change and finally seeing whether the edit improved the monthly picture. The goal was to make the payoff visible enough that correcting data feels worthwhile rather than like admin.
Open questions: whether category selection should save immediately, how long undo should remain available, when a bulk rule is appropriate and whether custom categories should influence future suggestions.
Impact mapping
I mapped the outcome before the feature.
The impact map keeps the deliverable provisional. The theory of change is deliberately simple: better context should improve recognition; improved recognition should reduce reconstruction effort; and lower reconstruction effort should improve confidence and reduce avoidable support journeys. Each link needs evidence. If one link does not hold, the feature should change rather than being defended because it already has polished screens.
Validation
Research status: this is an independent Alpha concept and I have not presented fabricated interview findings as research. I would begin by synthesising five to eight interviews with comparable mobile banking users, then rewrite the strongest themes as hypotheses with a clear predicted behaviour and failure condition. Usability testing would focus on whether customers can recognise the purpose of annotation, discover it without prompting and judge the effort worth the later benefit.
“Tell me about the last card transaction you did not immediately recognise.”Tests whether the problem exists beyond my own experience.
“What do you do before reporting a transaction as suspicious?”Maps the current recovery journey and support burden.
“Would you ever add a note or receipt to a banking transaction?”Tests whether annotation creates value or simply more admin.
“When would a spending prediction feel useful rather than intrusive?”Tests trust boundaries around inferred behaviour.
“What would you need to see before trusting an automatically activated cashback offer?”Tests clarity, control and commercial trust.
Accessibility and inclusion
Financial products need to work when people are stressed, distracted or using assistive technology. I would treat WCAG 2.2 AA as the accessibility target and test the interaction model rather than relying on a final visual compliance pass.
Keyboard and focus.Every interactive control needs a logical focus order, visible focus state and no keyboard traps.
Screen reader meaning.Transaction status, merchant context, note actions and prediction confidence need programmatic labels that do not depend on visual position alone.
Contrast and zoom.Text, controls and state changes need sufficient contrast and layouts must remain usable when text is enlarged or the viewport is reduced.
Errors and uncertainty.Validation, low confidence predictions and unavailable merchant data should be described in text, not communicated only through colour or icons.
One important trade off
Business need: Lloyds has an incentive to increase engagement with rewards and paid account benefits. User need: a customer opening transaction details primarily wants clarity, not an upsell.
I would push back on placing an aggressive Silver upgrade prompt directly inside the transaction recovery flow. My preferred approach is to prioritise recognition first, then surface a clearly labelled cashback opportunity only when it is relevant. For ineligible customers, “Available with Silver” should remain secondary to the transaction itself. I would validate the position and wording using comprehension, task completion and offer activation rather than optimising only for upgrade clicks.
Prioritisation
MoSCoW helped decide what earns its place.
Rather than treating every idea as equal, I separated the minimum useful proposition from enhancements. This is especially important in regulated products where accessibility, technical dependencies, policy, security and delivery constraints compete for the same roadmap.
Clear transaction detail, reliable merchant information where available, optional personal context, explicit separation between bank data and customer notes, and accessible interaction states.
Receipt capture, tags, category correction and low effort suggestions that reduce the work required to annotate a transaction.
Predictive spending and contextual cashback once the core recognition problem is proven and trust boundaries are understood.
Automatic personal notes, silent category changes, or rewards that interrupt the recovery task. The concept should not invent context or optimise commercial prompts ahead of clarity.
What I explored
I explored personal notes, receipts, tags and merchant location information where reliable merchant data is available. I then connected that richer transaction context to forward looking spending insights, recurring payment recognition and relevant cashback offers.
Concept exploration. Not a Lloyds Banking Group product or an official interface.
Notes, receipts and tags
Optional personal context stored against a transaction so the next time the merchant appears, the customer remembers why it mattered.
Better merchant and location data
Where data is reliable, the flow resolves processor names into recognisable merchants, categories and place names inside the app.
Predictive spending
Once transactions are better understood and categorised, spending patterns become more useful for forecasting, recurring payment recognition and monthly planning.
Contextual cashback
Rewards appear only when they are relevant to the customer and stay secondary to clarity, avoiding an intrusive upsell inside the recovery flow.
Transparent privacy choices
The customer chooses what to save, what predictions to allow and whether to opt into cashback. Suggestions support the decision, but the system never silently invents personal context.
Interactive prototype
The concept is designed as one connected system. Transaction context improves understanding. Better categorisation improves spending patterns. Spending patterns improve predictions. Merchant behaviour makes rewards more relevant.
Validation priority
The assumption that could break the whole idea
Biggest assumption
Will customers actively annotate transactions?
The concept only creates durable value if the benefit of adding context is greater than the effort. Merchant enrichment, receipt capture and low effort suggestions would therefore be central to the next iteration.
Notes + receiptsAdoption
PredictionsEngagement
CashbackActivation
InsightsRepeat use
SupportReduced enquiries
As an independent concept, the right next step is validation rather than invented production results. These measures would show whether the experience improves recognition, trust and usefulness without adding unnecessary customer effort.