Stop right now, thank you very much (“Stop Sign” by thecrazyfilmgirl, used under CC BY / Cropped and saturated from original)

Turning Constraints into Catalysts for Creativity

Lessons from Designing Inline Edit Experience in Lightning

You may have heard about the Salesforce Lightning Experience, which was launched to great fanfare during Dreamforce last year. This was a major milestone for us, but given the massive scope of the redesign, we had to prioritize our efforts for the initial release.

Unfortunately, some features, such as inline edit, didn’t make the cut. However, we soon learned — via Success Community, in-app feedback, and research sessions — that inline edit is a key feature that many of our customers use and love, and its absence is a major barrier to upgrading.

The product team immediately got back to work and started building inline edit for the following release.


Inline Edit 101

A record represents a real-world entity inside of a system. For instance, a lead record in Salesforce represents a prospective customer and it contains related information such as name, email address, phone number, etc.

One way to edit a record is via inline edit. In a nutshell, it enables a user to edit some part of a record without making a major switch between viewing and editing.

An example of inline editing a document title in Google Docs

This is a highly efficient method of updating a record. A user can make their changes without losing context and they can immediately return to what they were doing before.

In Salesforce Classic, inline editing is a feature that many customers have gotten accustomed to. However, the user experience is patchy. As an example, editing a basic text field opens the field inline, but editing a compound field (e.g. address) brings up an overlay modal.

Sometimes it appears inline
Sometimes it doesn’t

As we started designing the new inline edit for Lightning, we saw an opportunity to craft a new experience that’s clear, efficient, consistent, and beautiful. Along the way, we faced a number of constraints which led to key decisions and helped us arrive to the current incarnation of inline edit.


Auto-Saving vs. Explicit Save

In Classic, a user needs to click on “save” after editing a record inline.

Inline editing in Salesforce Classic. Note the explicit “save” button.

At first glance, this seems like a redundant step that could be removed by implementing auto-save so the experience could be more seamless.

Turns out it’s not that simple.

First, we quickly discovered that saving a record is an expensive operation. When a record is saved in Salesforce, 20 things happen in the background. Auto-saving records while editing would result in a significant performance hit, which means it wouldn’t be a feasible solution unless we implement overarching architectural changes first.

Additionally, saving a record triggers automated processes. For instance, a salesperson may have set up a process to send an email to a prospective customer when they have been converted to a lead. Auto-saving may accidentally initiate these processes while the user is in the middle of editing. This could result in major unintended consequences.

Verdict: auto-saving doesn’t work (at least in the short term).


Field-by-field vs. All Fields

Inline edit simplifies the editing experience when the user only needs to edit a few fields. We floated the idea of a “popover” for inline edit, which allows the user to edit a single field and quickly save it.

A “popover” example for inline editing

This seems like a fairly straightforward proposal, but it doesn’t address one common use case elegantly: field validation rules that involve two or more fields. As an example, an admin can set a rule on the “discount” field, which triggers an error if it’s more than 10% while the opportunity “amount” is less than $100,000.

Example of field validation rule in Classic

Translating this flow to the popover model, however, exposed a weakness of this paradigm.

Correcting field validation error in the popover model

Editing and saving fields individually becomes cumbersome when field validation rules are involved. The user has to wait after each save before they can edit another field, which reduces their workflow efficiency. The system also has to save the record each time the user saves a field, which places additional burden on the server.

Verdict: editing and saving fields individually seems simpler at first, but ultimately proves to be inefficient.


Rethinking the Flow

The two constraints we faced helped us narrow down the design direction. We knew that we should have an explicit save button, and that we should allow the user to make multiple field changes before saving.

Armed with these findings, we iterated and came up with a design where a whole section of the page becomes editable as soon as the user tries editing one of the fields in that section.

The revised design opens up the whole form when the user tries to edit one of the fields

This isn’t a pattern that’s extremely common in the wild, but testing it with users raised no red flags. Users were able to figure out what was happening and completed the tasks we asked of them with little difficulty.


Finessing the Design

Once we decided on this model, it was time to work on the finer details of the experience.

Accessible Design

We knew that we shouldn’t force users to hover to find things. In inline edit, this means explicitly showing what fields are editable and what aren’t (via showing a pencil icon, for instance).

Pencil icon indicates editability

We were worried that the pencil icons would clutter up the page when many fields are present on the page. However, we ultimately decided that clarity and accessibility are more important than simplicity.

Accessibility can help with clarity

To make the icons less prominent, we explored a number of color and size variations before finally reaching a happy medium, seen in the example above.

Smooth Transition from View to Edit

Switching into edit mode shouldn’t be jarring for the user. While transitioning, the user’s attention is focused on the one field they initially wanted to edit. Anchoring this field at the same position helps smooth out the “jump” between view and edit.

Transitioning from view to edit

Observe the animation above and pay particular attention to the positioning of the “mobile phone” field. Notice, too, how the field is automatically in focus so the user can immediately edit the field value.

Emphasis on Section’s Editability

While inline editing, a part of the page becomes editable, but the rest remains as is. To emphasize this difference, we wrapped the editable section inside of a card that’s slightly raised to distinguish it from the surrounding elements.

We also designed the save/cancel buttons to highlight this separation. The button set is “sticky” — it stays at the bottom of the page if the card extends beyond the fold, but it scrolls along with the card otherwise.

Editable section is emphasized in edit mode

Constraints: They’re Not All Bad

As designers, we love to explore possibilities and push boundaries, so it’s easy to think that technological constraints often put a damper on creativity. After all, we want design to work with — not dictated by — technology to provide a good user experience.

Facing limitations, however, forces us to take a second, third, and fourth look at our idea. What is the merit of the original idea? What are the existing limits? Why were they put in place? What are negotiable and what aren’t? Can we accomplish the same goal in a different manner?

Constraints need not be suffocating. They don’t always make your lives easier, but embracing them can lead to new paths and surprise you (in a good way).


“But out of limitations comes creativity”
 — Debbie Allen

Follow us at @SalesforceUX.
Want to work with us? Contact
uxcareers@salesforce.com
Check out the
Salesforce Lightning Design System

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.