Morgan Stanley Wealth Management

Launching a global financial institution's first consumer facing mobile app to help customers keep an eye on their investment portfolio.

At

Moment + Morgan Stanley

When

2012 - 2013

What

iOS app
User research

Team

Design director
UX Designer (me)
UX Designer
Graphic designer
Client ux lead
Client creative director
Client business analyst

—

How might we provide customers with a clear picture of their investments, and define a platform to scale additional features into?

In 2011, Morgan Stanley Smith Barney’s website and content wasn’t optimized for mobile viewports. The company also hadn’t built any native apps for iOS nor Android. This made it nearly impossible for investors to understand what was happening with their investments.

We had partnered with their internal design leadership previously to define an initial MVP mobile website. Now we were engaged to design their first native mobile apps.

Process

1.

Define our approach

The app needed to stand out from the crowd, primarily on the experience it offered customers instead of features, since they were late to market.

The company felt the app would be a great place to highlight the company's banking abilities in addition to their portfolio management abilities. Only a small percentage of current customers knew about these additional banking services.

There were many different parties and stakeholders involved across the business. We anticipated that decisions might be slow and that a good course of action would be to design an overall framework for the core functions of the app to get the various department teams excited and engaged.

2.

Identify our MVP scope and IA

Our first activities were to assess the features from a prior mobile web concepts and identify what the core features for the framework needed to be.

3.

Design the navigation paradigm

One of the biggest challenges on this project was navigation. We had to balance keeping the app straightforward, supporting the many internal departments with specific feature requests, as well as providing access to multiple accounts for a single customer.

As with any good concepting phase, we didn't hold back and some of our ideas were great and others a bit out there.

After going through many different navigation concepts, we settled on something slightly unconventional but it seemed to be a good fit for our challenge. We went with the standard iOS bottom tabs for their ability to clearly communicate the key areas of the app.

We then extended the typical pattern with an expanding sub-menu for each tab. So rather than hiding access to subsections within a page, we reveal those options to the user from anywhere.

You want to make a transfer, tap the transfer tab then select "make a transfer". To minimize any confusion, we made sure each tab had an submenu to provide consistent expectations.

Our unconventional concept on making the conventional tab navigation work with a deeper IA

4.

Moving between different accounts

We discovered that a typical user had at least 5 separate accounts. So we needed to make sure there was an easy mechanism for seeing the current balance across all of those accounts, as well as an easy way to drill into any of them to find out more details.

An early concept was to have the accounts menu also serve as the place to check account balances - you can see this in the prototype.

This was too clever and having a dedicated Balances screen to start from was a better approach.

Users had at least 5 accounts, so the first screen in the app needed to display all of the accounts and their various balances to help them answer "How am I doing?".

5.

Optimizing form interactions

We felt the two standard options for a transaction form (step-by-step vs fullscreen back-and-forth) was a place where we could provide a greater native experience.

So we explored an idea that split the form to reveal the input method inline.

This interaction provided greater opportunity for handling lengthy lists and communicating any transactional restrictions to the customer during the input process to help minimize errors.

We hypothesized this interaction would help maintain the user’s orientation with the specific input and allow us to provide additional filters or contextual information.

6.

Rethinking the main navigation

After a key stakeholders shake-up, we landed in a place where the framework navigation was simply too unconventional for some.

We also wondered if there was a navigation pattern that would be more consistent across iPhone and Android.

So we went back to sketching to see what some options were.

A launchpad navigation pattern that would work on either iPhone or Android

A horizontal 'card' dashboard for the home screen that would then allow the user to jump into any of these primary sections.

We eventually settled on the side drawer navigation pattern because it allowed for easy access to all possible sections and would also be a consistent pattern across iOS and Android.

7.

Usability testing

After refining the interaction patterns of the new navigation as well as defining a visual language for the app, we wanted to get in front of users to validate the feature set and discover any usability problems.

The client's development resources were tied up in other projects, so we built an HTML5 prototype to mimic the iPhone app to use for the testing.

We ran multiple sessions across two days and they were all moderated by a third party. We had overall positive findings but there were a few things we needed to work on.

8.

Extending features and covering edge cases

The remainder of the project was a collaborative effort amongst our team of designers to refine the interaction patterns and make sure we had accounted for all of the critical edge case variations.

We also continued to refine and apply the graphic design system across key screens for each of the main sections of the app.

In the end, I was responsible for wireframing and documenting all of the interaction flows including: