©2018 Built with love by Nick Howland.

Salesforce1 Global Navigation Update

An easier, more efficient way to navigate your data while on the go.

Salesforce1 Global Navigation Redesign

An easier, more efficient way to navigate Salesforce data while on the go.

Role: Product Designer / Lead UX + Visual Designer

Deliverables: Final Designs, Interaction Specs, Visual Specs, Assisted / Lead User Research Sessions

The Problem: A Disconnected Platform Experience

Salesforce users, especially those in the field, tend to start their work on their desktop computer in Lightning Desktop and continue their work on the go with Salesforce1. Lightning Desktop and Salesforce1 are the two major sales products for the company. The selling point for our customers is that they can access the same data from anywhere. Thought that promise wasn’t always fulfilled.

The problem we heard from the majority of our mobile users was that the experience was drastically different between the desktop and mobile applications. Customers couldn’t find the data they needed on their phone because the overall mental model was so different. Lightning Desktop was soon adding “app switching”as a feature as well, which allows users to quickly switch from one product (like Sales or Analytics) to another. All within the same webpage. This was an opportunity for us to either fall behind further or catch up.

Another frustration point was the Salesforce object-focused data model, meaning user-created data is organized through numerous hierarchical buckets, forced users to dig through layers of information to find what they needed. The antiquated stage left navigation wasn’t persistent, so users would have to hit the back button numerous times to get back to the navigation list in order to find anything else. Stage Left was also where the search feature was located, which compounded the issue.

The underlying architecture of the application was also hindering the app’s growth. Because the Stage Left access point, the hamburger icon, was located in the header (which is replaced by a back button when drilled in) and our action system was presented as an almost persistent bar in the footer of the app, it didn’t leave much room for us to place anything else. Especially if they were globally persistent.

Adopting Lightning, our new desktop UI, from the previous and still available Classic UI and driving user engagement were a top priority for the company at the time. The business goals coupled with the obvious user dissatisfaction with Salesforce 1, which lead to drops in monthly active users (MAU)—a key metric for our product teams—painfully pointed to the fact that we needed to bridge the gap between these two products.

Having a better understanding of the problem area, for the business and our users, gave us a list of goals for the app redesign.

  1. Align navigation across Desktop and Mobile.
  2. Enable app switching within Salesforce1.
  3. Increase engagement within Salesforce1.
  4. Drive Lightning adoption via new app architecture and parity.

Designing With A Million Active Users In Mind

 

Dismantling and rebuilding an enterprise app that sees millions of people tapping across it’s surface every day is no small task. Before we dove into decisions, we needed to better understand the whole of our users as well as how they currently use our app. This discovery research didn’t just focus on proving the user complaints we were already aware of, but uncovering complications in usage that users showed through their actions but didn’t verbalize.

Users told us they want quick access to information, and provided clear feedback that the current hamburger menu was preventing them from navigating quickly across the application. Usage data further proved this, as the hamburger menu was the most tapped item in the app. We also discovered that users were confusing the current action bar, which was located in the footer, for a navigation menu. Because they didn’t understand how that feature worked, engagement fell. A lack of multitasking, which was available via tabs in Lightning Desktop, also forced users to get creative with accomplishing actions most of the time this lead to users finding top level information within Salesforce1 then calling coworkers to have them find additional information on desktop—because that was actually faster for them than navigating with Stage Left. All of this lead to users getting so frustrated that they would often delete the app from their phone.

The data we gathered showed that Salesforce1 users tend to be in a time crunch, were largely middle-aged, and were working away from their office 62% of the time, and do not receive training for Salesforce1—which is available but is costly and takes time. This helped us establish a persona. With all of this in mind, we optimized for efficiency and clarity when considering navigation design improvements.

A User Focused Concept

With a better understanding of what users needed from Salesforce1 and a better knowledge of what they tend to access, we set about ideating on new navigation structures. We knew users wanted the experience to be efficient, they wanted the ability to multitask, and they wanted clarity of data.

Iterations focused on how the core navigation was presented and where it was located. It also focused on where app switching would live, which would be a major new navigation feature. These iterations ranged from keeping stage left and adding the app switcher to moving to a traditional tab navigation model.

Option 1: Stage Left with App Switcher.

Option 1 focused on providing a control within the group and gathering more information about Stage Left usage. The goal was to align Desktop and Mobile through the simple addition of the app switcher within Stage Left, docked immediately below the profile section and above the different “apps.” This was our low calorie option connected the app switching with the personal account of the user, since the apps would be attached to their org and license.

Option 2: Stage Left + Tab Nav with App Switcher.

The second direction focused on efficiency, personalization, and flexibility. Tab navigation, a navigation pattern widely known, was placed in the footer of the app. Stage Left was still included as the main form of navigation. The order of items in Stage Left are determined by an admin, so the order is “personalized” according to the org.

This version of tab navigation used the first 5 admin specified items within Stage Left and presented them as a shortcut at the bottom of each screen. The goal of which was to make the experience feel more personal. It also aligned more with what users see in Lightning Desktop.

The app switcher in this modal was placed within the overflow of the tab navigation. The goal of this was to see how far back we could push the app switcher but still make it useable. At this time app switching hadn’t been implemented, so we were also trying to identify the frequency of it’s usage as well.

Option 3: Traditional Tab Nav with App Switcher

The third and final direction focused on efficiency and ease of use. It utilized a more traditional tab navigation with static tabs, like “home,” “search,” and “settings.” We wanted to test the boundaries with this, see what our users were familiar with, and identify if bucketing broader sections of the app could lead to more efficient usage.

The home screen of Option 3 focused on personalized navigation, so the app switcher was placed here.

Initial Concept Testing

We created hi-fidelity mocks of these 3 directions and took them to one of our sales offices to do some light concept validation testing. We wanted to establish a baseline and identify a direction to push forward with.

Within the user testing sessions, we focused on identifying:

  1. Which core navigation proved to be easiest.
  2. Which core navigation proved to be fastest.
  3. Which App Switcher placement was easiest to find.
  4. Which App Switcher placement was easiest to understand.

Through this testing, we found that the traditional tab navigation model was hands down the preferred system. User’s appreciated how fast it was to navigate around the app, loved that you could multitask with the distinctly different tabs, and felt that this system was super clear.

Placing the app switcher on the home screen also immediately called it out. With the right structure of information, this would be a clear and easy to access place for the new feature to live.

Mapping Tabs And Flows

We had a direction to move forward with that was user approved. Now we needed to identify what the tabs were within the new tab navigation system as well as what would be contained within them. To do that, we created a flowchart to outline the structure.

For our initial tab structure, we identified 5 possible navigation buckets.

  1. Home – App navigation. Placed at the start since this controls the context and content of the entire app.
  2. Favorites – Personalized navigation. Allows users to quickly access the things they frequently visit.
  3. Search – Quick global access to anything and everything available.
  4. Notifications – Updates on the things that relate to you.
  5. Settings – Quick access to making app and profile changes, including access to offline and notification settings.

Navigating History Stacks

We also took this time to chat with our product managers and engineers to determine a plan around history stacks. We surveyed other apps that utilize tab navigation and looked back at our research.

Because users would use all the tabs as a tool for multitasking, we wanted to retain history stacks for as long as possible. Clarity was also important so we decided that the back button’s path would be contained within individual tabs, not across tabs. Users could also double tap the tab to reset the history stack and quickly navigate to the top.

Identifying Major Changes

Changing the core navigation of the app meant that many features, functionality, and hierarchy, were going to impacted. To get ahead of this, we took a drive through the app and made a list of all the items that would be impacted. We also used this opportunity to take a second look at these items and iterate on them to further better the experience. This helped us craft a backlog for the project as well as an eventual roadmap.

  • Org Switcher – placement (originally in Stage Left)
  • Action System – placement, structure, possible functionality (originally in the footer)
  • Settings – placement (originally in Stage Left)
  • Profile – placement (originally in Stage Left)
  • Search – placement, functionality (originally in Stage Left)
  • It’s very clear how to move around and get into what I need.

    Michal
    Michal

Finalizing A Direction

Global Navigation for S1 was built with our users’ needs in mind, so we took various prototypes to our users to hear their thoughts, see their reactions, and make adjustments as we worked on the new designs. Since one of the principles of Global Nav was increased speed, we started with simple local tests, like using CogTool to see how quick flows actually were with the new navigation compared to the current, Stage Left based navigation. Using thumb-friendly tabs sped up flows by over 50%. And when our user’s got it into their hands, they completed tasks just as efficiently as we had hoped. We held 2 large user testing sessions when finalizing designs (amongst others with more specific focuses) with internal and external users. The majority of people understood the new patterns in place and were able to easily navigate through the scripted flows. One of the users even went as far to say that the new design was “…so cool and easy.”

During user testing, we took to the road (literally) to learn more and dig further into testing our new designs. Through previous research we found that our users in the Bay Area were drastically different than those in the rest of the country—they were more tech savvy, had the latest devices, were more patient with their devices, and had better cell connectivity. Because of this we road-tripped to and did testing in Chicago, St. Louis, Texas, and a few international stops like London so we could get well rounded and global feedback.

Cross-Company Thinking

Cross-Platform

Users can access their data on Salesforce via every major platform–desktop computers, via iOS and Android native apps, and via the browser on phones. One major design goal of this redesign was to create a navigation paradigm that worked across all of these devices while respecting platform patterns when present.

Cross-Products

The scope of this project was relatively large. Salesforce1 acts as the flagship app at Salesforce, which means that most other apps look to our patterns as a definition of the company’s mobile platform. Because of this, many teams showed interest in utilizing the patterns we were developing for Global Nav.

To aid in ensuring our design decisions could be used across the broader Salesforce mobile ecosystem, which often developed solutions in silos, I helped create environments that would facilitate related discussions. I identified cross-product stakeholders that could use our patterns and met with them regularly to get feedback. We set up a Mobile Design Crit to create a safe space for discussing mobile design as well as get feedback on designs. I scheduled weekly Mobile Office Hours to learn more about our system needs and educate others about the patterns we were developing. Efforts were also taken to ensure these new patterns were easily and readily available to anyone else that could use them.

Working in tandem with the desktop team and Systems team, the S1 mobile team redesigned it’s navigation as part of the Lightning Design System. This means that internally other teams and business units can leverage the components, and externally partners and customers can extend them to meet their specific needs without replicating HTML markup and CSS styling.

Bonus Features

As stated before, bringing tab navigation into Salesforce1 displaced quite a few features and functions. Many of these turned into full blown projects themselves that myself and the team were responsible for. The placement of these adjusted features as well as their updates were all based off user finding discovered throughout the Global Nav project. Certain features, like Favorites, were also created to solve business and user needs and strengthen the new core navigation. Think of these as some of the pieces that make up Megazord; they can all function on their own but together create a much stronger experience.

Favorites

During user testing we discovered a user need for personalization within the app. Customers wanted to be able to have the app not just match their organization’s needs, which the admin was responsible for, but have one more layer of personalization that allows the end user to directly manipulate the organization of the application.

Through conducting more user interviews we discovered that users wanted to personalize the app’s navigation, freely moving the objects they use the most to the top. Through surveying our app structure, we determined that letting users manipulate the app navigation or tab navigation set would be far too complicated, and possibly too dangerous as it would loosen the out-of-the box control we maintain.

With a general understanding of the user’s needs and the hypothesis that personalizing navigation would lead to higher engagement, we set out iterating on a Favorites feature.

If you’re curious how the project turned out, take a look at the case study on the Favorites project.

Org Switcher & Profile

Some users are a part of multiple organizations, which means that they have multiple profiles with different login credentials. For these users, Salesforce1 has an Org Switcher feature that stores profile information, which allows for quick access to other accounts.

The Org Switcher feature was originally housed in Stage Left when that was the primary method of navigation. With Tab Navigation coming in, we needed to relocate this feature.

Referencing usage data, we found that only 2.8% of users had multiple orgs and interacted with the feature regularly. This helped us establish that the placement of the org switcher didn’t need to be top level. Initial explorations lead to placing the users avatar in the header of the home tab, which would open a half sheet when tapped. While the hierarchical placement worked, we realized that we also needed to create a shortcut to the users’s profile since it too was being lost with the removal of Stage Left. This shortcut provided quick access to their profile feed and related record, both of which create a daily timeline and shortcuts to immensely relevant data.

Because this bumped up the hierarchical location of the coupled profile and Org Switcher, we reassessed the tab navigation. Looking at which areas of the app were used most and which were used less, Settings usage fell below that of the profile and app switcher. App settings are also local and tied to the user’s profile. This overlap and rethinking led to us placing the user’s profile in the tab bar. Settings and the org switcher could both be accessed from tapping on the profile icon in the tab bar. These two areas would then be two taps away from anywhere within the app.

Action System

Another major functional element of Salesforce1 that was being displaced was the action system, or Action Bar as we called it. The Action Bar lived globally within the footer of the app, which is the new home of tab navigation. Since one of our focuses was improving engagement, access to creating and editing tools were at the top of our list.

Looking at our data and research, we noted that only 21% of our users took action in the app. While actions were an area that needed to be relocated, it also needed to be rethought.

Through multiple rounds of iteration and many prototypes exploring interactions and animations, we landed on a context focused solution that placed the action next to what they were taking action on, the page title, instead of disconnected at the bottom of the page. We also explored scroll state interactions for the action system, helping to keep them present as the user scrolls down a page that could contain 100+ fields.

View the case study for the Salesforce1 Action System to learn more.

Onboarding & Feature Callouts

An area that Salesforce1 had long overlooked was calling out new features or updates within the app when they are added. The only way we did so were via release notes, which no one but developers tend to read. Since we were giving the app a complete overhaul, we explored onboarding and feature callout patterns alongside most of the features we were reassessing.

We tested two options for a new feature callout and onboarding system: a non-obtrusive modal that allowed users to interact with the screen anywhere to dismiss and a modal located on top of a mask that had a clear action used to dismiss the modal. Users immediately dismissed the first option without even acknowledging it, some people not even realizing that something else appeared on the screen. The second option proved to be useful, though. While some users still immediately dismissed the modal, the mask and callout forced users to at least acknowledge the location in which something was being called out. This lead to a 70% higher success rate of using the new feature paired with the callout within testing.

Getting The Details Right

 Throughout the development phase, we worked closely with the engineers to ensure the visuals and interactions of the Global Navigation effort were implemented correctly and precisely across the two major platforms we were responsible for–Android and iOS. We visited the engineering teams (who were spread out across the west coast) to collaborate side-by-side and, throughout the process as a whole, even brainstormed how to make the experience even better by combining our skill sets and discussing design elements and flows, dreaming big them diving into the smaller details of bringing the project to life.

As a team, we then created specs through a fairly new application called Zeplin. A teammate and myself worked closely with the Zeplin team to ensure we could use our Salesforce Lightning Design System tokens (for colors, fonts, and spacing) within the application. We then took it to our dev teams and created interactive specs where we could look at the finalized designs and collaborate inline by leaving notes and @mentioning each other, enabling conversation to be had directly around what we were discussing.

In addition to living specs, I also created a “Spec Deck.” This was our source of truth for all things Global Nav. It had all of the decisions made for the project, links to the Zeplin specs and other important exploration decks, links to final prototypes, interaction specs, accessibility specs, and much more. The goal was to have most questions answered before they were asked and to have a tangible artifact to share with other teams who intended on or were curious about using these newly established patterns

Collaboration, with engineering and other product teams, was huge throughout the development phase. We maintained this collaborative nature through weekly standups, chatting on Slack, and having product reviews to ensure what was being developed matched the specs we gave the developers before it got into the hands of the users.

Looking Forward

Though development was in progress, this didn’t mean that the project was nearing completion. As the renovated product made it’s way out into the wild, we had a list of success metrics and additional improvements ready to measure the results of the work we did.

Metrics

  • Engagement – One of our main goals was to increase engagement. Through usage data we can see if this did improve and where, through the core navigation or through other coupled features.
  • MAU Increase – One of metrics we use to measure the success and health of the overall app is the number of Monthly Active Users. We would know if if Global Nav is successful if this overall number increases.
  • Lightning Desktop adoption – Global Nav would be successful if we saw an uptick in Salesforce1 users signing up or switching to Lightning.
  • Shared Patterns – Since collaboration was another focus, we would know we were successful if we saw other teams sharing and benefiting from what we created. This was an immediate and noticeable win as we saw 3+ other product teams start to use the patterns developed as part of this project.
  • Other Self-Initiated projects – Since Global Nav was a self-initiated team project, we would count seeing other larger self-initiated projects popping up as a success, possibly being inspired by the work we did.

Additional Improvements

  • Improved Hierarchy – The typography and information architecture of the app doesn’t create an easy to read resource, especially knowing most of our users are constantly on the go. Improving type hierarchy and the general legibility of the product would go a long way in improving productivity and cognitive load time.
  • Improved Landing Experience – Within the initial version of Global Nav, the landing screen was purely a navigation list. This forced users to still drill into something to find what they needed. In a future iteration, we should explore more proactive and personalized approaches.

By rethinking a massive flagship app, we showed the rest of the company that anything is possible. By basing every decision off of user needs, usage data, and business needs, we restructured a daily tool for users and set it up for a flexible and successful future.

Collaborators

Ryan Spohn – Mobile Team Manager
Aran Rhee – Desktop Designer
Lheyla Escobar – Mobile Designer
Jenton Lee – Mobile Designer

Other Projects