Overview

The inception of this project can be traced back to an annual survey conducted by UBS Research Technology. The survey serves as a crucial feedback mechanism to identify areas where the technology organization can help enhance the effectiveness of analysts through digital means.

In this particular year’s survey, the prevailing theme of the results revolved around analysts wanting tools to boost their productivity during their business travels. One such solution for this was a dedicated mobile application for customer relationship management.

My Role

Sole designer and researcher

So how did we get to the solution being the SmartMobile app?

ALIGN

The first step of defining what this solution would be was to align with the business on their goals and how they planned to define success. Through conversation, we whittled down to three main objectives

I then took these business goals and distilled them into what we’re trying to achieve for our analysts

Discover

Interviews

I then set off to conduct analyst interviews to understand their current method of retrieving client information and logging activities while on the road. The most common ways that analysts procured client contact information were: 

When it came to logging activities, analysts rarely logged them while still on a trip, as they noted that signing into the company's propriety platform was too cumbersome of a process. 

I found from reviewing the interview notes that there were two pain points that kept cropping up. 

1. Analysts did have down time while on the road to call clients, but didn't have easy access to client data through firm approved means.

2. When analysts went on marketing trips, they often stockpiled activity notes but then didn't actually log the activity until much later. When they did log activities, they relied on their scribbled notes or looking at calendar events and guesstimating the time spent with each client contact.

Both of these scenarios were dangerous to the business for different reasons. In the first scenario, analysts often resorted to printing client lists or emailing/calling their associates for information. This was obviously a problem because of the risk it brought to CID possibly getting into the hands of someone outside of the bank. 

The latter scenario became an even bigger issue with new MIFID II regulations. With research unbundling on the horizon, the bank needed a way to accurately log all client activites now more than ever.

proprietary portal

To understand lorem ipsum i poked around Neo

One of the mandatory fields for logging an activity is having a user select what type of activity took place. In the desktop portal's activity logging screen, activity types are put all together into one large dropdown menu.

DEFINE

FEATURES brainstorm

Based on

feature prioritization

To understand lorem ipsum i poked around Neo

One of the mandatory fields for logging an activity is having a user select what type of activity took place. In the desktop portal's activity logging screen, activity types are put all together into one large dropdown menu.

design

Card sorting

One of the mandatory fields for logging an activity is having a user select what type of activity took place. In the desktop portal's activity logging screen, activity types are put all together into one large dropdown menu.

In order to make this process less intimidating as well as more usable for a small screen, I used OptimalSort to create a card sort. The objective was to see if there was a consensus amongst analysts on how the different activity types could be categorized.

I created a closed card sort with the categories of phone, meeting, other, research, and event and provided the 23 activity types for sorting.

In all, we had 42 analysts complete the card sort and only four activity types were not unanimously sorted into a category.

information architecture

Once we fully understood the problems that analysts had while working on the road as well as how the problems were affecting the business, we knew where our app could begin to fill in the gaps. We began compiling a list of different actions analysts needed to take to find client information and better record activities. We then bucketed these actions and needs into logical groupings that became the basis for the app's architecture and feature list. At this point, we also marked features as "MVP" or "fast follower," as the timeline of the project was tight and we knew that not all features could make it into the first release of the app.