What I learned making parallel mobile and desktop UX

Users don’t want to learn how to do things twice. Our users really like mobile but they want it to work the same as desktop or at least as intuitively as other websites can when they move from desktop to mobile and vice versa. We have some clients who are mostly mobile, some clients who are mostly desktop and somehow switch back-and-forth. 

Mobile runs two to three years behind desktop at Salesforce. This may seem harsh, but I think it’s a defensible statement. There are many features that have not yet come close to parity between desktop and mobile. If you want to have the same user experience (UX), you have to be creative and patient. Sometimes it means not adopting the latest features that come out on desktop only. But all is not lost. There are ways to be creative and provide equivalent functions on both mobile and desktop.

Here are some of the things I’ve learned about making record pages for parallel lightning and mobile UX. The suggestions are mainstream enough that I recommend you think about adopting them if you support mobile:

1. Don’t make mobile and desktop versions. This just doubles the work for you and slows down your ability to support Salesforce. And it pretty much guarantees that users will not have the same UX.

TOP of the page:

2. The highlight panel is nice on desktop, but takes up a lot of screen real estate on mobile. It also cannot be closed by default on mobile as on desktop. Therefore, we use the highlight panel on desktop and provide an equivalent function on mobile using a free and configure bowl add-on called x. The user sees one or the other but they’re about the same so it doesn’t seem to cause confusion. 

3. Dynamic buttons are important to deploy on both desktop and mobile. On the desktop, they are attached to the highlight panel, and a separate set of dynamic actions are attached to the top level component. This is very confusing to the admin, but keep them in sync. On mobile, the record header, and the buttons remain at the top of the screen and don’t scroll. Other than that, they work pretty much the same as on desktop.

4. If your users use the global publisher action button (+), they will be missing it on mobile. The global publisher action is great to place context-free actions, like adding a brand new contact, lead, task, or program event. This is typically done with a quick action. I’d like to be able to use flows but this does not result in a good UX unless you wrap each flow in a custom LWC. Users like the global action because using it doesn’t change the current context. In order to offer something similar for mobile, add the same quick actions as dynamic buttons on the record page for mobile after all the other buttons. This gives the user access to the same function that works intuitively.

5. The path component works well on desktop right under the highlights panel and brings to the top for records that have a process associated with them. It uses a lot of screen real estate but is pretty intuitive to the user. On mobile it uses even more screen space but it is such a powerful user experience that we continue to use it. We have experimented with putting the path component at the top for desktop and positioning it at the bottom for mobile. This takes a little getting used to but frees up real estate at the top of the mobile screen.

6. I sometimes provide the Quick Related List component at the top. I think it works well here on the desktop where it renders with very useful previews of records and even the ability to use row buttons to edit without leaving the page. By putting it at the top, there is plenty of room to get real work done. Since it takes four clicks on mobile to get to any records details, I don’t find myself using this except when I need access to a record that we don’t normally expose any other way. I have been known to display the component on the desktop only.

The Middle Section:

Now that we have gotten through the elements typically present at the top of a screen, we moved to the multi-column layout, which typically presents various flow tools, fields, and related records. 

7. Tabs are your friend here. Each of the columns should host one top level tab on the desktop. The desktop user will see the default tab open and can select others as needed. On mobile, the user will see only a list of the tabs as a vertical menu and will need to push into each to see the content and come back to see the top page again. Unlike desktop, when you push into a mobile tab selection, it takes over the entire screen. Pushing into and going back are fairly intuitive, however.

As an example, you might have a two-column  desktop layout split 1/3 and 2/3 with a top level set of tabs in each. Tools and short field edits might be presented in the narrow column. Related lists and other larger fields might be presented in the wider column. On mobile, the user will see two sets of vertical buttons, one for the left most column, and one for the rightmost column. Each button will represent one of the tabs. It’s fairly intuitive, but you don’t get the type of co-working between the two columns that you get on the desktop. For example, when the flow finishes on the desktop in the leftmost column, data in the rightmost column will refresh on the desktop. On mobile, the user may assume such things occurred, but they can’t see them until they go back and push into a different tab. They are operating blind so it can make sense to provide enough context so that they don’t lose their place in their work sequence. 

Here are some things that work well in the tabs, on both mobile and desktop:

  • App Record Details: this is an add-on component that gives a very similar experience on both desktop and mobile as dynamic fields or related records It’s also quite convenient for the admin. (You won’t need to use Related Record, Details, or Mobile Details if you use this consistently.) 
  • Enhance Lightning Grid: this gives a very similar experience on both mobile and desktop for related records, including row buttons, and list buttons. It’s not super simple to configure unfortunately. But it’s very powerful. (You won’t need to use Related Lists, Related List Singe, or Dynamic Related List if you use this one.  Related List Single works well enough but gives a very different UX on desktop than mobile. I think it’s best to use ELG throughout.)
  • Rich Text: This works well everywhere and functions as dynamic notification when coupled with conditional visibility. (Salesforce Page Advisor doesn’t like how many of these I have on a page but it doesn’t seem to add to the actual load time significantly.)
  • Embedded or canvas flows. On desktop you can use multi-column flows and they will reflow on mobile. Unfortunately the amount of vertical space a flow uses isn’t static so as you move from screen to screen the mobile can get “jumpy”. I prefer having only one flow component per tab for this reason.
  • SharinPix Album: This provides a way to see one of the attached photos and scroll through the rest. You can upload additional photos. It works on both desktop and mobile.

Accordions: On the desktop, one section must always be open and the others are closed. On mobile it renders as a vertical set of buttons (so it’s pretty much the same as a tab on mobile).

8. These items don’t perform equivalently between desktop and mobile so should be avoided or used in “close equivalent” pairs. An equivalence pair is two items on the one page layout, with one set visible on mobile and the other set visible on desktop. It’s a reasonable way to go. Avoid these unless you are comfortable with the very different user experience on mobile and desktop:

  • Related lists (only display a button to push into on mobile.)
  • Related record: no edit function on mobile
  • Dynamic related list: no support for mobile at all
  • Dynamic Fields: no support for mobile at all
  • Mocal pop-up flow buttons. These don’t use the screen properly on mobile.

The Bottom:

9. The case can be made that nothing needs to be at the bottom. However, the bottom is a very nice place to provide several things because users have been trained to find certain types of information at the bottom. There would be nothing wrong with a set of tabs to organize this if you find it getting unwieldy. It should be stuff nobody wants to see very often. These render fairly innocuously on desktop and just become menu items to push into for mobile.

  • If you didn’t put the Quick Related List component at the top, this is a good place for it. If you put it at the top for desktop only, you can put it at the bottom for mobile only.
  • Notes and attachments if they are not critical to the users work flows and included in a tab In the middle. It renders as a list on desktop but a single item to be pushed into for mobile.
  • System Information like date stamps. Unless they plan a key role for the user, this is also a nice place to put the record owner and record type. A couple of these system information fields don’t play well with Dynamic Field or App Record Detail. I sometimes resort to a Change Owner and Change Record Type dynamic button attached to the desktop and mobile components at the top if such things are critical to workflow. On desktop they can also be included in the Highlights panel. 
  • Shortcut links in a rich text link box to other work areas. Be sure to warn users that these take them away from the page.      
  • Help text in a rich text component. You may want to explain how to accomplish key tasks or add key change history at the bottom of the page if your users are into these types of things.
  • History: We revise our pages pretty frequently with user input so a history element makes our users more comfortable, and they do like seeing their suggestions implemented.

Leave a Reply

Your email address will not be published. Required fields are marked *