Working within an Established Design Ecosystem
How nCino Approaches Design Patterns as a Salesforce ISV
Why is the navigation of so many websites across the top of the page? Why is the submit button on forms often in the bottom right? And why is the “X” to close a modal or dialogue most commonly in the top right? The reason is simple: because that’s where we expect them to be.
Web design trends are built upon the principle of habituation. With repeated exposure to the same pattern, users become accustomed to it and start to expect it on other sites or products.
To create an interface that any user will intuitively know how to use right away, designers can employ these established patterns on common elements like navigation, buttons, or tables. This way, even in a new experience, the user sees familiar elements that match their expectations of how a site will be organized and work. This reduces the need for training on a new system, and it reduces the cognitive load if the patterns are already engrained in the user.
The same habituation principle that holds true across different digital experiences also holds true within a single application.
If you need to display a table in two places within an app, it’s better for the user if both those tables look and behave the same. From a component reusability standpoint as well, why build two separate tables when you can build a component once and just use it in both places? Regardless of the type of data a user encounters or where it is in your application, they’ll already understand how to interact with it once they’re accustomed to your specific design pattern.
Working Within Established Patterns
Establishing consistent design patterns is straightforward when you’re building an application from the ground up. But what if you’re building on top of an established platform? One that’s already ripe with design patterns and conventions and reusable components? How do designers work within an existing design ecosystem to solve a unique set of business problems?
The design team at nCino grapples with this challenge every day, as our company builds a cloud-based bank operating system, using Salesforce as the foundation. Our features are accessed right alongside and sometimes within a standard Salesforce page, meaning that the lines between nCino and Salesforce are very blurry. We constantly need to ask ourselves:
“Should the user know that this is an nCino experience, or do we want our software to blend into the native platform so that our users get a seamless experience all the way through?”
When to Blend In
In general, our approach is that consistency with Salesforce will have all the benefits outlined earlier in this article. If our experiences look and behave just like those from Salesforce, then our users will have less cognitive load and will intuitively know how to interact with our unique features with little or no training.
Some difficulty emerges when the business problems we’re solving are more complex than what the platform can solve for out of the box. The industry of commercial banking is bursting with complex problems and issues like scale, multi-currency, risk mitigation, and compliance with policies and regulations. And those complex problems often warrant a unique and complex solution.
Our task on the design team is to solve a new problem in a new way, yet still make the solution feel like part of the underlying platform and design system.
One approach that’s had recent success is to take inspiration from native Salesforce components and design patterns, but to “upfit” them to meet our new complex use cases. Even if the original component is too limited for our needs, we can start with that as a base and extend it in meaningful ways.
Let’s say we need a list of items, and in our banking application it will comprise of different financial products — deposit accounts and loans and commercial services — all mixed together and displayed in a meaningful hierarchy. Perhaps Salesforce offers a variety of tables and lists, but each one can handle only one type of financial product at a time. Our path forward is to find the most applicable list pattern established by Salesforce, and then extend it with the capability of displaying different data types and parent/child relationships between rows.
This way, even though we might build this new component from scratch and own the code ourselves, the result will be something that feels familiar to users because they’ve encountered similar tables in Salesforce.
When to Stand Out
Our approach thus far has been to reuse the platform whenever possible, and even when we do need to build custom, to blend in as much as possible, with the goal of creating a consistent experience as the user transitions seamlessly between nCino and Salesforce.
This makes it really impactful when we do develop a component or pattern that is different from the standard platform. One particularly successful pattern we developed was a summary component — a simple bordered box that contains read-only fields that the user needs to complete their job below.
It might seem like a fairly simple or unremarkable pattern, but we’ve genericized it to work across our entire application, for every line of business. We’ve abstracted away from all of the specific use cases:
- summing up collateral values
- aggregating a bank’s exposure to a particular customer
- displaying the total amount of fees applied to a loan
And we’ve narrowed down the underlying problem of displaying non-editable summary data in a condensed and digestible format. By doing so, we’ve ensured the reusability of this summary component by solving for a shared design problem instead of focusing on seemingly disparate use cases.
In this case, we don’t want to align with an established Salesforce pattern. There was no base component that we could match or take inspiration from. So we introduced something visually new, that still uses the Salesforce color palette and design guidelines, so that it feels like it’s naturally part of the platform.
It’s About Balance
Ultimately we are striving for a balance between the two approaches. Not everything can be unique and new, or else the result would be overwhelming and disjointed. We want to blend in and reuse patterns where it makes sense and when we get the advantage of users’ habituation to an established pattern, and stand out and develop new patterns where our unique cases and complex business problems require it.
The unifying factor across all these components should still be the styles and guidelines set forth in the design system. At the end of the day, the user shouldn’t know which components nCino created custom and which come standard with the platform. Instead, we strive to create a consistent and cohesive experience across the entire application.
