'Asset Finance' - Lloyds Banking Group .
'Asset Finance' was the pilot product in a wider initiative to design and produce a product-agnostic 'onboarding' journey that could at once be a customer self-serve journey as well as a relationship manager solution involving more complexity. The solution was born of UX-led design thinking and research that established design patterns and journeys that would be rolled out across all business banking financial products and services.
Client industry / sector: Financial Services
Client location: City of London, London
Project delivery time: 8 months
Service/s provided: Research / UX design / User testing
Discovery began when meeting the Lloyds Banking Group (LBG) product team made up of developers, business analyst/s (BAs), a product owner (PO) and visual designer. These discussions were held before taking the project on and covered the business objectives, the state of the project, the problems it was addressing, and to understand their working process - design, development, and methodology. The project was intended to be a broker portal for finance brokers to send in leads to Lloyds Banking Group relationship managers.
Research was undertaken with relationship managers (one of two intended user-types for the product) in the form of ethnographic / contextual interviews at their locations as well as individual interviews at LBG offices. These revealed how RMs went about their role as well as to help us understand their processes - good and bad. Discovering such things as tools used and the workarounds RMs had adopted to alleviate the pain points they encountered. It was discovered that RMs used multiple desktop applications to process a single 'asset finance' product application, with complex and clunky workflows and un-intuitive user interfaces and even frequent application crashes. Much of this was observed. This research crucially revealed the shortcomings of the existing workflow giving insight into potential solutions early on.
The discovery/research revealed that of the RM user-types, there were in fact different 'types' of RMs, each with different remits, different customer groups and different ways of engaging with customers e.g. 'telephony RMs' and 'field RMs'. This meant that requirements for one type of RM were not necessarily the same for another and so the solution would somehow need to cater for all. Perhaps one of the most insightful discoveries was that their customers would often lack the necessary information (required by the bank) when applying for 'asset finance'.
Finally, the business' goals were identified as being improving 'speed to decision' and increasing the RMs 'capacity'.
Prior to taking the work on, the business had identified finance brokers as the user-type for this product and some early exploratory design work had already been undertaken to this affect. Further discussions with RMs however revealed that it would be far more beneficial for them (and the business objectives) to have self-qualified leads coming in directly from customers. The current process for this involved much RM time, while Broker leads would often contain incomplete information meaning RMs would often need to spend time following up. This insight meant proposing an additional customer 'self-serve' approach to the PO (and the wider business). And so, a self-serve customer-facing product was proposed. This would address both 'speed to decision' and 'increased capacity'. As research continued, focus changed to providing a solution for 'asset finance' 'telephony RMs' only as 'field RMs' would hand their cases to support teams. Much rationalising and re-thinking of the early financial broker portal work was needed.
A tendency existed to 'design by committee' - either by describing the 'solution' rather than focusing on capturing and defining the requirement - or by giving undue weight to opinion. The wider business had an inherent practice of 'designing for the system'. To mitigate much of this, I worked closely with the visual designer, the developers, and PO and together were able to surface design reasoning and champion the user. Within the project, the challenge was largely overcome.
This was a high-level and visible project, with much interest from other teams and Business Leads. By printing journey flows, wireframes and visual designs and placing these up on walls, we brought visibility and encouraged stakeholders (and others) to come for walk-throughs while explanations of design rational, logic and user testing findings could be seen informing the iterative design approach to the solution.
My design process always involves using pen and paper to sketch ideas and eventual solutions. The process here involved collaborating with the visual designer to 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 solution. This working practice was mutual and organic - happening as and when, with myself often asked to chip in and help on visual design and development issues.
The in-house testing lab was engaged for user testing with customer user types (via direct observation in a testing lab), while RM users helped to test the solution designed for them. These methods helped to surface issues and validate the solution.
The work was iterative by nature and the development of the project ran in Agile. My UX design work was in advance of this. Our work was designed for the 'end-state' and would then be reigned-in for MVP.
The UX-led design successfully established a research-backed, 'expert' designed and user-tested product design to be rolled out across all business banking products. The work was designed to be product-agnostic, meaning the newly established design patterns were universal and could be deployed for any finance product including credit and other internal regulatory checks. The solution addressed the wider business need to free-up RM capacity by decreasing their time spent processing individual asset finance applications with the new design. The self-serve customer journey also addressed this requirement. 'Speed to decision' was greatly improved with this new single application solution.
Both user-type solutions (RM and customer self-serve) tested well with no serious issues and helped to inform tweaks for the final product. The product design was effective and allowed all user types to dip-in-and-out at their pace, rather than through arbitrarily linear and binary journeys, while importantly addressing the user research findings. The design and design patterns established were product-agnostic so could be rolled out beyond asset finance - for all business banking products.
Overall, this was a personally and professionally satisfying project to have been involved in and a measurable success for the business.
" Evan is a talented and meticulous UX designer. His work is always well considered and to the highest quality. I enjoyed working with him at Lloyds Bank as he collaborated well in the team, had solid UX design and was always open to the challenges we faced. I'm sure he'll continue to do well and I wish him the very best for his future. "
Lead Visual Designer – Chris Wigmore
This project was very satisfying as it was primarily professional peers - developers, a visual designer, and me working together to deliver and build a user-centric solution. Design know-how and inherent design thinking and practice were not necessarily universally understood. Challenges will likely always be faced even in otherwise smooth projects.
I gained exposure to the developer-oriented practice called an 'Amigo session' - a method of collectively solving development problems around suggested design solutions. Occurring rarely, they allowed design and development skillsets to input on a suggested alternative solution due infrequently to last-minute scope creep, changes to the minimum marketable product (MMP), or back-end issues with micro-services, emerging. A tricky balancing act when designing for the user and not the system.
Image: The site map (doubling as a journey flow) for the relationship manager user-type. The journey considers the need for an RM to be able to dip in-and-out of a customer's product application, entering information as and when it came to hand.
Image: The user flow for self-serve customers differed slightly in that it was a linear journey, negating the need for user accounts and other barriers, while retaining security. This approach catered for the user take their quote away, have a think about it, compare it to others, and to return at a later point, via a one-time-passcode (OTP). By asking only for the asset and desired repayment terms initially, the journey was designed to allow customers to get their quote without forcing them to hand over personal and business information. A vast improvement, both internally for bank CX, and over competitor products.