Project Overview
Job: Bellese – Subcontracted to E-Simplicity
Industry: GovTech / Health Services
Project Type: Process Improvement
Role: Lead Designer
Project Summary
While subcontracted into a Salesforce Service Cloud project with Bellese Technologies, I noticed that the product and development teams—many of whom were new to Salesforce—were applying field validation in inconsistent ways. Some screens used “required” fields that blocked progress without context, while others used custom validation logic that confused users and increased support issues.
To solve this, I created a Field Validation Decision Framework that guided teams on when to use Salesforce’s built-in “required” setting versus custom validation messages or disabled buttons.
Problem Statement
Inconsistent Validation Patterns Creating Confusion and UX Debt
When I joined the Bellese Salesforce project, the product and development teams were still ramping up their understanding of the Salesforce ecosystem.
While highly experienced in healthcare systems and agile delivery, most team members were new to Salesforce design constraints — especially how validation and required field behavior differs across:
Standard Lightning Components
Screen Flows
Custom LWCs
Back-end Validation Rules
This created a pattern of inconsistency:
Some forms used the “Required” property, which blocked progress but didn’t explain why.
Others used custom decision logic, leading to unpredictable messages.
In multi-step flows, users often hit abrupt blockers or contradictory error text.
Different developers were applying their own approaches to “requiredness,” resulting in fragmented user experiences and maintenance headaches.
In short — validation logic was inconsistent, opaque, and not grounded in a shared design philosophy.
Insights:
The Root Problem Wasn’t Just Technical — It Was Governance.
Through design audits, team interviews, and QA walkthroughs, I discovered that:
Product managers were defining requirements as “make this field required” without context of user behavior or conditional logic.
Developers were implementing validation based on technical ease, not UX intent.
QA was testing against functional expectations (“does it block submission?”) but not usability expectations (“does it explain why or how to fix it?”).
In a platform where users could create, edit, or complete forms across multiple UI layers (record pages, quick actions, flows, and console sub-tabs), this fragmented approach was hurting adoption and increasing support tickets.
What the team needed wasn’t just design direction — they needed a governance framework that codified when to use native validation and when to build custom logic.
Solution:
The Salesforce Validation Decision Framework
I developed a Field Validation Decision Framework — a simple, visual guide to help teams decide when to use:
“Required” field settings (for always-mandatory data)
Custom Validation Rules or Formulas (for conditional logic)
Disabled Button and Custom Messaging (for human-centered guidance and accessibility)
The framework provided:
A decision matrix that aligned product, UX, and dev choices.
A consistency model for where error messages appear (inline, modal, or toast).
Tone and language standards for user-facing error text.
Accessibility guardrails (ARIA compliance, focus states, and screen reader support).
Example Flow and LWC patterns implementing each option.
The core principle was:
“Validation should help people complete their work — not punish them for mistakes.”
Implementation
I rolled the framework out in three parts:
Team Training Sessions
Conducted walkthroughs with the product and dev teams to explain Salesforce validation hierarchy: Required → Custom Validation → Fault Path.
Used real examples from the Case Intake and Appeals workflows to demonstrate impact.
Playbook Integration
Documented the framework in the project’s UX Governance Confluence and Design System (Figma + Mural) so it could be referenced during sprint planning.
Design Reviews & Adoption
Embedded the matrix into the Definition of Ready for user stories:
“Does this field need to be required, conditionally validated, or contextual?”
Partnered with QA to rewrite test scripts to validate user feedback behavior, not just field enforcement.
Outcomes:
Impact Area | Before | After |
---|---|---|
UX Consistency | Ad-hoc rules, mixed logic | Unified patterns across screens and objects |
Development Time | High rework, unclear requirements | 30–40% reduction in build/test cycles for forms |
Error Clarity | Generic “Complete this field” | Contextual, human-readable feedback |
Accessibility | Mixed results | WCAG 2.1 AA compliance baseline met |
Team Confidence | Uncertain on when/where to use validation | Shared language and framework for decision-making |
The framework also became a teaching tool for new developers joining the Salesforce team, helping them ramp up faster and reducing dependency on senior admins for every UX decision.
Reflection
Creating this framework clarified a broader truth:
When teams are new to Salesforce, consistency is design.
By defining clear rules for when to use Salesforce’s native features versus custom logic, we not only improved usability — we also created alignment between product intent, technical feasibility, and user experience.
This small but strategic artifact has since been reused in other Bellese and subcontracted Salesforce initiatives as a lightweight UX governance tool, ensuring that as systems evolve, the user experience remains stable, predictable, and humane.