BRDGE Fintech Dashboard Redesign
UX Research
UI Design
Internship
This project was a 3-week project done during my first ever UI/UX internship for a local software development start-up, The Solveware Co. I took this opportunity to practice some skills I learnt in school.
Team
Choo Yuan Jie, Intern
Celine Ooi, Intern
What I did
Research Plan
User Interviews
Information Architecture
Feature Suggestion
Results
Made development more efficient by introducing a free design system.
Practised facilitating user interview sessions with various employees.
Background
BRDGE helps connect public money providers to small businesses. The revamped dashboard, will be mainly used to perform data-analysis and reporting.
The Solveware.co provides software solutions for companies in Singapore. Our client, BRDGE, wanted to redevelop its admin dashboard.
ddd dd A screenshot of how the dashboard looked like originally.
We broke it down to rebuild it
As part of the product strategising phase, I was involved in the early stages of planning the redevelopment.
Summary
1. User Interviews
We interviewed the different teams and found out their pain points through questions.
2. (Digital) Shadowing
We recorded and looked back at how each team used the dashboard in their day-to-day workflow.
3. Defining Opportunities
We found similar problems and feelings across each team, gathered a few problem statements.
4. Solution Brainstorming
We brainstormed for solutions and a final prototype was prepared for the PM.
Snapshot of an observation session.
Understanding
One navigation bar = few extra hours.
We realised that employees repeated tasks that would cost them a few hours a day of extra labour because of the lack of proper menu hierarchy and navigational tools.
However, many employees were quick to come up with unorthordox “quick fixes” for UI problems.
Some entered ".../page=250" on the url instead of pressing next 20 times.
Understanding
An overload of dangerous buttons?
People were not aware of the full extent of the dashboard's features because they did not dare to explore around what they knew.
Every button became a potential danger to losing all the funds in the platform.
Function-first, to user-first.
Problem
There is a lack of user autonomy when using the dashboard, caused by ambiguity in the user interface.
Most of the buttons looks the same, there is a lack of a proper navigation system, descriptions and texts were not easily understood by the employees. Of course, that's when we also found out that current BRDGE dashboard was developed by a single developer(wow!).
Problem
Users are overloaded with information and choices.
Beyond remembering specific functions, it was hard for users to remember navigational paths that led them to forms, which was caused by the sheer amount of menu items on the menu bar.
How might we?
Intruduce user-first navigation, while reducing congnitive load for employees on the dashboard?
Synthesis
We iterated off a free design system to make customised components for our dashboard.
After synthesising our observations from all three teams,
We decided to adopt the Ant.Design system (as we wanted to keep development fast) and craft custom UI components that were suited for each team.
Ant.Design system also had...
Existing iconography, which was clear and understandable by employees.
A front-end development library which was easily accessible by the team.
Pre-designed and validated building blocks (buttons, forms etc)
Customised features and components for each teams.
1. Friendly Search Filters
For the compliance team, we designed friendly filters to aid in their background search. They are now able to perform any type of search.
2. Redesigned Loan Forms
For the credit team, we redesigned loan forms such that they did not have to worry about losing track/progress of their long forms when they switch tabs. (The sections autosave too!)
The most important value (Credit scoring) is also placed at the top for easier reference.
Synthesis
We introduced information architecture to organise 99 menu items.
The main menu items were also categorised into each team’s function. We tried several types of categories and seeked for employees’ opinion. We managed to end up using function based categorisation.
The above screenshot shows how I tried to categorise the menu items (Alphabet, Hierarchy and finally by Function).
Reflections
Lesson
How to work in a small, close-knit team of developers, product managers, and designers.
It was very interesting to work with developers, as many of them consider scalability of the product. (There was a moment when I suggested animated icons and someone mentioned it would increase load time when there are too many animated icons.) Finding the perfect balance of attention to all stakeholders is crucial in proposing solutions.
Lesson
Ask better questions? Set better constraints.
In hindsight, several questions could have been rephrased for better insightful answers, such as asking questions focused on their past/present, rather than their future. Each experiment could have also a clearly stated hypothesis to validate.
