What’s the Difference? Configured vs Custom Design
Avoid re-work with these universal definitions of what’s what
Imagine this: A project team meets to review initial designs. The brief has some limitations: no custom work and designs will use the Salesforce Lightning Design System (SLDS). In the meeting, the team notices that the designs include features that require additional work from a Salesforce admin, program architect, or developer. This falls outside what they thought was the agreed upon scope. Confusion ensues.
Maybe the designer didn’t know their suggestions weren’t achievable without a developer writing their own code. Or maybe the customer is arguing that configured designs are different from out-of-the-box designs. (They’re the same concept in Salesforce vernacular.) Now, the team is trying to figure out what they’re working with. Is it a configured design or a custom design? Then everyone looks at the designer for clarity. Been there? Many designers I talked with have experienced just this. So, today, both terms are being defined. 🎉
In short: Configured designs do not require writing your own code. Custom designs do.
We’ll break it down even further below.
If I’m being honest, it’s easy to see why people have been interpreting terms in different ways. For one, each team member is coming to the table with different contexts depending on their specialty (sales, account management, development, design, etc). What they all agree on is that a clear definition can make a real difference.
Let’s get everyone on the same page from the beginning.
Now re-imagine a version of the briefing above where the team agrees at the kickoff that they’re making a configured design. They’re probably more efficient. And they definitely avoid unnecessary rounds of re-work — for both designers and developers.
“A universal definition would help as there is a lot of flexibility via configuration. When re-work is required, it’s because the stakeholders didn’t fully understand the long-term impact of their decisions,” says Salesforce AVP Joel Dubinksy. The impact he mentions here could include the creation and upkeep of writing your own code, which is the key differentiator between configured and custom designs.
Below, these two designs are differentiated more objectively and precisely than ever before. Let’s break down the differences.
Configured design
If you can implement your design using a Salesforce builder tool or Admin options (without writing your own code), then it’s configured. You’ll also hear this called out-of-the-box. But wait.
There are two types of configured designs:
- Basic Configuration
- Declarative Configuration
The good news is: There’s a simple way to determine which one you’re working on. Ask if it requires declarative programming.
Declarative programming denotes the kind of click or drag-and-drop solutions that allow someone without coding knowledge to build an application. Some examples of this would be business rules, workflows or process flows that a Salesforce Admin or program architect would apply with App Builder, Flow Builder and Community Builder. If it requires declarative programming, then it’s a Declarative Configuration. If it doesn’t, then it’s a Basic Configuration.
Another benefit of configured designs is being able to take advantage of the three releases a year for platform innovation. For custom designs, it’s a bit different. Read on to see how.
Custom Design
If the design has a goal that can’t be achieved through the provided builder tools, then it’s custom — and you’ll need a developer to write your own code.
This is best when a business has a key differentiator that cannot be showcased or executed through configured designs. Joel focuses on these types of conversations as well, noting, “What’s most important is to create guiding principles on when customization is necessary.”
Generally speaking, companies opt for custom designs if there is a piece of functionality that is of high value or gives a competitive advantage.
For example: If a company’s core value is customer satisfaction but salespeople spend too long locating their customer-satisfaction rating on the platform, then a standout meter is worth the expense of having a developer write their own code. (See visual below.)
Here’s how it works: To design the custom component, the UX designers use Base Components from the Developer Library, Design Tokens and Component Blueprints from the SLDS. This helps cut down on development time and ensures that the custom component will fit seamlessly into the experience. The developer will then take the UX design and build the custom component based on the UX designers’ specifications.
Salesforce Experience Architect Matt Chock has collaborated on exactly this process. He reminds fellow designers, “Always check your designs with your developer partner and assess what’s possible and what’s not. Do it early and do it often to ensure you’re setting realistic expectations with your customer.”
Given each Salesforce project and customer has their own unique use case, it’s impossible to know exactly when you should make a configured or custom design but what we can do is outline a common set of helpful definitions. When it comes down to it, there’s no magic bullet. Each design choice should always be considered based on its particular needs. The best advice is to look for the sweet spot. Weigh user needs, business value, technical considerations and resources.
And, most importantly, set your team up for success by having shared definitions you all are aligned on.
Interested in in-depth design knowledge for Salesforce? Skill up with the User Experience Basics module on Trailhead. Want more? Get certified as a Salesforce UX Designer.
Thanks to Bill Clifford, Matt Chock, Heidi Reinfeld and Joel Dubinsky for their collaboration in bringing this story to life.
LEARN MORE
*Try the Lightning App Builder Trailhead module to build custom pages for Lightning Experience quickly with point-and-click tools
*Learn how to customize the Lightning Experience user interface without writing any code via the Lightning Experience Customization Trailhead module
*Skill up on Deep-dives into building data input flows with the “Build Flows with Flow Builder” trail on Trailhead
*See how to optimize and personalize your site with high-impact customizations with the Customize Your Community trail on Trailhead.
