A lot has been written about Salesforce best practices, this has come from official and unofficial sources, they are usually around the dos and don'ts on specific topics such as apex, sharing, security, etc. However, I have always felt not enough is out there on more high-level and general design and implementation approaches and considerations in Salesforce.
During the last 10+ years I have probably worked, been consulted on or had a quick peek on probably hundreds of orgs, based on this experience, here is my brief attempt on highlighting those issues I have often seen. For today, I have chosen to discuss UI/UX-First Design Approach
This design approach means the initial and core focus of your design is around how the application will look like, this approach has a strong focus on thinking how the user will view the application, how will they interact with buttons, navigation and records. The attention is not on how the data will be reported, shared, and more importantly, how it will be used to solve the business problem is meant to address.
You may be thinking by now "hey! what's wrong with that? Shouldn't the end-user experience be the most important thing?".
First, let me clarify that this approach could work well for other systems, especially, on completely custom applications in which you define the database to use, backends, the UI framework, programming language and so on, or in application with a very small scope, but this approach doesn't play well in Salesforce, especially at large scale.
Prescriptive requirements and its impact on the use of native features
One of its main causes are requirements or user stories that are too prescriptive and are the results of a bad translation between the actual business requirement and the technical solution the person writing them has in mind which somehow end up being what I would call "Prescriptive Technical Requirements". These are requirements in which the writer, instead of focusing on detailing on what is needed and why from a business perspective they try to specify how the solution should exactly be achieved, in some cases, they often intend to get the Salesforce solution to copy the behavior of another platform the writer has used.
There are at least two problems with this approach, the most obvious one is that it does not focus on the problem to solve, and second, it already tries to choose the best way to solve the problem and the person making this suggestion is quite often technically equipped to do that.
A few examples of these requirements would look like:
As an X user I want 2 fields in Opportunity records, last opportunity won and last opportunity lost and they should be populated on record creation so that I can easily see past opportunity information on a given opportunity
I would like the search to bring all the customer information when I enter a case number for case a customer opened, so I want a field in each case to contain all the case numbers of previous cases.
I think is easy to get the point of those examples. The effect of not challenging those requirements would be:
- Unnecessary fields.
- Cluttered page layout.
- An overly complex application which is hard to maintain.
- Poor reporting
- Poor adoption of standard Salesforce features.
Logical and Physical Data Model should come first
The second point but equally important is that in Salesforce the rules of the game are laid for you and they are very clear, all the declarative magic and speed to deliver features comes at a price, you must play by the rules and consider the constraints of the platform from the beginning, therefore, there is not much room to wiggle when it comes to building a strong foundation for the system, and if the foundation is wrong because you were thinking only on how the system will look like, the application is destined for failure.
To be a bit more concrete, this issue comes in the shape of data models that are built around the navigation between records or by taking into account that the UI will be a lightning component rather than a standard page so very little consideration is put on how the objects will be related to each other. This issue often also driven by the specific UI requirements I mentioned earlier but in this case it is the developer or architect actively making these decisions. In this case, the data model is built to mirror the UI that has been envisioned.
The side effects of this approach are:
- Duplicate records.
- Performance issues
- Workarounds to address sharing gaps.
- An application difficult to report on.
Finally, I am not saying UI and UX are not important, they are and should be kept in mind during design at all times, but it should not be the core foundation of the application. A data model and its logical relation to the business area it relates to (its domain) is what should constitute the foundation. An application with a solid data model can easily have many iterations to achieve a great UI that delivers a great user experience but the opposite would very likely require re-architecting several components almost from scratch.