Creating Confident Users Through “Clicks, Not Code”
On Collaborating to Build Clear, Consistent, and Adaptable Interfaces for Complex Logic Construction
One of the most compelling things about Salesforce is how intentionally it navigates the space between technical complexity and user-friendliness. Our customers can visually build applications connected to gigantic datasets and automate intricate business processes — with no coding required — while still giving Salesforce admins the power to customize and manage the entire experience for their organizations.
This ability is showcased in interfaces that make it easy for users to query databases — for example, running a report, filtering a list view, or setting conditional logic for an automated workflow. Salesforce has many ways to visually build database queries, but they weren’t always using similar interfaces. Recently, a number of Salesforce designers who’d noticed that such interfaces were inconsistent across products got together to address the issue.
Clarity, Efficiency, Consistency — In That Order
Consistency is an easy word for designers to toss around. It seems obvious, right? But simply making a UI that looks and behaves the same across Salesforce products isn’t good enough.
Consistency is the wrong approach, at least in the sense that making UIs that look and act the same doesn’t magically instill confidence in users. Clarity and efficiency must also come into play — one of the many reasons they come before consistency in Salesforce’s design principles. Prioritizing clarity and considering how elements fit into users’ workflows makes it possible to empower users at every experience level.
Each human being comes to our applications with unique context, knowledge, and interest. Our job as designers is to ensure that users are aware of all available functionality while optimizing for the task at hand. For example, some tasks may be so complex that they require writing code — or writing code for a simple task may be more efficient.
With clear, understandable interfaces optimized for the task(s) at hand, “consistency” can then scale to encompass a wide range of contexts, products, and form factors. The real output of this approach is confident users.
Using the UX Theme Framework
As Liz explains in this post about evolving the Lightning Design System at scale, we tackle problems like this with a UX theme.
A theme is a scoped deep dive into exploring how an experience should align across many products.
Back to our ad hoc team of designers. As we defined our goals and processes, I worked as the theme lead, reaching out to designers actively working on projects that used UIs to create logical expressions. We established a cadence for discussion, allocated a specific portion of our time each week, and started exploring the problem more deeply.
The first step was a broad design audit. Seeing lots of examples at once paid off! The group was able to quickly understand use cases along with previous designers’ approaches.
While such an audit can be time consuming and tedious, it offers a key benefit, kicking off natural collaboration and idea generation. Designers begin to see patterns across examples, and can take early passes at new ways to accommodate all use cases.
As a group, we agreed on an initial design approach, knowing that it wasn’t likely to be the final solution. Gut checks are really important early on in a process like this. As much as possible, we worked with existing design system elements, even if that meant using them in a new context.
Next, we created a simple prototype to begin some basic internal testing. We used the Lightning Design System (obviously), built it in Vue, hosted it on Heroku, and added an analytics tool that allowed us to play back each test session.
Since our end goal was user confidence, combining qualitative and quantitative feedback was crucial. We wanted users not only to be able to complete tasks easily, but to feel like they were easy. Successful tasks that take too long or are confusing don’t breed confidence — and feeling confident while completing a task incorrectly is even worse.
Cross-Disciplinary Collaboration
As the project progressed and we became more confident in the proposed solution, we reached out to crucial parts of Salesforce UX including Accessibility, UX Engineering, and Documentation. Each group provided valuable feedback, raising area-specific concerns like these:
- How do we ensure that every part of this interface works well with screen readers?
- Is the interface readable and understandable?
- Should labels exist for every row of inputs, or just once per column?
- What text for labels and placeholders should be dictated for consistency, and which should be flexible for its particular context?
In an effort like this, the amount of feedback can be overwhelming, and no one person can remember and manage everything. Documentation, delegation, and iteration are crucial. Each designer is responsible for contributing, collecting feedback, and discussing it with the group — all while maintaining an eye on specific use cases. Committed group members hold the group itself together.
After months of iteration, discussion, and use case testing, we were able to define the scope of the first phase of this effort. Our collaborative working documents became documentation for other UX folks, and we used those decisions to inform several forms of output, including a shared Sketch file and a new Salesforce Lightning Design System component blueprint, called Expression.
Supporting and Iterating
Officially documenting our work in the design system meant empowering other designers to use the new interface, but it also meant preparing for feedback as it became widely adopted. Elements of a design system should be living.
Each new Salesforce release brings new use cases and perspectives. Like the rest of the design system, components are regularly evaluated against product direction, customer feedback, and new perspectives. This keeps us honest — we know our design work solves problems for particular contexts in a specific moment, but it’s never immutable. Neither is the process of getting there.
Each contributing member of this UX theme continues to help by answering questions and advocating for adoption of the guidelines. We don’t force everyone to adopt every aspect of the system; instead, we want it to provide clear value that, in turn, generates the desire to adopt it. Every UX member — from research to documentation to accessibility — collectively holds the system together with a shared sense of ownership and dedication. And we believe that collective ownership makes an outsized impact on the experience of our customers and users, increasing their confidence and compelling them to do their best work, too.
Thanks to Kathy Baxter, Sarah Mei, and Alan Weibel for all your feedback.
Follow us at @SalesforceUX.
Want to work with us? Contact uxcareers@salesforce.com
Check out the Salesforce Lightning Design System
