CASE STUDY
Redefining a critical moment in the user journey
The core user journey had been set some years earlier, but the platform's capabilities were expanding and we needed to find a way of similarly expanding a critical user action. Upon conducting discovery, we realised we were going to have to completely reshape it.
The PEXA platform is built with a central proposition at the core of the experience: the workspace. This is a collaborative space in which lenders and law firms working on a property transaction could come together - something unique in this industry.
Like a lot of platforms, the PEXA platform has a core workflow; a backbone that in a happy path scenario could be followed end-to-end. In this journey was a moment where a user from a law firm would come into the platform to approve the workspace. This was a critical moment - without this step, the workspace couldn't progress any further and the transaction would never complete.
But then it got... complicated. Instead of one law firm, we would now have two. One representing the buyer, and one representing the seller. Our challenge was to figure out how to facilitate both firms approving the workspace. Except that what we found out was that the problem we were trying to solve wasn't quite what we thought it was.
Please note that because this is a B2B platform, some of the outcomes of this work have been omitted to protect IP.
Skills
User research | Problem definition | Communication | Collaboration
Defining the problem by understanding user behaviour
Together with the Business Analyst responsible for the feature, I undertook a number of interviews with law firms, intended to understand their behaviour around approving the data they compile.
The PEXA platform had been developed on the notion that a law firm would approve an entire workspace - in fact, the button to do so lay outside the area where the data sat, so that the user could interact with data across the whole workspace without losing sight of the approval action.
But what we discovered was that whilst law firms do have an approval process for some of the data they compile, they don't approve everything.
A discovery phase was undertaken to establish existing ways of working amongst law firms
Once we understood that the law firm didn't need or indeed want to approve a whole workspace at all, it called into question the entire notion of 'approval'. So now, rather than trying to understand how to expand the approval process to allow two firms to complete it, we were redefining the nature of approval entirely.
Working with the BA and a developer, I split the workspace data into two distinct categories: data that would require somebody to approve it, and data that just needed to be confirmed by the user. The financial data in the platform would maintain a formalised approval process, and the rest of the data would simply be reviewed by someone. These two processes would happen independently of each other, whereas the previously designed approval process had intrinsically combined the two actions.
Key deliverables
User flows
Our starting point for this feature was our existing user flow. We played around with lots of options for how to accommodate the splitting of the approval process, as well as the introduction of a new party into the workspace. Without going into the ins and outs of the outcome, which is unlikely to make sense without the full context of the platform, the journey got much more complicated. We had to work hard to simplify it back down to something that would feel intuitive for our users - as ever, the simpler the resulting UX, the more complicated the challenge!
User flows - the top left shows the simplest flow through the platform prior to the approval process discovery work. Each of the other flows highlights in orange an area where the flow becomes more complicated once an additional law firm is present in the workspace. We did this to identify all flow variations that could be impacted by a change to how approval works.
The resulting user flow
Wireframes & clickable prototype
Once we had re-confirmed the proposed journey with a few law firms, I set about creating the wireframes. This was not as straightforward as I had initially hoped! With approval now split into two separate actions, we had to have two separate trigger points. That was all well and good, until whilst working through the interaction design, I realised that each action did have some implication on the other.
One decision I had to make was around the presence of a modal in the UI. In the existing implementation, once the user clicked the 'Approval' button, a modal would open that asked them to confirm the action. The trouble was, this modal then hid the very information they were being asked to confirm. That was, for obvious reasons, not a great user experience.
I played around with two options that would increase the visibility of the data being approved:
-
Including the financial information being approved in the modal itself
-
Setting a new design pattern whereby instead of a modal appearing, the screen would filter the view to only show the data being approved by that specific user
After working both options through, it became clear that option 2 was the stronger, both in terms of the resulting usability and the cost to implement. It was more usable because it allowed the user to not just see, but interact with, the data they were approving, so that they could dive into the details before finalising the action. It also allowed us to incorporate some legal statements that the user needed to confirm they had read in a much more streamlined manner. (There was also a lot of back and forth with our Legal team to try and make the language as user-friendly as possible, but that's another story!)
The existing implementation, featuring the modal that hid the data being approved
The new design, which incorporated the new design pattern that automatically filtered the data below to show only the data being approved at that moment, with the approval action clearly visible above. This was accompanied by a much more streamlined legal statement that the user needed to confirm.
Impact
The approach I took during this work achieved the following:
-
Redefined the problem statement we thought we were solving for. Through detailed conversations with law firms, where we followed the customer's direction of conversation to allow us to discover that the problem statement was different than we had at first understood, we enabled the problem statement to be redefined.
-
A straightforward solution that leveraged existing patterns where possible, and created new ones where needed. By working closely with the BA and developers, we were able to create a solution that was not only streamlined from the user's perspective, but was cost-effective.
-
Established a significant change to a critical moment in the platform journey that has laid solid foundations for future work. This is probably the most important impact of the work, which is that the solution we put into place does appear to have laid solid groundwork for other features that we are now designing and developing.
By giving ourselves the time to do a deep-dive discovery, we were able to identify a significant issue with the problem statement, and consequently put the right solution in place.