Design at Bloomberg

From 2015 to 2018, I was an interaction designer for the Bloomberg Terminal, an extensive platform that provides finance professionals with data, research, analytics, news, and pretty much anything else they need on the job. More importantly, the Bloomberg Terminal serves as a network to connect finance professionals so they can trade securities, share research, and collaborate on investment ideas. 

I designed a variety of communication, collaboration, and compliance products including apps for messaging, note-taking, searching, contact management, and surveillance policy creation. 

Case study: redesigning a contact management app called SPDL

Messaging is one of Bloomberg’s most important features — it’s used heavily and is the feature that makes the platform so sticky. Many years ago, a group of engineers built a contact management tool (called SPDL) for users to keep track of people with which they communicate.

Over the years, SPDL has evolved and features have been added to support entirely new use cases. The app, which was originally created for traders to keep track of their contacts at other firms, is now also used for managing pricing distribution lists. As the use cases evolved and new features were tacked on, SPDL became increasingly difficult to use.

Clients began having difficulty managing and sharing their SPDL lists, and they often relied on Bloomberg customer support for help. They've hacked solutions to support their workflows, but these hacks caused usability problems.

In 2016, after witnessing these usability issues firsthand, we set out to redesign SPDL. Our challenge was to simplify SPDL and bring it up to modern standards of usability while supporting the more complex workflows we observed during client visits. 

Here's a screenshot of SPDL before our project:

Initial Research

To learn how clients use SPDL, I conducted contextual inquiries and interviews with users, talked to internal specialists and experts, and looked at help tickets in our internal ticketing system. We found that a number of basic user needs were not being met by the existing system. Some of the key user needs/opportunity areas we identified are:

• As someone keeping track of my clients, I need to know their status (especially, if they’ve been fired)

• As someone thinking about using a mailing list I need to know which mailing lists I have access to, where the list came from, who is in the list, and what I can do with the list

• As someone trying to contact clients, I need to make sure I have my team’s latest mailing lists

Brainstorming, sketching, and creating a product roadmap

We had a series of ideation sessions with our product and engineering partners. In these sessions we came up with new ideas, had sketching sessions, prioritized future work, identified possible challenges, established a shared product goal, and created a product roadmap. 

 Our roadmap was comprised of many versions - the earlier versions would establish a framework that the later versions would build upon.

Validating long-term goals with clients

We started by validating our long term goals to ensure that our v1 was comprised of the right building blocks - we realized that if our long term goals were invalid, we would want to change the fundamental framework of the v1. To do this, we added the long-term features to the existing UI. We brought these paper prototypes to clients and asked them to point where they would click. Though some called it "arts and crafts", everyone participated happily. We found that our long term goals were valid. 

Wireframes that we used for concept validation:

Designs for v1 of our new SPDL

We based our designs off of user needs that we identified during the research phase.

The contacts view: As someone keeping track of my contacts, I need to find them quickly and see their online status.

First, we separated the individual contacts from the distribution lists — they were intermingled in the old design, which caused confusion. We tested a number of options for the contacts view and users preferred this simple grid, which makes sense since they spend so much time in Excel!

The list view: As someone sending out pricing information, I need to know which mailing lists I have access to. I also need to know where the list came from, what’s in the list, and what I can do with the list.

Customers often create and share mailing lists with their teams. Many people we interviewed had tons of lists that they used regularly, though they often didn't know where the list came from or who was on it. When we asked customers to explore the lists they use regularly, they often found people that shouldn’t be on there, and removed them on the spot! Further complicating matters, SPDL supports nested lists, and customers sometimes found entire lists within their lists that they hadn’t realized were there.

The contact detail view: As someone thinking about contacting a client, I need to understand the context of our relationship.

Before contacting a client, customers want to know about the context: which of my distribution lists is this person on? Have we messaged recently? Do I have any notes on this client, either personal or professional? Relationship building is very important for our customers, so they want to be prepared for client interactions.

Testing and iterating

We designed a testing protocol and conducted usability tests in our lab with 9 client participants. We identified 12 critical tasks, and rated how successful participants were at completing them.

We identified some small usability issues in our testing and addressed these in our final designs. One area that required some work was out “add contact” flow. Customers use this feature to add a new contact — the autosuggest feature is integral because if a customer selects a Bloomberg user from autosuggest, the user’s public Bio record will be linked to the SPDL entry.

Originally, engineers said we had to have separate fields for first and last name. In our testing, we realized that there are often hundreds of Bloomberg users with the same first name, and there was no way for users to select from that list.

Based on our testing findings, engineers agreed to a single name field. This greatly improves the experience, though it does require first and last names to be parsed if the user enters a custom contact. This is less precise, but its a tradeoff we were willing to make!

Post release

After releasing our simplified SPDL (phase 1),  our sales reps report fewer lost lists and fewer calls in which clients are confused about list management and finding/maintaining content. Success!

Next steps: to work on the v2 features from our roadmap!