NEXEN

A financial services platform developed by BNY Mellon during its digital transformation.

August 12, 2016

NEXEN is a data analysis platform that allows users to analyze business data in different ways (as well as download additional plugins for new interpretations of the information).  Developed by Bank of New York Mellon, the UX team was tasked with upgrading its notifications, or alerts, system. I was a UX/Front End intern, and I was tasked with improving the alerts system through heuristic reviews, user tests (with business users), low/high fidelity prototyping, and front end programming.

Objectives

• Modify the alerts (notifications) system that notified liquidities and business transactions to be more clear and readable.

• Tune the subscription system to be more intuitive and less confusing.

Outcomes

• Extensive research and user testing which led to a low and high-fidelity prototype of a new subscription model in Axure RP

  • We reduced the amount of links and introduced a wizard to make the process intuitive.

  • We implemented ways (through buttons and sliders) to indicate important accounts or monetary ranges users would be interested in to reduce spam.

• Implemented changes in the notifications user interface using AngularJS (for example, had the notifications icon light up on mouse hover).

Problem

In order to update users on business transactions and liquidity deals from different lines of business or changes in the system, NEXEN relied on its alert system, which provided realtime notifications to users to whatever information they subscribed too.  This also leads to the subscription system, which allows users to subscribe to updates from any line of business they choose from.

The main issue is that the the alerts system is very out of date.  Based on a heuristic review we conducted on the site, a lot of the information was cluttered and extraneous, with random timestamps thrown around.  In addition, the alerts system was prone to spam just from the massive amount of information people could get from subscriptions.  The topright dropdown system also did not provide a lot of feedback on a lot of actions, such as when there are no notifications to view.

In addition to that, the subscription system interface was very confusing.  There were multiple links to add a subscription, and placement of certain elements made adding emails or editing subscriptions a hassle.

Research and Review

We started off by immediately researching some best practices when it comes to notification systems.  Some things we came across:

• Never use tech speech; keep the instructions simple and easy to understand.

• Clearly distinguish things with different colors in order to make at a glance identification easier.

• Never annoy the user; spam is the one thing that'll cause someone to unsubscribe!

Afterwards, we did a heuristic review of the application in question.  We wanted to navigate the site as if we were new users, and placed ourselves in the shoes of the business people who would use it.  We primarily analyzed the notifications system and clicked every link and analyzed every element there was.  We categorized everything by the type of criticism we provided (whether it was a technical issue, information overload issue, etc.).  We found that the

• Application, though organized, was at times very cluttered with a lot of information, especially prices.

• A lot of the dates and outputs were also raw outputs that programmers were familiar with, but not everyday users.

We brought in businessmen that dealt with liquidities for our user tests in our user lab, where we used eye tracking software and cameras in order to discern areas where users had a lot of confusion.  Coupled with numerous menus as well as unresponsive icons, we set about making user flows and stories for the application.

Options

Based on our heuristic review, we brought in the front end programmers in order to discuss which pain points could be fixed quickly and which ones would need more reworking.  Based on our discussion, be categorized the pain points into two categories:  Actionable and Non-actionable tickets.  The Actionable tickets we would tackle hands on by using AngularJS, HTML, and CSS to fix the problems in the files before pushing it for review.  The Non-actionable tickets were problems that couldn't be fixed simply by changing the code, so we would need to do more research on them before doing user flows and wireframes (both low and hi fidelity in Axure RP).

Actionable Tickets

Among our actionable tickets, some of the problems we had to fix were:

• The notification icon did not light up if you hovered the mouse-over it (nor did it react to a mouse-over in any way)

• The current page of number of the table you were on didn't always update.

• If there were no notifications, there was no message pointing out there was no more notifications (making an empty notification tray look like a bug).

These were problems we could fix by first creating tasks in our JIRA system (in order to assign ourselves these tasks in the company task management system) before making branches in the company's local Git.  I myself tackled the issues with the notification icon and tray, especially in relation to the notification icon not lighting up on hover-over and the notification tray not displaying a message when empty.

The files we dealt with were largely programmed in HTML, CSS, and AngularJS, which is something we picked up with practice before diving into the files.  I dealt with the hover-over issue by making the notification icon light up once the user hovered over it with the mouse.  For the notification tray issue I added a message that said "No new notifications" once the user had no new alerts in the system.  This experience was very enlightening as it gave me hands on experience with front end development in a professional setting.  I got to see the files inside and out, and how changes in the code are conducted in a business setting.

User Flows and Prototyping (Non-actionable tickets)

Among our non-actionable tickets, we discovered that users wanted to add liquidity accounts to their alerts system so that they would receive notifications whenever these accounts had an edit or change.  The problem was, adding accounts to your user profile was a very unintuitive process that had a lot of complicated and roundabout steps.  My UX partner and I determined that we needed to redo how the entire system was done, first with user stories and flows, then with low and hi fidelity prototypes before doing user testing.  I had a lot of experience with the process through school projects, but this helped me apply these skills in a professional setting.

User Stories and Flows

Our first step was to take the complaints we experienced through user interviews and our heuristic review of the application and address them through user stories by detailing what users actually want.  From our user stories, we were able to determine that users would most likely need:

• A single process to add a liquidities account to their profile.

• An option to opt into email alerts in addition to in-application notifications

• A simple method to categorize the alerts by priority.

From these user stories we were able to make user flows based on how each of these actions worked presently in the application and how we believed they should work.  We found that the process to add a liquidities account to your profile was overly complicated; there were three processes by which one could add an account, and each process was hard to follow and overly tedious (not to mention way too many options for different types of notifications).  By comparing each flow chart, we realized the pain points in the contemporary model, and thus set about simplifying the entire process.

Prototyping

Low-Fidelity Prototype 

We decided to centralize the feature into one tab as opposed to three, and drew out what we hoped would be a more streamlined and simple form to fill out.  We put special focus on the form that the businessmen and women would have to fill out:

• We put in a 'timeline' feature so the user could go back to any point in the form

• We simplified a lot of the questions that were asked.

• We put in more focus on sliders and buttons so that the form would be more intuitive to the user.

Upon review with our UX team lead, the Front-end team, as well as several of NEXEN's users, we were able to figure out the pros and cons of our new designs.  The main insight we got was on how our email notifications were set up; it was believed that there needed to be more robust structure in selecting multiple accounts for email notifications, as well as adding emails to an account.  We were also able to gain insights to existing sliders and buttons that could be used in our framework.  With these things in mind, we went about making a hi-fidelity prototype.

Hi-Fidelity Prototype

We made our hi-fidelity prototypes in Axure RP, which allowed us to add interactions to our prototypes.  This was our first time building such prototypes in a professional setting, and my partner and I divided the prototyping work in half.  We had a lot of fun building and presenting our prototypes to the UX team, although given our timeframe we were not able to sort out the issues with email notifications.

Conclusion

 All in all, my time at BNY Mellon was a fantastic experience; we received a lot of mentoring and insight into both the UX and Front-end pipeline, and had a lot of fun doing it.  It gave me the tools and knowledge to lead the UX processes of my own group projects, and I am sure I will still use them in the future.