Sketch…meet the Lightning Design System
How I used Sketch to prototype a new timeline lightning web component for usability and maintainability
Salesforce designs its components to be consistent by applying a design pattern called Lightning Design System (LDS). LDS consists of brand and product design guidelines, design patterns and component blueprints for creating a unified UI in the Salesforce ecosystem. Unless you want your new component to stick out like a frankensteins monster on Salesforce branded pages it’s a good idea to be familiar with it.
In my previous post we discussed the research needed to ensure that your idea for a web component addresses key pain points. In my experience this is when people start writing code….if you do you may end up with something that meets requirements but that people don’t understand or like to use.
My recommendation is to design for — usability and maintainability before you start writing code. If you have access to someone who does this for a living…use them. If not, read on.
I use Sketch to prototype. But pen and paper also works.
Usability
Getting Started
Given that sketch is a popular prototyping application there is a UI kit available from the LDS website.
Let’s take a look at the UI kit and you’ll see how easy it is to use.
After downloading the UI kit a series of libraries is available to you.
The components that appear in your Sketch UI kit approximately match experience and base components that Salesforce supplies and can be configured to meet your use cases
Each component you drop into your Sketch artboard has attributes that can be overridden. This allows you to tailor the screen for your use case.
As an example, the Record Home component defaults to Opportunities, but you can override each base component to change the look and feel. In the example below we will modify the default characteristics to mimic the Contact record home page.
First prototype
In the previous post we documented the following requirements that directly impact usability:
- Design a timeline that plots related records to a lead, contact, account, opportunity and case on an interactive graph. A user should be able to see clusters of activity at a glance.
- Allow me to move the timeline back and forward similar to the existing universal timeline and health cloud timeline
- Allow me to zoom in and out to view records in a specific period of time and allow an administrator to set the default zoom
- Allow me to see up to 5 years worth of historical related records
- Plot key information on the timeline but allow me to hover to see more detailed information — ideally make this configurable
We looked at the Health Cloud timeline and liked the concept and design. My first prototype was to mimic a Contact object page layout and conceptualise what it might look like if it was a Salesforce provided Experience Component.
This is what I came up with in Sketch — based on the existing Health Cloud timeline user experience.
Salesforce provides a templated page designer called App Builder. Having an initial prototype is good but I need to put in into context of the various places that it might be on an actual page. This often reveals issues. So I fleshed out the prototype in different page layouts.
Assuming you don’t want your new lightning web component to stick out like frankensteins monster on the page then using Sketch is a great way to test ideas
Now I have something I can take to users and get feedback on. Here is a summary of some of the feedback.
Problem 1 — Consistency
The UI experience in the Health Cloud plotted individual patient records using custom images. When we provided context in a Sales or Service example using the existing pages they looked odd. Users didn’t understand why images looked different to those already shown in related lists.
Solution — Let’s use the standard icons provided by the Lightning Design System and keep a consistent experience.
Problem 2 — Information density
“How can I properly identify the record if I can only see the first 15 characters of the describing field?” — turns out the Health Cloud timeline shows only the first 15 characters of the field describing the record. This might be okay for patient data but when dealing with Cases, Opportunities, Tasks, Calls and Emails it isn’t sufficient to quickly get an overview of the record plotted.
Solution — We looked at some real world Opportunity Names, Case, Task and Email Subjects and played around with different compromises until 30 characters seemed workable — done.
Problem 3 — Superfluous fields
“What’s the purpose of being able to specify the Start Date?” “What does the Days to Show field do?” When I was talking through the existing design users were immediately confused by 2 fields. They are designed to let me change the zoom start data and range. “Isn’t it easier to just change it manually?” — Yes it probably is.
Solution — Remove ‘Days To Show’ and ‘Start Date’ fields.
Problem 4 — Key information missing
When interacting with the zoom I wasn’t giving the users any indication of the dates being used. Whilst the users could drag and widen the zoom they couldn’t tell exactly the date ranges being used.
Solution — Add a label to show the start and end date ranges.
The current tooltip shown when hovering over the Health Cloud timeline shows only one field containing more detail about the record. Users were not convinced that this gives them the information needed about each record to make decisions. Salesforce already provides a compact layout for each record…why couldn’t we use this?
Solution — Restyle the tooltip to be consistent with other popovers. Automatically show the compact layout for each record and position it to be consistent.
Maintainability
In the previous post we documented the following requirements that directly impact maintainability:
- Related records should include contacts, cases, emails, calls, tasks, attachments, campaign members, case comments and opportunities. Each related record should be configurable by an administrator for each independent object.
- Allow me to see up to 5 years worth of historical related records but allow an administrator to change the historical time range in the page setup as it might be different for each object. Let’s go with 0.5, 1, 3 and 5 years into the past and 0.5, 1 year into the future.
- Allow for an administrator to easily setup the types of records that should be plotted and allow them to differ for leads, contacts, opportunities and cases. There’s no point plotting Case Comments for Accounts
- Allow for runtime attributes to allow an administrator to change height, colour, time ranges and title
- Allow for administrators to use the date field of their choice to plot on the timeline for each record. For example I might use the CreatedDate or a custom date field
This step is often overlooked. For your component to be reusable it needs to have attributes that can be configured at runtime and they need to be intuitive to use. As well as designing the user experience you should also consider the administrator experience.
As well as designing the user experience you need to consider the administrator experience.
Designing for maintainability for a new timeline has 3 challenges:
1 — How I setup which records to plot for each parent object
We need records that administrators can setup and configure that determine which child records to plot for each parent object. But what attributes are needed?
Parent Object — Lead, Contact, Account etc
Object — The child object to plot
Icon — What icon to show to represent the object
Icon Background Colour — What background colour to use for the icon
Position Date — The field on the Object to use to plot on the timeline
Detail Field — The field to use for the initial short text next to the icon
Active — Quickly inactivate the record and ignore the record
2 — The runtime attributes of the timeline component itself
Sketch provides some basic layouts for the App Builder user interface. This means I can prototype the admin experience. Administrators can tell me what the attributes should be called, where they should be positioned and what values they needed.
a) Title — Allow me to change the title that appears in the top left
b) Colour — Changes the colour scheme for the x-axis. Don’t make it HEX or RGB though that’s hard for an admin to determine. Come up with themes. Set drop down values for ‘Cool Blue’, ‘Mean Green’ and ‘Mellow Yellow’.
b) Height — Allow me to change the height…but not in pixels. Make it more intuitive. Set drop down values for 1 — Smallest, 2 — Small, 3 — Default, 4 — Big, 5 — Biggest. You control the actual height.
c) Historical Time Range (Years) — Allow me to set the start date for the filter…in years. Set drop down values for 1, 2, 3, 4 and 5.
d) Future Time Range (Years) — Allow me to set the end date for the filter…in years. Given the fact that I’ll probably need fewer options set drop down values for 0.25, 0.5, 1.
e) Zoom Based On — This came out of user feedback. We were going to default the zoom to the current date. However, administrators wanted the option to override the default to highlight the latest activity. Set drop down values to ‘Current Date’ or ‘Latest Activity’
f) Zoom Range (Days) — Admins wanted to change the default time being zoomed into. Just an integer field with a max value of 365.
When speaking to Administrators the following key design decisions were made what the attributes were called, where they were positioned and what values they needed.
3 — Non Functional
When everything works it’s great but let’s design for when things go wrong. There’s nothing more frustrating than not being able to determine why something doesn’t work.
There’s nothing more frustrating than not being able to determine why something doesn’t work
My design principle will be to display errors in a consistent and easy to understand format.
Again in Sketch I could mock up the scenario’s that I could anticipate and get administrators feedback on error messages and clarity and make any adjustments. I could also use the suggested illustrations in the Lightning Design System for consistency.
Summary
Design starts with a good prototype that allows for you to anticipate usability and technical challenges early. The best designs consider usability and maintainability.
By following the above design principles your component will more likely meet users expectations and maximise your development effort by making it reusable
By prototyping we have a component that will require less rework later and leaves little room for misinterpretation by your developers.
The final prototypes look like this:
Next time we’ll look at the technical design of the component.
