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.
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.
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.
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.
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.
Translating this flow to the popover model, however, exposed a weakness of this paradigm.
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.
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).
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.
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.
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.
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
