Fidelity Investments

Prototype Link

Intro

Fidelity investments has been helping customers achieve their financial goals since the 1930's. Whether is is investing in brokerage stock, planning for retirement or donor investments they have been one of the leading financial institutions for decades. With the invention of the internet, Fidelity was forced to quickly move from paper forms to the digital space. The transition from paper to the digital realm would prove to be a struggle for the company even until today.

The Problem

One of their biggest struggles would revolve around their internal tools used by their phone representatives to help customers. While these tools allowed their phone reps to do their jobs, the programs were inadequate and outdated. Paper forms needed to be retyped so that the phone reps could digest the information better. Often times the employees would need to use multiple internal applications to meet the needs of their customers.

In some cases phone reps would create hacks such as cheat sheets, excel files and digital sticky notes to help them solve their clients needs.Because the system failed to inform the phone reps about the status or progress of a customer, many users were forced to rely on notes from previous users to help their clients.

All these things lead to an increase in human errors, confusion and longer phone service calls.

These factors prompted Fidelity to form a new suite of products to solve these issues. A road map was created of all the products that would need to be rebuilt over the next few years.

The plan would be to take all these loose applications and build a suite of tools to increase internal productivity. With a roadmap & a plan in place the company formed a several new teams to build the various applications. This is where I come in.

Fidelity Suite Roadmap

My Role

In 2019 I was hired to help with the strategy/design for the task management portion of Fidelity's new suite of tools. This new tool would replace the current task management tool being used by the phone representatives. When I first came on the project the vision for this project had been loosely defined. The stakeholders over this project knew that the old software was insufficient yet they didn't have a clear vision for the future. Part of my role was to help define the vision and purpose for the task management engine.

My role would include

1. Work with product owner to create a strategy for the upcoming platform

2. Design/create wireframes mockups, and prototypes for developers

3. Find ways to automate the business process & move away from paper

4. Help establish a design system

Defining a Strategy/Vision

In the beginning stages of the project I worked heavily with the product manager, business analyst, and stakeholders to define a strategy. Using the personas which had been previously researched, we identified the tasks our persona would need to accomplish to do their job. This allowed us to generate a roadmap of pages that needed to be built the next few months.

I also had many long conversations with the current task management product owner about previous pain points. By talking with the product manager I was able to glean the following about the old application:

• The old application was full of one-off features. Many of these single use features were added to appease a small portion of our user base.

• The data structure suffered from being siloed from the rest of the other applications data. This made it hard for phone representatives to know what their customers needed.

• The current task management system was rushed to replace an even older system. This created inconsistent designs and features in the product.

Having learned much about the current pain points from the product manager. I also focused on user research to paint a bigger picture of the problems facing our users. I arranged several meetings to observe the phone representatives using the current software.

Sometimes I would purely observe the phone representative without interrupting their job. I would write down my observations and questions. After the observations I would then ask the user why they did what they did. This allowed me to gauge what types of features & information would be needed in the tool I was designing.

Through these sessions I observed many phone representatives:

• Ignored the current task management system in favor of the legacy application or Excel.

• Relied on handwritten note or cheat sheets to do their job

• Split their screen to display multiple tools & info all at once

• Information was copied from one application in order to be used in another

• Needed to retype scanned paper documents into their systems

• Several tools such as calculators & google maps were used to gain more info

• Were timed on how fast they were rather than if the problem was solved

• Could not search by email, phone or who was related to whom in the system

• Had to make phone calls to other representatives to get more information

While I participated in several sessions the main the main issues seemed to revolve around too many tools to find information and poorly structured data bases. With lots of research in hand I set out to create an interface that would allow phone representatives to manage their tasks.

Designing the application

While doing my research I learned that the application had to service thousands of service representatives all over the country. I started designing the task list then worked my way towards the task details page. Without knowing what information and tools the user would need I came up with the idea to create flexible templates to service the various user needs.

I wanted the phone representatives to customize what information and which tools would be displayed on their interface. Rather than having to rely on paper notes designed a tool that would allow them to write notes and see who wrote what note. The phone rep could then contact their peer should there be any questions.

I also allowed the user to drag and drop the tools they wanted on their interface. The goal was to eliminate the number of tools, screens, and paper notes they used outside our application. I also allowed the user to rearrange those tools and information in a manner that made the most sense to them. I started sketching out concepts one whiteboards and paper and eventually created high fidelity mockups of the designs.

Prototype Link

Conclusion

While the research and concepts I came up with were great, the project was ultimately was shut down. There were many factors which let to the downfall of this product including:

• The inability to merge data structures with multiple departments

• Competition with the current task management tool

• The team needed more time to research bigger issues regarding the suite of tools

• Lots of red tape regarding user data and shared databases

• A change of CEO in the company

• Shinier projects being pushed ahead of the task management tool

• Lack of vision for what the new suite of tools was going to look like
  

Lessons Learned

Even though the project was shut down I learned alot about the importance having a clear vision when building a project. From the very start expectations of what we were building was very limited. At one point I was told that the project vision would not be coming from upper management.

Without an understanding of what is you want to build it can be hard to create a successful project. Since no vision came from the stakeholders I needed to rely heavily on user research, learning from past mistakes and gleaning information from wherever I could find it.