'Asset Finance' - Lloyds Banking Group

'Asset Finance' is the first product in a wider initiative to introduce a self-serve journey for banking customers to apply for, and manage, their financial services. The work is purpose-designed for both 'colleague' and customer user-types with the former being more complex. The solution, born of UX-led design thinking, establishes the patterns (user flows, journeys and interactions etc.) that will be rolled out across all financial products and services within business banking - a standardisation of customer engagement, if you will.

Client industry / sector: Financial Services
Client location: City of London, London
Project delivery time: 7 months

Service/s provided: UX design / UX consulting

An image of work-in-progress user journey flows for the UX-led design of asset finance.
Image: A screenshot of a work-in-progress user flow UX recommendation for colleague-generated new applications for the UX-led product design known as 'Asset Finance'. These flows help to illustrate a given journey that a user will undertake.


Discovery began with meeting the existing product team (made up of developers, B.A.'s (business analyst/s), a P.O. (product owner), a visual designer and their departing UX designer) prior to taking on the work. This was in order to get up-to-speed on the early solution approach they had taken, and the problem/s it was addressing, seeking to understand their working process - from UX design, through visual design, and then development. Evan also met with the P.O. to understand their vision, and the B.A. to gain as much insight as possible before agreeing to take on the work.

Evan and others later met with R.M.'s (relationship managers), one of two intended user-types for the eventual product, to research how they conduct their role to gain understanding of their processes - the factual, the good and the bad, as well as the work-arounds they'd incorporated to make carrying out their tasks faster and/or easier. This research shed light on the shortcomings of the existing product and highlighted common pain-points - such as the use of multiple desktop applications to process a single product application, the lack of intuition in these programs, their complexity and even frequent system crashes.

The discovery/research revealed that of the R.M. user-types, there were in fact different 'types' of R.M.s, each with different remits, different customer groups and different ways of engaging with customers. This meant that requirements for one type of R.M. were not necessarily the same for another and so the solution would need to provide for all these user-types. Perhaps one of the most insightful discoveries was that customers would often not have all the information to hand (required by the bank) when applying for asset finance or when seeking quote. This insight would go on to inform the solution greatly.

Finally, the business' goal of increasing R.M. 'speed' and 'capacity' came to the fore, as the real business drive behind the work.


Prior to OldWorld taking the work on, the business had identified finance brokers as the user-type for this product and some exploratory design work had been undertaken. The business case evolved, and the focus changed providing a solution for their Asset Finance telephony R.M.'s. The product brief then evolved to also include a direct customer-facing self-serve product that would also re-cater to finance brokers. Much rationalising and re-thinking of the early financial broker solution was needed.

There existed a tendency to 'design by committee' - often with unintentional descriptions of 'solutions' rather than a focus on capturing and defining the requirement. There was also a lack of understanding from the business on the difference between visual design and user experience design disciplines which surfaced from time-to-time.

Amongst the wider business, there existed a habitual practice of 'designing for the system', i.e. for the current way of doing things or for the way the backend worked, and not for the user. By working closely with the visual designer, together we were able to voice design reasoning and champion the user. Within the project at least, the challenge was largely overcome.

This was a high-level and visible project, by nature, with much interest from other teams and the 'higher-ups'. By printing (A3) journey flows, wireframes and visual designs, and placing these up on walls, we brought visibility to it and encouraged stakeholders and other to come for a walk-through where they were taken through the solution from a user's perspective - whilst explaining the design rational and logic that informed the solution.


The UX-led design successfully establishing the user-centred product application design flow to be rolled out. The solution addressed the wider business desire to free-up R.M. time by decreasing their time spent processing individual asset finance applications, allowing R.M.'s to onboard yet more customers - addressing the goal of 'speed' and 'capacity'. While the customer self-serve solution also addressed the goal of increased capacity.

Both user-type solutions tested well with no serious issues and helped tweak the final product. The product's design was effective and allowed all user types to dip-in-and-out at their pace, catering to the main user research insight, while the design and interaction patterns established were product-agnostic so could be rolled out beyond asset finance - for all business banking products.

This was a personally and professionally satisfying project to produce and a measurable success for the business.

An image of work-in-progress dashboard design in Axure.
Image: A snapshot of a work-in-progress wireframe showing the design of the product dashboard for colleague users. This design considers the management and overview needs of a colleague's asset finance application workload - including new, current, rejected and archived applications.
A snippet of the visual design of the application overview page UX-led work
Image: A draft visual design (for MVP) of the application overview page. This page is the central point of an application and allows the colleague user to dip in and out when entering customer information, as and when it comes to hand - a considered design approach coming from a key learning of the user research.
A snippet of the visual design of the informed choice page UX-led work
Image: Another draft visual design showing a snippet of the 'informed choice' page that colleagues must take customers through.

The process

Our design process always involves the sketching of any solution using pen and paper. The process here involved collaborating with the visual designer to try and challenge and/or validate the suggested UX recommendation. It also involved liaising with the developers to see if they could envisage front-end or micro-services issues in the UX recommendation to be built around. This working practice was mutual and organic - happening as and when, with OldWorld often asked to chip in and help on visual design aspects and development roadblocks.

The requirements that informed our solution were validated with R.M.'s and B.A.'s to double check that the nuanced details were hard and fast before considerable time and effort went into the design thinking. The inhouse testing lab was engaged for user testing with customer users (direct observation and video recording), while colleague users were test with in-person - more guerilla-style. These methods helped to surface issues and validate the solution.

The work was iterative by nature and the development of the project run in Agile. OldWorld's UX design work was in advance and independent of this. Our work was designed for the 'end-state' and would then be reigned-in for MVP as per the business prerogative.


This project was very satisfying as it was primarily professional peers - developers, a visual designer, a tester, and OldWorld providing the UX work - working together to deliver and build a user-centric solution.

OldWorld gained exposure to the developer oriented 'Amigo session' - a method of collectively solving development problems. This was adopted and used for design solution issues from time to time allowing for design and development skillsets to input on a suggested solution, and where possible alternatives to the solution might emerge given back-end limitations. A tricky balancing act when designing for the user and not the system.

From a design perspective - the working relationships on the project was ideal, and sadly very rare. Exactly how professional design and development engagements of independent contractors coming together - hand-in-hand, yet authoritative and not via 'design-by-committee'. A job well done.

This project engagement was defined as being Outside IR35 - 100% contractor control (OldWorld Creative Ltd retained control and direction over work produced, working patterns and work delivery, and was not client-office-based) as per correct contractor practices.