Before I went to meet the end users I learnt as much as I could about Shawbrook's commercial lending.
We were lucky enough to have not one but two subject matter experts (SMEs) with us through the journey. Every day we would have systems demonstrated and questions answered.
It was important to get a basic understanding of the Bank before we approached their Brokers. We knew how much broker relationships meant to the bank, so we ensured we treated them delicately.
The review didn't take long but it formalised the areas where improvement could be made to the product and helped me create a UX debt backlog to prioritise.
During the review the normal surface level checks were completed:
I found that the site used different design patterns to solve similarly or the same problems as it had evolved.
Accessibility was certainly an issue, for example; a lack of ARIA labels attached to AJAX events, random form element ordering, bad colour contrast ratios and tiny text.
Out of date visual treatments, that were out of step with the brand guidelines currently being used on the brochureware sites.
Accompanied by our Business Analyst (BA) we travelled around parts of the UK meeting Brokers, Packagers and Introducers. We utilised their existing relationships with Business Development Managers (BDMs) to score the meetings in the first instance.
During the interviews, I used the customer development interview technique to ask Brokers about the last time they used Shawbrook to apply for a loan on behalf of a borrower.
We got them to tell a story to understand the job the borrower was trying to hire Shawbrook to do. I would continue to use the five whys method to extract the underlying cause and effect the pains users have in their pursuit of progress.
The business already had a priority backlog and I wanted to juxtapose that against the brokers own backlogs. I used the monopoly prioritisation technique to force brokers to prioritise their needs in a way that was engaging and thought-provoking.
An output from our interviews was to generate 3 key Broker personas based upon attitudes, expertise and clout with the bank:
We met 20 Brokers from Essex, Suffolk, Kent, London, East Midlands and Merseyside. Most specialised in a specific type of loan that our delivery team was looking to develop new features for in the coming weeks and months.
In this project, it was necessary to open up UXpin and develop some high fidelity UIs. This allowed me to explore the visual treatments for, at the time, undefined patterns.
In situations where a design system is already well documented I tend to only lean on hi-fi UI design when there's a new pattern or page layout to define.
By employing a HTML/SASS/JS (jQuery) I was able to build rich data prototypes that are as close to the real experience as possible. While they take longer to build initially, once you begin to iterate on the prototype you end up with a toolkit that allows you to quickly spin up new pages and journeys.
Utilising the GDS 'one thing at a time' pattern to create a triage user flow we could ensure the illustration's main screen only contained relevant variables. In previous designs, various fields became invalid or conditional depending on values entered. Our Google Analytics event reporting showed users were coming up against these 'errors' regularly and with a view to expanding out the product to less expert users, we knew something needed to be done.
Brokers told us how they captured most of a full application's data when they first dealt with the borrower but were prevented from inputting it into the bank's system until quotes, illustrations and indicative offers were completed.
The main issue was not one of mere inconvenience but a situation where the Broker wasn't able to submit data that they knew would derail an application.
The hub and spoke pattern allowed brokers to upload any data they had while flagging any potential blockers to the bank within the system.
The slide out modal was used for self-contained microtransactions. Having the main page in the background provided the orientation a user needed and the modal pattern allowed us to make modular transactions in a tightly controlled part of the screen estate.
The add borrower journey was a nice example of creating a 'wizard of oz' prototype. By utilising the free Companies House API I was able to mock up a realistic journey where users could add their own data and get real results back.
This avoids leveraging a users suspension of belief which often diminishes the returns on the feedback you get.
Adding securities was a feature of the current site that most users hit an error on multiple times. It used a different address micro-interaction to the borrower.
My design hinged on the hub and spoke pattern + the modal slide out to reduce the cognitive load on Brokers when adding securities. It was clear which properties were added, it was simple to add new ones and safe to remove existing ones with a confirmation modal dialogue.
Every application needs an ending and we wanted to make it absolutely clear the journey had come to a conclusion.
To achieve this we created a super clean UI which clearly had the result of any outcome displayed to the user.
The engineered delay and loading messages created a sense of trust because anticipated effort was being applied to the process even though it actually happened almost immediately. We found users waited patiently and were satisfied with the outcomes. This echoed thoughts from Google Venture's Braden Kowitz, although not universally supported.
The MVP was a stripped back version of the vision piece. It reduced the scope down to the smallest thing we could build that would deliver value to the Broker and help us learn their user needs.
We built our new application from the ground up utilising React to create pages with lightning response and rendering times.
We had no mobile users because our mobile experience was broke. Our adopted design system was responsive by default so it opened up the opportunity to serve a new user base.
Sometimes it's hard to avoid help content. For example, our MVP only supported 1 product type. We used an accessible pop-over micro-interaction to explain this to those who were curious or confused.
The single column UI was a step change from the multi-column layout employed by the previous design. It made the form much easier to scan reducing the chances a user would miss an input field, something we noticed even with our experienced test users.
The prototype set the vision, our key stakeholders had this tangible demo they could interact with, talk around and show to others. We used it as a tool to get buy-in from the business and validation from the users.
We released our MVP without fanfare to our early adopters, users who were looking to make progress even if it meant a little pain along the way.
Early data shows a modest move towards faster applications, the more promising feedback has been qualitative. Brokers are reaching out to comment on how they 'love' the new 'straight forward' application and are looking forward to seeing more products (financial) being made in the same way.