In this brief case study, I use some quick-and-dirty usability testing to evaluate the experience of using Pardot from within a Salesforce instance.

Image for post
Image for post
Image courtesy of Salesforce

I work for Salesforce as a User Experience Consultant. While the majority of my role is dedicated to helping customers of Salesforce Marketing Cloud to plan, design, and implement digital experiences for their customers, I also consult them on their use of the product itself.

As part of a previous customer engagement, I needed to familiarize myself with a related Salesforce product, Pardot. While Marketing Cloud is best suited for supporting 1-to-1 engagement with customers, Pardot is specialized for B2B businesses who rely heavily on the lead conversion process. The customer in question needed to be sure that Marketing Cloud was the best solution to fit their needs.

This led me to an exploration into Pardot. While I’m intimately familiar with Marketing Cloud, I had only seen Pardot a few times before. I had never had an extended hands-on, so I acquired a demo account to better familiarize myself. Pardot was previously an independent email service provider, which through a series of acquisitions became a part of Salesforce (Karkaria, 2013).

In an attempt to unite product experiences, Salesforce has made Pardot accessible through the standard Sales Cloud login. While this certainly adds a level of convenience, it makes for a poor user experience. The interface for Pardot is subsequently nested within an iFrame, which is wrapped in the regular Lightning interface. On larger displays (see Fig. 1), the padding around the iFrame of the app is extremely large (especially at the bottom). Certain standard interactions, such as scrolling, can cause strange and occasionally unexpected behavior, due to the nested vertical scroll box.

Image for post
Image for post
Fig. 1: Pardot app nested in lightning interface on large monitor

Furthermore, because the entirety of the Pardot app has been transplanted into a Lightning tab, the navigation is duplicated. At the top resides standard Lightning navigation (app switcher and tabs), while within the Pardot area is a lefthand (old style Lightning) menu.

The issues described above only impacts users accessing the Pardot interface from within Lightning. By visiting, Pardot can be used in a standard, non-nested app in its own window. Likely, customers who use both Sales Cloud and Pardot (a significant percentage of all users) would end up using Pardot from the Lightning interface. This also gives them quick access to other activities inside of Salesforce related to their Pardot campaigns.

For this evaluation, I’ll find a test subject and perform a “Thinking Out Loud” exercise. I’ll ask my participant to accomplish a few tasks and to speak what they are thinking as they attempt each one. I will occasionally ask questions to clarify if necessary. I’ll record the audio from the session for later reference.

This method is an ideal means to determine where the described problem causes users to be stymied. And as described in Usability Engineering, it’s adept for identifying users’ understanding of the system and misconceptions and is inexpensive to perform (Nielsen, 1994). It will help me to quickly see what issues arise from this awkward interface.


The duplicated navigation is extremely confusing for users (especially new ones). I started the exercise by giving my participant (who was familiar with Marketing Cloud, but not Pardot) some context to what Pardot is and how it fit into the Lightning interface before her.

In the first task, I asked them to start the process of sending an email from Pardot. After a bit of scanning and comments about what she was seeing, she hit the “plus” button at the top-right of the Lightning interface. From the “global actions” list that appeared, she chose“Email.” And with that, she was satisfied with her results. This perfectly demonstrated the usability issue in question. Of course, this was not the correct action. While this would allow a user to send an email from Salesforce, it is very different from sending a Pardot email. With another hint, I guided her to the lefthand navigation which hosted the intended Pardot email destination, and after a decent bit of confusion from the naming and menus, she arrived at the correct location.

This was reinforced by the second task: I asked her to open the page that would let her check the performance of her recent campaigns. Even though she was now familiar with the second, lefthand navigation, she opted to select “Campaigns” from the Lightning tab interface. Because of its position and her previous experience with software affordances, she was drawn to this navigation as a means of getting around.

A couple of other tasks highlighted more of the same concerns. How is a user meant to know when they should look in the main Lightning navigation versus what’s available in the Pardot lefthand menu? Unfortunately, there are tasks that are unique to the Lightning nav that cannot be accessed from just the Pardot nav, so users will need to use both at different times.


Using the Nielsen Norman principles for interaction design, the key challenges can be described under the following categories:

The biggest issue with the split navigation is that there is no consistency between the two menu types. For some users, this would expand to other Salesforce product they use. For those familiar with Salesforce, they’d likely rely heavily on the Lightning navigation to complete everyday tasks. A lack of consistency here is causing a lot of confusion in terms of where to find the desired result. And from a usability perspective, it requires users to bounce between two parts of the screen, making muscle memory more difficult to develop.

The affordance of tabs arguably comes from a variety of places in the real world (folder tabs, for instance). But more significantly, today’s users are accustomed not only to real world affordances, but also to digital ones they encounter on a daily basis. And tabs are a big part of that. It’s also important for users to be able to contextually place “where” they are metaphorically in the digital app. This allows them to orient themselves more quickly and more naturally find “where” they want to go next. This unnatural nesting of two paradigms for how panes and objects interact with one another are a major hinderance to that goal.

The horizontal (Lightning) nav does an incrementally better job at indicating to a user “where” they are in the app at any given time. It does so by providing better visibility into what action has just taken place (such as moving to a different area of the app). Doubling the navigation reduces the ability to see in one place where a user is and what has recently happened.


The most successful solution to the issues described would involve the conversion of Pardot to a native Lightning app. This would mean updating Pardot to use the native lightning system such that it can be opened as a standard Lightning app. All the areas in Pardot that can be navigated to from the lefthand drawer would instead be Lightning tabs or submenus. Then, users logging into Pardot through Salesforce proper would have an incredibly fluid experience with the rest of their instance. The doubling of menus and top chrome (settings, user, and search appear twice), in addition to the extreme amount of unnecessary padding, would be eliminated.

Granted, it makes a lot of sense how the app ended up in this state. To migrate the tech stack of Pardot into Salesforce would require immense resources. So instead, the choice was made to Lightning-ify Pardot, and eventually make it accessible through Sales cloud (in an iFrame, as it is now). This approach is not uncommon in the Salesforce world because acquisitions often take place, and completely re-building an enterprise app inside of another would sometimes be just as intensive as building a new app from the ground-up.

On a different note, while Marketing Cloud is never nested inside of Sales Cloud, the product could benefit from a similar “native Lightning” treatment, as many of its users use both products. Recently, the nav in Marketing cloud was refreshed and made “similar to Lightning” which is almost more confusing than being entirely distinct. The new nav suffers from the same usability issues that the old navigation did (lack of visibility and affordances), because the UI has changed (with a “fresh coat of paint” consisting of new colors, fonts and icons), but the UX is identical. A version that was truly Lightning was almost released, but changed last-minute so as not to change the experience for customers too drastically.

B2B product teams seem to have more of an aversion to making significant changes to UX than B2C products, for fear of impeding on business user activities. While this is a valid concern, and rapidly changing the product would make for an unreliable business experience, the regular refresh to how things work shouldn’t stop teams from making the updates necessary to improve the user experience. Users will adapt and learn the newer “unfamiliar” way of doing things, even if they’re frustrated to begin with because it’s different. Especially when the end result after they’ve adjusted is a more efficient, effective, and pleasant user experience.

Image for post
Image for post
Image courtesy of Salesforce

Update (November 2018)

At Dreamforce 2018, Salesforce announced Lightning for Pardot, directly addressing the usability concerns listed above. In fact, they integrated Pardot into true lightning tabs, precisely as recommended. A follow-up study is required to evaluate this new user experience and determine how well it addresses the aforementioned pain points.


Written by

Product Designer @ Salesforce. I dabble in email and front-end development. 👨🏻‍💻

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store