©2020 Built with love by Nick Howland.

Saleforce Mobile Flow Platform

Salesforce Mobile Flow Platform

A customizable, events driven system that pushes users the data they need when they need it.

Role: Product Designer / Lead UX + Visual Designer

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

The Problem: Outdated Mobile Architecture & Inflexible Products

The old way: single persona apps

Mobile conventions have more or less been the same since the first cell phone came out. The user finds what they needs, consumes it, takes action on it, or creates something new. The act of the user having to find something has been consistent from the start, until the advent of AI that is.

The current architecture of the Salesforce app: a “search and find” model

Users have also always been dumped into a product that is created for the average user, which is more or less a super broad, extremely simplified persona. This makes a bit more sense for most consumer applications. They are for largely for entertainment, efficiency, or some other scoped use case with focus on social interactions or moments of delight. But when it comes to enterprise and business, it’s a different ballgame.

There’s no such thing as “average.”

Within enterprise, the “rule of average” is not a thing. If anything, its a mistake that leads to costly customizations, broken systems, possibly interrupted business process, and ultimately unhappy customers. Personalization shouldn’t be an afterthought; it should be primary, intelligent, conscious, and flexible.

These problems were blindingly obvious when we interviewed users and looked at usage data within two of our core mobile apps: The Salesforce App and Lightning Field Service app.

We focus on the Deal Closer persona but ignore all the details.

Understanding The User


A company is different than an organization is different than a user.

A business user is a complex creature. Each user is part of a larger organization, which is part of a larger company. A company buys a Salesforce product and disperses the licenses to these various organizations. Each organization appoints an admin to set up a customized instance of the platform product for their users. Each company uses the products differently. Each organization within the company uses the products differently. And each user within these organizations might also use the product differently than the person they sit across the desk from.

Focusing on too much.

The Salesforce App is a great example of this. Because of the current navigation (stage left), backend issues (slow loading times), and bloat (all of Salesforce in one app), the app’s single persona focus has left many users feeling left out. While there are ways to customize the app, they are entirely programatic. Which is an issue since most companies don’t have developers on staff to make these changes. A knowledge of code shouldn’t be needed to simply make the app work or sustain it. A Declarative platform is necessary.

It’s just outdated.

Another issue is with the antiquated structure of most mobile apps: find something, do something with it. Through initial research and interviews, we found that it not only slowed users down, but it also forced them away from some apps depending on the use and scope of the app. Users want to be shown what they need. They don’t have the time to slow down and tap around.

Proving The Concept, Testing Usability

Engagement, personalization, and self-starting.

Doing initial interviews and reading previous research findings helped us get a better understanding of our users’ needs. It also helped us create a hypothesis before heading into research: engagement is low because our mobile products don’t match our various users’ needs. It’s not that their needs are changing, quite the opposite; it’s that so many different companies use the product in distinctively different ways. These slightly different use cases seemed to be the downfall (or massive hurdle) of our product, as customization costs the big bucks for customers. Our data model, which focuses on records (opportunities and events) and the information related to said record, also seems to both be dated and doesn’t match the mental model of how users organize their data. So, a flexible and focused system that embraces customization and drives engagement was needed.

As we began to dive into research and fleshing out this new product offering, we decided to take the not-so-traditional route. Since these larger issues outlined previously were known to our product stakeholders, we decided to take this into our own hands and self-start a solution. A new business goal for our organization, Mobile UX, just so happened to be improving engagement within our products. This gave us a business goal to hitch our cart to.

Utilizing a design sprint.

Since the time seemed to be right, we wanted to hit the ground running. I teamed up with a VP in the product organization and we outlined a design sprint. We wanted to validate our concept, begin identifying and mocking up an architecture, do some light usability testing, and pitch the idea to execs. Concept testing focused on asking participants to “build their own flow” with flashcards that had “events,” “actions,” and “customizations” on them. Usability testing focused on having a user run through three flows (Meeting Prep, Meeting Capture, and Meeting Wrap) and personalize one of the flows. We also organized a Design Studio to get other designs involved across the company. The design sprint ended up being a huge success, validating our concept, providing valuable feedback on usability, and getting the project buy-in from executives.

The data speaks for itself.

Here’s a brief overview of the system we were constructing and testing during this phase.

  • Event based application: pushes information via “flows” to the user based on calendar access, time, location, and other mobile-specific features.
  • Engagement: We don’t just give users context, we give them the immediate ability to take action on data or create new data.
  • Task oriented: The object model is flattened to show the user exactly what they need to get context and complete a specific task. All on the least amount of screens possible
  • Flexible: Admins or end users can adjust the “flows” based on their specific needs. Nothing is finite. This is done and made easy through provided components and a builder.
  • Declarative: No code is needed to be able to customize this experience.
  • Multi-Channel: Define experience once and express it across various channels, like GUI, voice, AR, and more.

And here are a few key takeaways from research that helped us shape our system.

  • All users show a want / need for this product.
  • There is a definitive conflict between admin and end user functionality; admins wanted more control while end users wanted more freedom.
  • Users don’t want to think about what to do next. Our systems should be smart enough to be able to serve that data to them.
  • Record centric UI is not ideal: there needs to be a single place for all important and related information, regardless of where it is coming from.
  • Similarly, users were overwhelmed by our product offering. They don’t know which app to use or when.
  • End users wanted to create “flows,” but they don’t have ideas on how to.
  • Admins and end users were curious if permissions still apply; want to make sure their data isn’t available to anyone.
  • It would be awesome to see third party content in this system as well. From LinkedIn, Slack, etc.
  • Conditional logic should be represented so that changes are updated in line, in real time.

Ideating On The Final Product

Putting the pieces together.

With a good idea of what was needed, from a business side and user perspective, as well as what worked within the initial system we tested, we began to outline the necessary pieces of the Mobile Flow Platform as well as ideate on what the experiences felt like.

  • Mobile app for running flows: A mobile product that is embeddable within other products, but can also stand on it’s own. Includes a “flow gallery,” which allows pre-built flows to be “installed” by the end user as well as an “activity” feature that keeps track of the flow usage within the app (successfully ran, errors, partially run flows, etc.). The core UX patterns focus on thumb friendliness, clear content hierarchy, and bringing focus to key moments.
  • Declarative app builder: There is a desktop product for building flows that we will leverage until the 2nd release. Beyond that, we will need a more focused builder that enables multi-channel building. An on-device builder could also be useful and is worth exploring.
  • Mobile Component Library: Simple, Compound, and Complex components + guidelines. Used for customers but can also be used for internal employees.

The mobile app was our core focus since the ability to run these flows was the most necessary as it promised immediate engagement gains. During our testing, users noted that they wanted information from all of our app products available, which left us with a decision to make: create a standalone app or build as an embeddable experience within other Salesforce apps. We chose both, as this product should be able to stand on it’s own if needed but also support and strengthen other applications. By creating an embeddable experience, we were acknowledging the various user needs across the company’s various products and invited the product teams to influence the component library we were crafting. To create the building blocks of a system, we also finalized three flows that we could launch with, which we started outlining within the initial user testing.

During the iteration phase, we identified where we could pull data from and what fields were available to us to show.

Can’t forget customization.

Customization was still important, and luckily we had a preexisting builder we could utilize for our V1 needs. It wan’t ideal, but it would get us through the first release and satisfy the need for declarative personalization. We could also leverage the components already built in this system, adjust them appropriately, use them as a base layer for our more ideal component library.

Finalizing & Refining

After pitching to our execs, we were given headcount for a small team. With this team in place, we had everything we needed to plot a release schedule, create backlogs, and test the feasibility and limits of this shiny new product. After iterating on the mobile app UX, I created a more specific structure for the initial application by outlining the functionality and components needed for the first release. To ensure that we weren’t building in a vacuum, we established partnerships with two other teams: the Lightning Flow Builder team to work towards a more ideal builder, and with the Field Service team to build flows outsides of the Sales use case (which we had built due to familiarity) which helped test the reach of our system.

Iterations focusing on “layered” UI to clarity of data.

We also established a plan for two pilots; one an internal pilot with our sales agents and an external pilot with one of our largest international customers. The internal pilot gives us a close understanding of the usefulness of the platform as well as an understanding of the usage numbers. An international pilot gives us an understanding of the difference of use case outside the US. It also enables us to have a more intimate test by observing an admin creating flows for their teams, deploying the flows, seeing them run in the field by the end user, and seeing them personalized by the admin.

As mentioned before, we also created a roadmap for our releases. The first release centered around the release of the Mobile Flow app (standalone and embeddable), which is supported by the initial builder. The app gives the user the ability to run flows, organize their own flows within a home screen, monitor the activity of flows if one isn’t complete or if errors occur, and an initial version of the “Gallery” of prebuilt flows available to end users. The rest of the releases focused on expanding the current offering as well as building a more ideal system.

Looking Forward, Building Outward

Still more to do.

While we had the first release outlined and the structure in place, now it was a matter of making it real and mapping out the future of the product. Our goal with the Mobile Flow team was to create and maintain a system, so we partnered with the core Sales team to bring the sales-focused flows to life and own them in the future, just as we were doing with the Field Service team. This allowed us to focus on mapping out the next steps of the system.

Our initial release focused on the curation of information and improving engagement. To continue improving the system we looked at a few key upgrades.

Updated components: We took a step back and identified the vision for some of our core components, like turning long vertical lists into accessible horizontally scrolling lists (carousels).

  • Expanded navigation: The first version of navigation allowed for thumb-friendly, conditional controls. We wanted to keep this focus on ease of use but, to better suit the growing group of business units wanting to use the product, we needed to make the core navigation more flexible. We needed to add in the ability to pause a flow, view the progress, and skip ahead as needed.
  • Multi-channel: With our mobile users on the go and always in different environments, our application needs to match the user’s needs. To do that, we are creating systems for “Multi-Channel” use, starting with voice. Channels should be seamless, allowing the user to swiftly go from one to the other with ease.

  • A mobile builder: In addition to creating a more ideal desktop building experience, we also want to give end users the ability to quickly edit flows on the go, ensuring that they have exactly what they need for their job. Check out the prototype gif in the research section above for an example. 

Measures Of Success

There were multiple layers of success with this project. On a surface level, we were able to start with a user-centered concept and self-start a solution that met business needs. We established a GA release and created a backlog for future releases. On a personal level, I found success in bringing people together across the company and very much enjoyed building a (sustainable) system from the ground up.

Here are some of the metrics we measured our overall success by:

  • Engagement: though creating a push based system, utalizing efficient UI, and flattened navigation.
  • Customization: Established at the ground level through crafting a component library and utilizing a declarative builder.
  • Innovation: We truly rethought what mobile design is at Salesforce as well as what mobile products are. We also created a moment-based product, which had never been done within our company.
  • Inspiration: We brought together teams that would never normally work together and showed others at salesforce that anyone can take a concept to product, no matter what their position.

Wrapping It Up

With the Mobile Flow product, we drove engagement giving users the exact information they need when the need it and made it incredibly simple to take actions with the necessary context provided. We also put personalization first and ensured that these flows were declaratively customizable. Lastly, we listened to our users and put all the Salesforce data that mattered to them in one place, regardless of product, helping to create focused, moment-based and meaningful interactions. We got to truly question what mobile is at Salesforce and deliver an answer.


Craig Villamor – VP Mobile Products
Dan Winterberg – Mobile Team Manager
Urvin Thakkar – Product Manager

Other Projects