Case study

Improvements to Admin Tools

at Brightwell

01 /

Summary

Product Design
UX Research
UX Workshops
Fintech

The admin tool used by implementations, compliance, and support teams had never been prioritized from a design perspective, and the team had a litany of complaints about its efficiency. I was tasked with finding a way to design impactful improvements that could be implemented quickly.

Timeline: July-Sept 2019
Platforms: Web admin app
Team: Product Designer (me), Product Manager, 4 Engineers

Results

  • The number of actions and pages to load to execute most common actions was reduced by 2x.
  • The dashboard became the default interface taught to new employees, simplifying their onboarding process
  • This small project was considered a yearly win at the end of the year, alongside other much more costly and time-consuming projects.

02 /

Research

Who is Brightwell? [CONTEXT ON COMPANY]

Brightwell is a company that provides financial services for cross-border remittance and, at the time, focused on the cruise industry. They help cruise ship companies pay their international workers by handling payroll and remittance through their system.

My role

Throughout my time at Brightwell, I was a Product Design team of one embedded in the Product team, responsible for the product website, mobile apps, and Admin tool. I was also responsible for user research and cross-company collaboration.

Project - goals, risks and challenges, constraints

This particular project was an update to the admin tool: the tool that allowed Support, Compliance, Implementations, IT team members and more to act on the system supporting the payroll. In addition, some of the paymasters on ships had access to the system of the employees on their ship.

The Admin tool had many issues and was a constant source of complaint, but they were rarely addressed. With this project, our task was to figure out what changes we could implement quickly (about 2 developer sprints) that could have maximum impact.

Research

Users

We conducted interviews with internal coworkers, grouping them according to their team. We interviewed 2-4 team members at a time to investigate their issues with the system. We talked to:
- the Customer Support team
- the Compliance team (legal)
- the Implementation team (who went on ships to help users enroll)
- DevOps and IT
Through affinity mapping, we identified a list of important problems teams cared about. The list was abundant, and we needed further help understanding where the pain points really were. So we conducted a second round prioritization exercise with the teams:
What were our findings?

Prioritization exercise - setup

We laid each "Improvement" on a post-it note, and provided each team with $100 to "spend" across

Results

Internal users, + some ship users - describe more.

There is a large variation in their English proficiency, and they spend most of the time on ships in the middle of the ocean - they often have no phone access and can’t just get services off the street when they need them.

Prioritization exercise - setup

-weffawe

Main findings

  • The focus of our efforts should be on reducing loading times through technical improvements and through better task efficiency.
  • Combining information currently spread across screens will reduce task speed across the teams that work most with Admin. Through the votes, we knew which screens had the information that needed to be easier to access.

03 /

Solution

Solution: New dashboard

Solution: New dashboard

We were going to create a new "landing page" for the Admin application. Previously the screens users saw upon log-in was completely underutilize. Instead, we were going to use this space to consolidate important information, providing an intuitive location for most users to gather the information they need.
Ideation, feedback from devs
prototyping, and
early testing , results out outcomes
User testing and results
Refinement
Final designs

Ideation

Inventory of Screens

I went through each screen to combine and inventoried the information present on each of them. A lot of it was repetitive, showing why it made so much sense to combine them.

Low-fidelity wireframes and Prototype

Low fidelity wireframes were used to discuss, test and validate early iteration of our solution. This led to quite a lot of modifications: from a division into 2 separate tabs to query different sections of the database and conduct faster searches, to various iterations of the information displayed to users.

Designs

Low-fidelity wireframes and Prototype

Low fidelity wireframes were used to discuss, test and validate early iteration of our solution. This led to quite a lot of modifications: from a division into 2 separate tabs to query different sections of the database and conduct faster searches, to various iterations of the information displayed to users.

04 /

Outcomes

Release

  • The update led to a decrease in Support click rate of 2x, and a significant reduction in time to resolve tickets
  • The dashboard became the default interface taught to support agents to handle tasks, simplifying their onboarding process
  • The outcomes of this project were presented as one of the product team's yearly "wins" in all-hands presentations thanks to its incredible impact
  • The dashboard's success was later replicated for compliance-focused tasks in another section of Admin