Loan management system helps bank workers to create and manage loan accounts of their customers across bank branches. Target users are bank workers in the Nordics and in the UK.

Contents

  1. The problem;
  2. The solution;
  3. The team;
  4. The process: Requirements gathering and research → Define & Execute → Delivery → Handover and support;
  5. Design highlights;
  6. Usability test.

1. The problem

The old Loan system had an outdated UI and couldn’t support new business flows, which have developed over years in the industry. It was a stand-alone system, not included into the whole system, which led to inconsistencies in the UI and data architecture. It was available only in Norwegian language, however the business has expanded into the Nordics and in the UK and required a proper localisation.

2. The solution

Our team updated the UI according to the new standards, also enhancing by intuitive flows and appropriate system feedback. New business flows were added to the system. Loan system was integrated into the complex architecture of the whole core banking system, accessible from multiple browsers. Localisation was done for 4 countries with translations and formatting.

The system was designed and developed for over 2 years, with multiple iterations on the requirements and scope of the delivery with a waterfall methodology.

3. The team

The core team included ~20 people in 3 countries.

  • Product owner;
  • Project manager;
  • Subject matter experts;
  • System architect;
  • 2 UX Designers/Analysts;
  • Business analysts;
  • Developers;
  • Testers.

4. The process

→ Requirements gathering and research

  • Stakeholder interviews;
  • Requirements elicitation;
  • Research the old loan system and current bank processes.

→ Define & Execute

  • Workshops facilitation;
  • Information architecture;
  • Low fidelity wireframes;
  • Coordinate the process with another designer in the team;
  • Review and comment GUI UCs (written by a BA);
  • Design system feedback: success, error, validation, warning, write messages texts;
  • Define alternative flows;
  • Prototype version control.
Image 2. Workshop.
Image 3. High level information architecture.
Image 4. Version control. Each version (v1, v2, etc.) could be planned for different deliveries in various combinations between functional parts. E.g. Disburse loan v1 and Interest rates v2 in Delivery 1.

→ Delivery

  • High fidelity interactive prototype with over 70 screens (generated into HTML), designed in Axure RP;
  • Interaction map;
  • GUI specification;
  • Description of the system behavior.
Image 5. Prototype generated into HTML and uploaded to a server. Accessible by a direct link in browser.
Image 6. Detailed interaction specification.
Image 7. Detailed fields behavior.
Image 8. Example of GUI specification: Drop-down with filtering.

→ Handover and support

  • Prototype walkthrough to developers and testers;
  • Continuous support with Q&A sessions and workshops;
  • Assurance of design and behavior consistency across the Core Banking system.

5. Design highlights

The UI design was made to be easy for an eye, because users would typically work with the Core Banking system for majority of their work day. Thus the design should be neutral. UI customization would be possible upon a client’s request.

The design fulfills 2 regulations:

The system supported multiple languages, locales, permissions and keyboard navigation (designed and tested). The web application was designed for desktop and large screens and had a responsive layout with two breakpoints: 1024 px and 1200 px.

6. Usability test

Who worked on an enterprise FinTech project knows: it is hard to get your hands on actual users.

But we had a great design manager who made it possible! So I am proud to say that the prototype was tested on non-target users (4 people) and on target users (4 people) in a bank.

General findings

  • The input amount field was formatted when focus was moved to the next input field. Users want amount fields to adjust format automatically when typing: putting separator marks, quantity of decimal figures, etc.
  • It was noted that for some tasks the test participants had problems to find the correct menu item in the action menu. This could be a particular issue of translations to multiple languages, so a help of a professional translator would be required.
  • Some test participants found flows with wizards “noisy” because of the redundant captions and guidance. Two other test participants commented that they understood that it was a next step in the process because of the “Next step” text on the button. Thus a need of a wizard UI was be questioned (and removed in future version).



Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here