• Cert++
  • Practice
  • Certle
  • Review
  • Tracks
  • Checklist
  • Guides
  • Upgrade
Cert++
  1. Home
  3. Platform User Experience Designer

Platform User Experience Designer

Checklist progress

0/151Learned

Platform User Experience Designer

Study Checklist

  • Platform Administrator
  • Platform App Builder
  • Platform Foundations
  • Platform Developer
  • Platform Administrator II
  • Agentforce Sales Consultant
  • Agentforce Service Consultant
  • Platform Data Architect
  • Platform Development Lifecycle and Deployment Architect
  • Platform Identity and Access Management Architect
  • Platform Integration Architect
  • Platform Sharing and Visibility Architect
  • Heroku Architect
  • B2C Solution Architect
  • Experience Cloud Consultant
  • Agentforce Field Service and Operations Consultant
  • Agentforce Nonprofit Consultant
  • Data 360 Consultant
  • Omnistudio Consultant
  • CRM Analytics and Einstein Discovery Consultant
  • Platform User Experience Designer
  • Platform Strategy Designer
  • B2C Commerce Developer
  • JavaScript Developer
  • Omnistudio Developer
  • Platform Developer II
  • Marketing Cloud Engagement Administrator
  • Marketing Cloud Engagement Specialist
  • Marketing Cloud Engagement Consultant
  • Agentforce Sales Foundations
  • Business Analyst
  • Marketing Cloud Engagement Developer
  • Marketing Cloud Engagement Foundations
  • Agentforce Specialist
  • Agentforce Life Sciences Consultant
  • B2B Commerce Administrator AP
  • B2B Commerce Developer AP
  • Agentforce Consumer Goods AP
  • Agentforce Financial Services AP
  • Agentforce Health AP
  • Agentforce Manufacturing AP
  • MuleSoft Integration Foundations
  • MuleSoft Developer
  • MuleSoft Developer II
  • MuleSoft Platform Integration Architect
  • MuleSoft Platform Architect
  • Tableau Desktop Foundations
  • Tableau Data Analyst
  • Tableau Consultant
  • Tableau Server Administrator
  • Tableau Architect

Checklist progress

0/151Learned

  • Selecting the correct research approach (generative vs. evaluative) depending on whether the team is exploring a problem space or validating a proposed solution.
  • Choosing between qualitative research methods (contextual inquiry, interviews, diary studies) vs. quantitative methods (surveys, analytics) given a specific business constraint such as limited access to users or need for statistical confidence.
  • Defining research objectives and writing a discussion guide for a stakeholder or user interview, including how to structure open-ended questions to avoid leading the participant.
  • Selecting the appropriate discovery tool (empathy maps, journey maps, stakeholder maps, affinity diagrams) based on the research goal and available inputs.
  • Determining appropriate participant screening criteria and recruitment strategies when end users are difficult to access directly (e.g., using proxy users, SMEs, or customer success managers as substitutes).
  • Using competitive analysis or benchmarking against industry-standard UX patterns to establish baseline design requirements when no direct user access is available.
  • Determining when to use card sorting vs. tree testing for evaluating information architecture decisions.
  • Identifying the appropriate use of usability testing vs. A/B testing given constraints around sample size, development phase, and decision type.
  • Using stakeholder interviews and contextual observation to surface hidden pain points that stakeholders cannot articulate in written requirements.
  • Identifying when existing analytics data (page views, drop-off rates, click paths) is sufficient to define design requirements vs. when primary research is still required.
  • Synthesizing research findings using affinity mapping to cluster themes and identify the most impactful problem areas to address in a Salesforce solution.
  • Building an as-is journey map from interview and observation data to identify moments of friction in the current user experience.
  • Translating raw user research findings into a prioritized problem statement (How Might We statement) to guide design strategy.
  • Aligning stakeholders around research findings by presenting evidence (quotes, observations, data) in a compelling format that builds organizational support for a UX-centered approach.
  • Conducting a heuristic evaluation against Nielsen's 10 heuristics to identify UX deficiencies in an existing Salesforce implementation.
  • Differentiating the responsibilities and platform behaviors of the Salesforce Admin, End User, and Executive personas in the context of UX design.
  • Mapping Salesforce standard personas (Trailblazer, Admin, End User) to their typical Salesforce platform touchpoints and pain points.
  • Identifying which Salesforce UX persona is best represented by a given job description or workflow scenario (e.g., configuring flows vs. logging activities vs. reviewing dashboards).
  • Constructing a UX persona document from research data, including goals, frustrations, behaviors, and technology comfort level, to guide Salesforce configuration decisions.
  • Recognizing how Salesforce's contextual data (related lists, activity timelines, embedded analytics) reduces user effort compared to switching between external systems.
  • Identifying which Salesforce platform capability (automation, collaboration, analytics, guided selling) provides the most value given a described business problem.
  • Evaluating whether a requested customization adds genuine user value or introduces unnecessary complexity given a described current-state experience.
  • Applying design thinking phases (Empathize, Define, Ideate, Prototype, Test) to determine the correct next action given a described project scenario.
  • Selecting the correct UX deliverable (persona, journey map, wireframe, prototype, user story) based on the project phase and the audience receiving it.
  • The four levels of UX fidelity: wireframe (structure only), mockup (visual design added), prototype (interactive), and live build — and the defining characteristic of each.
  • Matching UX fidelity level (wireframe, mockup, prototype, live build) to the correct validation goal given a described scenario.
  • Distinguishing when to use low-fidelity wireframes vs. high-fidelity prototypes given constraints around stakeholder expectations and development timeline.
  • Choosing between a clickable prototype and a paper prototype for early-stage usability testing given resource constraints.
  • Using an empathy map (Think, Feel, Say, Do quadrants) to consolidate user interview data and reveal gaps between what users say and what they actually do.
  • Selecting a future-state journey map vs. an as-is journey map based on whether the team is documenting a current pain point or designing a desired experience.
  • Determining when a service blueprint adds value over a journey map when multiple internal systems and back-office processes are involved.
  • Explaining how corporate brand guidelines (color palettes, typography, logo usage) translate into Salesforce customization decisions such as themes and Experience Cloud branding.
  • Describing how consistent branding across internal Salesforce org and external Experience Cloud site affects user trust and adoption.
  • Identifying the risk of violating brand standards when custom CSS overrides conflict with SLDS tokens in a Lightning Experience implementation.
  • The four POUR accessibility principles (Perceivable, Operable, Understandable, Robust) and what each principle addresses.
  • Applying WCAG 2.1 Level AA success criteria to identify accessibility failures in a described UI layout (e.g., insufficient color contrast, missing alt text, keyboard trap).
  • Applying WCAG minimum contrast ratio requirements (4.5:1 for normal text, 3:1 for large text) to evaluate whether a proposed color scheme passes accessibility standards.
  • Mapping a given UI accessibility deficiency to the correct POUR principle (Perceivable, Operable, Understandable, Robust).
  • Identifying Gestalt principles (proximity, similarity, continuity, closure) as they apply to Salesforce page layout decisions.
  • Applying the concept of cognitive load theory to evaluate whether a proposed Salesforce page layout introduces unnecessary friction.
  • Distinguishing when to use progressive disclosure to reduce cognitive load vs. when showing all information upfront is preferable given user role and task frequency.
  • Selecting the correct visual hierarchy technique (size, weight, color, whitespace) to guide user attention on a record detail page.
  • Applying affordance and feedback principles (visible clickability cues, loading states, success confirmations) to ensure users understand system status after taking an action in Salesforce.
  • Evaluating information architecture (IA) decisions — navigation labeling, grouping, and hierarchy — to ensure users can predict where to find functionality without prior training.
  • Writing actionable, non-technical error messages and microcopy for Salesforce forms.
  • Distinguishing inline validation errors from page-level error summaries in Salesforce forms and when each presentation is appropriate.
  • Identifying mobile UX constraints (small screen real estate, touch targets, thumb zones) that should influence Salesforce page layout decisions for the Salesforce mobile app.
  • Distinguishing between responsive design (layout adapts fluidly to screen size) and adaptive design (distinct layouts served per breakpoint) and identifying which approach is used in Lightning Experience and Experience Cloud.
  • Applying mobile-first design principles to prioritize which fields and actions appear on a Salesforce mobile compact layout.
  • Determining when a mobile-specific compact layout is required vs. when the standard desktop layout is acceptable given a described user scenario.
  • Identifying the UX impact of offline capability limitations in the Salesforce mobile app when designing for field service or remote worker personas.
  • Distinguishing between divergent thinking (ideation, brainstorming) and convergent thinking (prioritization, decision-making) and when to apply each in a design process.
  • Determining how to build empathy with users (shadowing, contextual inquiry, think-aloud protocols) when direct access to end users is restricted by the client.
  • Identifying the correct phase of the Double Diamond model (Discover, Define, Develop, Deliver) to apply given a described project situation.
  • Recognizing the role of rapid iteration and feedback loops in human-centered design and when a team should cycle back to earlier phases instead of moving forward.
  • Applying jobs-to-be-done (JTBD) framing to reframe a stakeholder's feature request into a user-centered problem statement.
  • Evaluating whether a proposed Salesforce solution adequately addresses the user's mental model vs. the system's data model.
  • Applying an assumption map (known vs. unknown, high vs. low risk) to prioritize which design assumptions must be validated through research before committing to a solution direction.
  • Selecting the appropriate co-design or participatory design technique to involve users when the team has limited research budget and compressed timeline.
  • The five phases of the Design Sprint methodology: Map, Sketch, Decide, Prototype, and Test.
  • When the Design Sprint methodology is an appropriate compressed alternative to a full discovery and design process.
  • Differentiating inclusive design from accessibility: understanding that inclusive design is a methodology that benefits all users, not just those with disabilities.
  • The three Microsoft Inclusive Design principles: Recognize Exclusion, Solve for One Extend to Many, and Learn from Diversity.
  • Explaining the concept of situational disability (temporary or environmental impairment such as a broken arm, bright sunlight, or noisy environment) and why inclusive design addresses a broader audience than traditional accessibility compliance.
  • Identifying how designing for edge cases (users with motor, vision, cognitive, or situational impairments) creates solutions that improve usability for the entire user population.
  • Applying Microsoft Inclusive Design principles to a Salesforce UX decision.
  • Identifying how bias in persona creation or user research can lead to exclusionary design decisions in a Salesforce solution.
  • Selecting between standard objects (Account, Contact, Opportunity, Case) and custom objects based on the user's workflow and data relationship requirements.
  • UX impact of lookup vs. master-detail relationships on related list display and record access.
  • UX implications of master-detail relationships: rollup summaries and cascading deletes.
  • Identifying how junction objects model many-to-many relationships and what UX considerations arise when users need to work with junction object records.
  • Distinguishing how Activities (Tasks and Events) behave on the activity timeline and how that affects the UX design of sales or service workflows.
  • Evaluating when to rename standard objects and fields to match business terminology vs. when doing so introduces confusion with Salesforce documentation and help text.
  • Distinguishing between Record Home pages, App Home pages, and Home pages in Lightning App Builder and identifying which page type to customize for a given UX goal.
  • Configuring Lightning page layouts using the Lightning App Builder to optimize field density, component placement, and tab structure for a specific user role.
  • Choosing between Dynamic Forms and standard page layouts to control field visibility and reduce clutter on record detail pages.
  • Using compact layouts to surface the most critical fields in record highlights panels, Kanban views, and mobile cards.
  • Applying List Views with filters and column selection to improve user efficiency in high-volume record management scenarios.
  • Configuring Kanban views and when they are preferable to list views for managing pipeline or process stages.
  • Comparing the UX implications of using tabs vs. accordion sections vs. collapsible panels in a Lightning record page to manage dense information.
  • Deciding when to use related lists vs. related list quick links vs. related record components based on how frequently users need to navigate to child records.
  • Using Path (Sales Path / Service Path) to provide stage-based coaching and highlight key fields at each process stage.
  • Configuring Dynamic Actions (show/hide buttons based on field values or user criteria) to reduce action bar clutter and surface only contextually relevant actions to the user.
  • Identifying the UX role of field-level help text vs. in-app guidance prompts in reducing user confusion without cluttering the interface.
  • Using Report and Dashboard components on Lightning pages to surface actionable analytics in context, reducing the need for users to navigate away from their primary workflow.
  • Distinguishing between global actions and object-specific actions and their respective use cases.
  • Identifying when Quick Actions (object-specific or global) improve task efficiency by pre-populating fields and launching modal dialogs without full page navigation.
  • Which Quick Action types (Create, Update, Log a Call, Flow, Custom) are available in global vs. object-specific contexts and their UX implications.
  • Using default field values to reduce manual data entry in Salesforce forms.
  • Using formula fields to auto-populate fields and reduce manual data entry.
  • Using dependent picklists to guide user choices and enforce valid field combinations.
  • Applying validation rules to enforce data quality at the point of entry and evaluating their UX cost (friction) vs. benefit (data integrity).
  • Selecting Screen Flows over Guided Action Lists vs. standard page layouts when a user must follow a prescribed multi-step data-entry process.
  • Determining when Flow's Screen component conditional visibility is preferable to building separate screens for branching logic.
  • Identifying when a Guided Action List (a flow-based checklist component) is preferable to a sequential Screen Flow for tasks that users complete non-linearly or across multiple sessions.
  • Using Process Automation (Flow-triggered) to auto-populate fields or send alerts, reducing the number of manual steps a user must take.
  • Evaluating the use of Macros in Service Cloud to enable agents to execute repetitive multi-step tasks with a single click.
  • Choosing the correct Lightning App configuration (navigation items, utility bar, app branding) to align with a user persona's primary workflow.
  • Using App Manager to assign custom apps to profiles and permission sets and the UX implications of app assignment on user experience.
  • Deciding when split view vs. standard navigation vs. console navigation in Lightning Apps is most appropriate for a described user workflow.
  • Identifying when to use the Salesforce Console app navigation model (multi-tab, split view, pinned regions) for high-volume users such as service agents who need to manage multiple records simultaneously.
  • Configuring the utility bar (open CTI, notes, recent items, flow launcher) to surface frequently used tools without disrupting the main workspace.
  • Evaluating the role of global search and Search Layouts in helping users find records efficiently.
  • Selecting the appropriate in-app guidance mechanism (Prompts, Walkthroughs, or Help & Training) for a specific onboarding or adoption scenario.
  • Distinguishing between floating prompts, docked prompts, and targeted prompts in In-App Guidance and when each is appropriate.
  • Determining when a multi-step Walkthrough (In-App Guidance) is preferable to a single targeted prompt for introducing a new feature or process change.
  • Configuring custom help menu items and Salesforce Help & Training links to surface role-specific learning resources.
  • Evaluating when Trailhead or myTrailhead (Enablement) is an appropriate learning delivery mechanism vs. in-app walkthroughs for Salesforce feature adoption.
  • Applying custom themes in Lightning Experience (logo, colors, default branding images) to align the internal org with corporate brand standards.
  • Configuring Experience Cloud site branding (header, footer, color palette, fonts) using the Experience Builder branding panel.
  • Identifying the constraints of declarative branding (no custom CSS allowed in some contexts) and when to escalate to a developer for custom SLDS token overrides.
  • Determining the UX impact of applying a dark vs. light background theme in a Salesforce console app used in low-light or high-volume environments.
  • Designing task scenarios for a usability test that are realistic, non-leading, and appropriately scoped to the design elements being evaluated.
  • Defining recruiting screener criteria to ensure usability test participants represent the target user population and are not biased by familiarity with the product.
  • Determining the appropriate number of participants for a usability test session given the goal of finding major usability issues vs. reaching statistical significance.
  • Selecting between moderated vs. unmoderated usability testing given constraints on user availability, facilitator skill, and research depth required.
  • Choosing between remote and in-person usability testing methods given geographic distribution of users and required observation fidelity.
  • Selecting guerrilla (hallway) testing as an appropriate low-cost validation method for early-stage designs when formal participant recruitment is not feasible.
  • Planning a first-click test or five-second test to validate whether a proposed navigation structure or landing page communicates its purpose effectively.
  • Distinguishing between formative testing (used to improve a design during development) and summative testing (used to evaluate a completed design against benchmarks).
  • Defining the role of UAT (User Acceptance Testing) in a Salesforce implementation and how it differs from UX usability testing.
  • Think-aloud protocol: purpose and output in usability testing.
  • Co-discovery: purpose and output in usability testing.
  • Retrospective probing and concurrent probing: purpose and output in usability testing.
  • Applying a System Usability Scale (SUS) questionnaire to quantify perceived usability after a usability test session and interpreting the score.
  • Structuring a usability test findings report: how to communicate severity ratings, patterns observed, and design recommendations to stakeholders who did not observe the sessions.
  • Using screen readers and keyboard navigation testing to validate WCAG operability compliance of a Salesforce UI.
  • Using color contrast checkers to validate WCAG perceivability compliance of a Salesforce UI.
  • The four severity levels for usability findings: critical, serious, minor, and cosmetic.
  • Determining which usability findings to address before launch vs. post-launch based on severity and resource constraints.
  • Deciding when a design change discovered during testing requires a new round of prototype validation vs. can be implemented and validated in production.
  • Managing stakeholder pushback on user-validated design changes by presenting evidence from usability testing and framing changes as risk mitigation.
  • Using analytics and feedback tools (Salesforce Feedback Management, in-app surveys) post-launch to identify usability regressions and guide iterative improvements.

Describe SLDS and its purpose.

0/7

  • Explaining the core purpose of SLDS: providing a shared visual language and CSS framework that ensures consistency between custom components and native Lightning Experience.
  • Describing the relationship between SLDS and Lightning Web Components (LWC): LWC base components automatically apply SLDS styling; custom LWC components must manually apply SLDS.
  • Identifying what SLDS does NOT provide: it is a CSS framework and visual specification, not a JavaScript component library, and does not replace LWC or Aura component logic.
  • SLDS design tokens: purpose and when to use them in a Lightning component.
  • Explaining SLDS design tokens and how they allow global visual changes (color, spacing, font) to propagate consistently across a custom Lightning component.
  • SLDS utility classes: purpose and when to use them in a Lightning component.
  • SLDS component blueprints: purpose and when to use them in a Lightning component.

Given a scenario, determine out-of-the-box design and configuration consistent with the look and feel of Lightning Experience.

0/5

Evaluating when a standard LWC base component (lightning-button, lightning-card, lightning-datatable) already follows SLDS guidelines vs. when a custom implementation is required.

Learn this concept
Unseen

Selecting the correct SLDS component blueprint (data table, card, modal, badge, pill) to match a described UI requirement without custom development.

Learn this concept
Unseen

Identifying which SLDS utility classes (spacing, alignment, text, grid) should be applied to achieve a described layout without writing custom CSS.

Learn this concept
Unseen

Using SLDS icons (utility, action, standard, custom, doctype sprite categories) correctly in a custom component to maintain visual consistency with Lightning Experience.

Learn this concept
Unseen

Selecting SLDS data table variants (with row actions, with inline editing, read-only) and identifying the appropriate variant given a described user task.

Learn this concept
Unseen

Given a scenario, utilize SLDS to create new and customized component functionality.

0/6

  • Identifying the trade-offs of styling a custom LWC with SLDS utility classes vs. writing scoped CSS in the component's .css file, and when each approach is appropriate.
  • Applying SLDS design tokens to override default visual styles in a custom LWC without breaking Lightning Experience consistency.
  • Using SLDS Blueprints as a reference specification to implement a custom component that visually matches native Lightning Experience elements when no base LWC is available.
  • Selecting the correct SLDS state classes (is-active, is-open, is-selected, has-error) to reflect dynamic component states in a custom Lightning component.
  • Applying SLDS validation patterns (inline error messages, required field indicators, help text icons) to a custom form component to communicate input errors accessibly.
  • Using SLDS loading spinner and skeleton screen patterns in a custom component to communicate system processing state and prevent users from perceiving the interface as broken.

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other Platform User Experience Designer studiers. 593 members and growing.

Go to Discord

Evaluating when a standard LWC base component (lightning-button, lightning-card, lightning-datatable) already follows SLDS guidelines vs. when a custom implementation is required.

Explainer

Learn More

Practice Question

Keep going

Next conceptSelecting the correct SLDS component blueprint (data table, card, modal, badge, pill) to match a described UI requirement without custom development.

Checklist progress

0/151 (0%)

0 of 151 concepts learned

Tip: You can filter concepts by status.

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other Platform User Experience Designer studiers. 593 members and growing.

Go to Discord

Explainer

Salesforce Lightning Design System (SLDS) base components provide the standard look and feel for Lightning Experience and update automatically with design changes. Use these components whenever possible to ensure consistency, but switch to custom implementations when a base component lacks a specific feature required by the design guidelines.

Core information
  • Base components are built from SLDS design guidelines and follow them closely to maintain the Lightning Experience look and feel.
More details and nuances
  • Do not depend on the internal markup or CSS classes of base components because they can change in future releases and cause unrecoverable errors.