PORTAL REDESIGN
OVERVIEW
Deserve is a credit card company who instead of just checking your credit history, also considers your financial health, potential employability, and level of education to increase your chance of approval for a credit card.
WHAT IS PORTAL?
Portal is the credit applications review and customer relationship management tool used by Deserve,
It is used:
-
To approve, review or reject applications
-
Manage communications with applicants and customers
-
Provide applicant and customer information to employees and management
WHAT IS WRONG?
The current system is
​
-
not secure
-
not easy to use
-
not intuitive to learn
-
involves multiple clicks to perform simple tasks
GOAL
The goal of this exercise was to fundamentally redesign portal to make it easy, secure and efficient to use
ROLE : UX Designer, UX Researcher
PROCESS & TIMELINE
UNDERSTANDING PORTAL
HOW IT WORKS
1. Applicant submits a credit application by going through a pre-qualification flow on Deserve's Website. They answer questions, enter information and upload documents
2. The workflow in the backend takes in the information provided, checks with various credit and other institutions and throws out following outputs:
-
Approve
-
Reject
-
Require more information
-
Send the application to Deserve credit team for Manual Review
​
3.The application enters Portal and goes into the relevant queue
4. The deserve credit team picks up application, manually verifies documents/information and can:
-
Approve
-
Ask for more information
-
Reject the application
When an applicant calls to ask about their status, the deserve credit team pulls out information quickly and provides necessary details
OLD PORTAL
USER RESEARCH
Job Shadowing and Contextual Inquiry
I checked with all the teams in the company to identify key users who interact with portal for different purposes.
I spent time with them while they were performing their daily tasks to see how they use and interact with Portal
​
-
I made detailed notes of all the tasks they perform with Portal
-
Identified the different roles they played - Personas
-
Listed down all the gaps and frustration points
​
What I found out
1.The users have access to all the information, regardless of their role - One size fits all
2. There is no way to assign a queue item to a user, which leads to duplication of work
3. The information architecture, action buttons and navigation structure is not simple and intuitive to understand
4. Portal should be secure with restricted access and logout when inactive
​
What next?
Based on the user research, the next steps taken were:
-
Identifying and creating personas for all the tasks performed in portal
-
Compile a list of Product Requirements
-
Share it with the management to communicate my findings while collecting inputs for the same.
-
Identify high priority features and functions to be created first
​
PRIMARY PERSONAS
PRIMARY PERSONAS
SECONDARY PERSONAS
PRODUCT REQUIREMENT LIST
I created a product requirement list clearly indicating
-
Tasks
-
Roles which can perform those tasks
-
Priority to make a minimum viable product for initial version
DEFINING USER FLOWS
Next I started creating user-flows for each key persona
SCORER FLOW
MANUAL REVIEWER FLOW
CUSTOMER SUPPORT FLOW
ROLE BASED INFORMATION ARCHITECTURE
SKETCHING
I looked into multiple dashboards and information storing and processing tools to get inspirations for best practices and methods for interactions like search, apply filters and save options.
Here are a few sketches:
LOW FIDELITY WIREFRAMES
Add filters, if required
View/Edit Profile information
Action Button
Start review from Scoring tab
Search Feature
Typeahead suggestions
View/Send emails Communications tab
USABILITY TESTING & ITERATIONS
Navigation Tab Bar
Showing applicant tasks and timeline
Showing Profile information
PUTTING IT TOGETHER...
Information tab selected
Document tab selected
Communication tab selected
Scoring screen
Next Steps:
​
-
The high fidelity wireframes were converted into Mockups by the visual designer
-
The designs were sent to the Engineering team who are located in India
-
We used Zeplin to collaborate the design guidelines and mockups
-
The first version was released on a test environment which is being tested.
Key Takeaways
-
The first low fidelity wireframe was designed using Desktop size artboard (1024x1024). When we conducted usability test we realized that all the users use an iMac size (2560x1560) we had to recreate them again in the new size. This is where, my use of responsive design while creating symbols came to use. I kept that in mind while working on the entire project.
-
Working in a startup also made me realize that people from all teams will have input and communication is the most important factor. Holding regular meetings and sharing regular status updates helped everyone stay on the same page
-
Collaborating with teams in remote location taught me the importance of keeping communication clear by having regular meetings and using collaborative tools effectively. Also time management was the key due to different time zones involved.