How to turn a good idea for a Lightning Web Component into a better one
3 simple steps towards user centricity helps avoid bespoke one-of-a-kind components that no-one uses
Lightning Web Components is a new programming model for building Lightning Components. Oh wait you’ve no doubt heard that. Like a million times before. Most people get the why and what Lightning Web Components are but I was lacking an understanding of how I could design new components and make use of the new web standards and specialised services that form the programming model beyond simplistic examples.
Breaking the user interface into components gives developers and administrators new ways of working — and a new shift in thinking is needed to make the most of this shift in development styles. Lightning Web Components need to be reusable and useful. If your component ideas don’t start with that philosophy you’ll be developing bespoke one-of-a-kind components and adding to your technical debt.
1 - Start with a pain point or challenge
Ideas stem from a pain point. When working with customers recently it became clear that many of them wanted to quickly see clusters of activity they’ve had with their customers over at least 5 years. Activity for them doesn’t just relate to tasks and events but also cases and opportunities.
The pain point was that this was hard to achieve with current functionality. Salesforce provides many experience components to use on your Lightning pages but none of them are useful for visualising related records over a large period of time. I could use the related list component and the timeline component but neither provides a user experience that meets the challenge stated above.
The best way to have a good idea is to have lots of ideas - Linus Pauling
Linus Pauling once said that the best route to a good idea is quantity of ideas. Ideas are best sourced from you and your customers. It’s why Salesforce has an idea exchange and why a voting system helps qualify the quantity of ideas into an actionable list of good ideas that can incrementally improve the services that Salesforce offers.
2 - Research your idea
Crowdsource
The first step I took was to review what others were saying about similar features. It’s highly unlikely I’m the first person to have this idea. Source pain points from other people they often talk about use cases and features that you haven’t thought of. By looking at the idea exchange I could quickly assess:
a) How many other people have similar pain points - vote and points. The higher the number of votes the more interest I might have in addressing the need through a web component.
Higher points with an open status are challenges to solve
b) Will the idea be addressed by Salesforce any time soon - status. There’s no point working on an idea if it’s likely to be addressed by Salesforce. If it’s been delivered, will be delivered, or under consideration then perhaps wait for someone to do the hard work for you.
Great idea but will probably be addressed, or partly addressed by someone else
c) What are some key features that I might not have thought of - idea detail. I don’t know about you but I don’t have budget for extensive customer advisory boards and surveys. I need a more inexpensive way of reviewing what other people are asking for.
Review existing solutions
Once you have refined your idea you can then expand your search to include what existing solutions that may exist in the ecosystem to address your needs
The best place to search is the AppExchange.
Existing solutions may already exist. Here’s a universal timeline from the AppExchange.
The above timeline is a pretty good fit for what I need. It allows me to plot opportunities and cases on a single timeline, lets me see clusters of activity and can go back in time more than 3 years and I can configure what related records to plot. But it looks like it’s from the 1980s.
Health Cloud needed to plot related data and created a more modern look and feel.
This is more like what I’m after. However, this is not available as a reusable component that I can simply drag into a Lightning page in a Sales or Service use case.
I could also use Einstein Analytics to plot records on a timeline. It may require some compromise on look and feel but might be worth exploring if large data volumes were at play. I might come back to this idea later.
Speak directly to your end users
Ideally we would spend some time on end user interviews, customer advisory boards and group discussions. These would let me pose questions and solicit responses to early ideas. I don’t have budget for that. I do work for a company that uses Salesforce everyday though. I therefore have access to thousands of users that would have an opinion on my proposed timeline component - and best of all they work across varying roles.
For example, in sales, when I asked how they view past and future activities on the Opportunity record I invariably heard things like “oh, I just look at the related lists for attachments then use the timeline for meetings and calls, then use the activity list if I need to see meetings scheduled beyond 6 months.” This seemed like a lot of effort and there was a danger that customers were being called, emailed and followed up with too often. In a service environment being able to see clusters of case comments and other cases a customer has raised also seemed to hit the nail on the head — looking at a related list gave an agent no perspective of time. Today the agents review multiple related lists and often open multiple windows which is frustrating when you’re managing multiple cases at once.
As it turns out being able to see related record activity at a glance would be invaluable for multiple use cases.
3 - Refine your idea
I wanted to quickly see clusters of activity I’ve had with a person over at least 5 years. Activity for customers doesn’t just relate to tasks and events but also cases and opportunities.
Okay. So now I can iterate on my original idea and action the feedback I have to build on it. Based on the comments and suggestions in the idea exchange I have come up with the following ideas that I can design against.
- 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. The component should just know the context it’s in - like magic — administrators should be able to drag and drop on a Lightning page without specifying the object.
- The component should work for desktop and communities.
- 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 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 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.
- Plot key information on the timeline but allow me to hover to see more detailed information - ideally make this configurable
- Allow me to click on the timeline to navigate to the specific record to view/edit it
- 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
- Make sure it loads fast….even if there are 3,000 related records. This is important. I asked my colleagues how many records need to be designed for. 3,000 is a number that resonated with users based on the following logic that should cater for even the largest customers. If we assume we need 5 years worth of data (see requirement 5.) then taking an average count we could cater for — (1 case per week= 260 cases) + (1 opportunity per month = 60) + (3 tasks per week = 780) + (3 calls per week = 780) + (3 emails per week = 780) + (1 attachment per week = 260). I even went as far as asking some large customers to query for sample data in their environments to gauge if these numbers reflected reality…and they seemed to be close.
So, let’s recap.
There are a number of resources open to you to crowdsource and leverage learnings from existing solutions to better position your Lightning web component ideas. Addressing pain points from your own, and other peoples experiences will lead to a super useful, reusable component.
What makes a component useful is providing a solution to real end user challenge that you can empathise with - not one you have assumed exists.
Lightning Web Components are just that…they are components that by nature should be reusable across your user interface(s). Thinking about the use cases for your idea and the attributes that administrators should be able to setup at runtime will ensure you’ve thought about the user experience prior to designing your component. What makes a component reusable is providing the ability to change the look, feel and function declaratively without the need to code.
What makes a component reusable is providing the ability to change the look, feel and function declaratively without the need to code.
By following these 3 simple steps we can better ensure that our component ideas are useful and reusable.
Without even knowing it we’ve taken our first steps into user centred design (UCD).
Next time we’ll look at the proposed design for the component based on the above requirements. Stay tuned. Let’s work on actually designing and developing a new Lightning Web Component that meets our requirements.
