Client
Jacobs Enforcement - Birkenhead, Merseyside
Jacobs Enforcement is one of the leading enforcement agencies in the UK.
Jacobs Enforcement is one of the leading enforcement agencies in the UK.
Roles
Jason Cham - UX Research & Design, Prototyping and Copywriting
Chris Mackin - UX/UI Design, Prototyping and Marketing
Ellie Bowen - Usability Testing Assistance
Chris Mackin - UX/UI Design, Prototyping and Marketing
Ellie Bowen - Usability Testing Assistance
Results
• Increased collections resulting in increased turnover;
• Debtors have a better perceptions of Jacobs;
• Reduced number of customer service calls and complaints; and
• Gained competitive advantage through added value over competition resulting in new contract wins.
• Debtors have a better perceptions of Jacobs;
• Reduced number of customer service calls and complaints; and
• Gained competitive advantage through added value over competition resulting in new contract wins.
Project Background
Jacobs were one of the leading agencies in the industry at the time, however their continued growth was hindered by the following reasons:
• Debtors automatically have a bad perception of Jacobs and are reluctant to handover money due to the terrible stigma attached to debt collection in the past, bailiffs (now known as enforcement agents) have been known to use aggressive tactics to collect debt and charge ridiculous fees; and
• Jacobs still relied primarily on dated, costly and labour intensive methods of contact with debtors including; sending out letter, call centre agents making outbound phone calls and also sending out enforcement agents to the door.
• Jacobs still relied primarily on dated, costly and labour intensive methods of contact with debtors including; sending out letter, call centre agents making outbound phone calls and also sending out enforcement agents to the door.
Jacobs are a forward thinking company and their business goals at the time were to:
• Increase turnover by 10%;
• Reduce overheads from customer service calls and sending agents on the road;
• Improve the debtors' perception of Jacobs and the debt collection industry as a whole; and
• Increase competitive advantage over other agencies to retain clients and win new contracts.
• Reduce overheads from customer service calls and sending agents on the road;
• Improve the debtors' perception of Jacobs and the debt collection industry as a whole; and
• Increase competitive advantage over other agencies to retain clients and win new contracts.
Project Goal
The project brief was to create an online system which would allow debtors to view, manage and pay their debts at any time. The system had to be accessible on a multitude of devices and operating systems, including both mobile, tablet, Android and iOS.
Execution
At the time when the project started, I was part of a 2 person design team at Jacobs with Chris Mackin as the only other designer.
The project was divided up into phases following the waterfall development model. Requirements, Analysis, Design, Development, Testing and Maintenance.
Requirements
To initiate the project, Chris and I met with the stakeholders at Jacobs to document and fully understand the requirements. From this I created a document which outlined the business goals (what Jacobs aim to achieve), business objectives (how Jacobs aims to achieve its business goals), project requirements (what the project should do) and project objectives (what are measurable goals for the project).
Analysis
The next phase of the project was to delve deeper and better understand the users and their requirements, who in our case were people who owed money to Jacob’s clients. With debt being a such sensitive topic, unfortunately we were told specifically by the business not to speak directly with debtors to collect user research. This meant I had to define the target audience, contexts and personas from assumptions along with general demographic information from current debtors.
From developing personas of our target user, it was determined that the best experience for the users would be to create native apps for both Android and iOS alongside website access to the system. Native mobile apps would give debtors quick and easy access to manage their account with push notifications to keep them up-to-date with payments and information.
We decided to take inspiration from online banking apps as they provide similar functionality to what we were trying to create and a good percentage of users will have used or had exposure to them.
Design
I started the design phase by mapping out the activity flows and information architecture of the system. A card sorting exercise was performed on participants to organise and prioritise the topics of information and name the headings for the top level menu.
We followed the mobile-first approach to designing the interface as this would guide us in prioritising the content for all other devices.
Chris and I worked together to define a style guide for the system which was translated into all versions of the app, ensuring they were consistent.
Unfortunately mid-way through the project, the development of the native Android and iOS apps were abandoned due to lack of development expertise, investment and time. Instead the stakeholders decided that the system would be accessed exclusively through a responsive webpage in a browser.
From a user experience perspective, there were pros and cons of abandoning the native apps. The pros are that the user doesn’t have to find and download an app to their devices, however the cons which outweigh the pros are that accessing an online system through a browser on a mobile device can be difficult. Browser systems are also unable to push notifications to users, which was originally an important feature for keeping debtors on top of their debt.
Taking this alternative approach, we adapted the design to work responsively across multiple platforms, whilst also incorporating updated brand style-guides.
Due to app development being a brand new venture for Jacobs, the business was not yet bought into the UX or design process, which meant that there was no budget allocated for real usability testing of early prototypes. I did however manage to negotiate that the prototype was to be tested properly prior to handover to the development team to be coded.
I researched a detailed method for conducting a thorough usability study which involved testing 5 participants who were representative users on roughly 20 of the most complex and common tasks. With the help of a new designer at the time to take notes, I facilitated all the studies in a testing room which was set up with recording equipment to capture audio, the screen and the participants reactions.
Each session followed the summarised format below:
1. I welcomed the participant, provided them with a brief overview of the study and asked them for their consent to be recorded for the study;
2. Each participant was then asked a few questions regarding their knowledge of debt collection and their technical ability;
3. The participant then worked through the task list whilst thinking out loud, during which both quantitative (e.g. time-on-task, completion) and qualitative (e.g. quotes, desirability rating) data was captured;
4. The participant was then asked to carry out a desirability exercise where they were given a number of reaction cards to shortlist and elaborate on in order to better understand how they felt about the system;
5. Finally to end the study, the participant was asked a number of questions about how they found the system.
As this was one of the first usability studies for the product, the quantitative data would be used as a baseline for all future studies. The qualitative data, in particular the quotes captured from the participants thinking out loud was written on post it notes. All team members from both design and development were then invited to an affinity diagramming session in order to organise the vast amount of data captured.
During the session, the post it notes were separated into several groups, of which the most important 2 were successes and pain-points.
To conclude the affinity diagramming session, I asked each team member to vote on the top 3 pain points they feel were the most important. From this we were able to shortlist a handful of high priority pain-points which needed to be fixed along with ideas and recommendations for improving the system. These were all documented in a report for all team members to refer to. It is also useful to keep an archive of the findings to ensure the same pain points aren’t repeated in the future.
Development and Testing
After the design was amended, we handed over the design, prototype and style-guides to the development team to begin building. We worked closely with the developers and carried out various quality assurance and tests on the system to ensure it followed the design closely and worked as we intended it to.
Maintenance
Since Jacobs Customer has been released, it has been updated numerous times with improvements and additional features. I work closely with developers to monitor the analytics of the system and implement A/B testing on new features.
Evaluation
I was fortunate enough to be involved in the project from initiation to release. The execution of the project highlighted the need for a much more robust development process for future projects as time was wasted redesigning the system several times after it had been passed to developers to code, which is a waste of time and money. The project also revealed the need for frequent and fast usability testing much earlier in the design stage.
I also found that for such a small team, following the waterfall methodology allowed for the design to be quite organic and flowing in comparison to using the Agile methodology.
The biggest benefit of the project was that our design process and the usability testing helped to build stakeholder buy-in for user experience research and design. After Jacobs Customer was released, Jacobs created a dedicated UX research and design team.