Free Practice Questions for Salesforce Plat-UX-101 Exam

The correct answer is C. Scale, using relative size to signal importance, exactly as identified by the uploaded study guide.

The problem is that users cannot easily determine where to look because too many visual elements compete for attention. The study guide therefore selects scale as a technique for establishing hierarchy.

Using relative size enables the designer to communicate that some elements are more important than others. A larger heading, key value, or primary action can attract attention before smaller supporting information, creating a more deliberate visual reading sequence.

Option A would weaken hierarchy because keeping all elements at similar sizes reduces the visual distinctions users rely on when scanning a page.

Option B incorrectly reduces hierarchy to simply putting larger elements at the top. Position can contribute to hierarchy, but the guide specifically identifies relative scale as the relevant principle in this scenario.

The key UX concept is that visual hierarchy should help users perceive importance before they consciously analyze every element. When size is applied intentionally, users can more rapidly distinguish primary information from secondary content.

Therefore, Cloud Kicks should use scale to establish clearer emphasis and reduce competition among page elements.

Study Guide reference/topics: Visual hierarchy, scale, relative size, attention, UX Fundamentals.

==================================

The correct answer is B. Add a List View component to the home page configured to show a custom list view filtered to show assigned and open cases, as specified in the study guide.

The UX requirement is to make the relevant queued Cases immediately visible so that help desk users can begin resolving work quickly. The study guide selects a filtered List View component placed directly on the team's home page.

This approach reduces the amount of navigation required before users can identify actionable cases. By filtering the list to show the appropriate assigned and open records, the home page becomes a task-oriented starting point rather than merely a general landing page.

Option A refers to a Case Assignment component, while option C refers to a Case Inbox component. Neither is the approach identified by the answer key.

The important design consideration is that the team already has a predictable record-selection criterion: the Cases must be relevant to the help desk member and remain open. A configured list view can express those conditions declaratively.

The study guide therefore favors bringing the right Salesforce records directly into the user's work context through a standard filtered list-view experience.

Study Guide reference/topics: List View component, filtered Cases, home pages, help desk productivity, Declarative Design.

==================================

The uploaded study guide identifies B. User Engagement Dashboards and Reports as the correct tool for tracking and measuring process adoption.

The requirement occurs after launch, and the organization specifically wants to determine whether customer-service representatives are adopting and using the new Salesforce process successfully. This is a measurement problem rather than merely an onboarding problem.

Option B matches that requirement because dashboards and reports allow adoption-related user-engagement information to be reviewed and monitored.

Option A, In-App Guidance, is primarily a mechanism for helping users understand or adopt a process by presenting prompts, walkthrough-style guidance, or contextual assistance. It can contribute to adoption, but it is not the measurement tool selected by the guide for evaluating whether adoption is actually occurring.

Option C, Google Analytics, is generally associated with web analytics and is not the Salesforce adoption-measurement solution keyed in this question.

The UX principle is that launching a process is not the end of design work. Teams should measure whether users are actually adopting the intended workflow and identify whether additional guidance, redesign, or process changes are needed.

Study Guide reference/topics: User Engagement, dashboards, reports, process adoption, Testing.

==================================

The correct answer is B. Bring together a cross-functional group with varied experiences, as explicitly keyed in the uploaded UX Designer study guide.

Consequence Scanning is represented in the guide as an activity strengthened by diverse perspectives. Bringing together people from different functional areas and with different experiences increases the likelihood that the group will identify consequences that a homogeneous team might overlook.

Option A focuses on organizational OKRs. Those objectives may inform product planning, but they are not the consideration selected by the guide for a Consequence Scanning workshop.

Option C places inclusivity examination after the product has already been built. That timing weakens the preventive value of the exercise. The study-guide framing treats consequence-oriented thinking as something that should influence design decisions rather than merely audit them after implementation.

A cross-functional workshop can expose different technical, business, user, operational, and social perspectives. This is particularly important when evaluating possible intended and unintended outcomes.

The main Human-Centered Design lesson is that responsible design analysis improves when teams deliberately include viewpoints beyond the immediate product or design group.

Study Guide reference/topics: Consequence Scanning, cross-functional collaboration, diverse perspectives, responsible design, Human-Centered Design.

==================================

The study guide identifies C. Configure a pre-filtered opportunity list view for each key attribute with the partner group as the correct answer. The requirement is for partners to quickly browse opportunities according to predetermined business criteria. The guide's selected solution is therefore a declarative one: create list views that are already filtered for the relevant opportunity attributes and expose those views to the appropriate partner audience.

This approach directly addresses both conditions stated in the scenario. One view can focus on opportunities closing within two weeks, while another can focus on opportunities valued above $100,000. Partners do not need to repeatedly construct their own filters or understand the underlying filtering logic.

Option A introduces a custom Lightning Web Component even though the requirement can be addressed using standard list-view functionality. That adds unnecessary implementation complexity.

Option B delegates filter creation to each partner, which conflicts with the requirement for a quick, standardized browsing experience.

The design principle reflected by the study guide is to prefer configured, reusable Salesforce functionality when it satisfies the user need. Pre-filtered list views reduce interaction effort and provide consistent segmentation across the partner experience.

Study Guide reference/topics: Experience Builder, opportunity list views, partner experience, filtering, Declarative Design.

==================================

The correct approach is to leverage Salesforce Lightning Design System (SLDS) using UI kits or plugins. The study guide explicitly identifies option C as correct. SLDS exists specifically to accelerate the creation of interfaces that are visually and behaviorally consistent with Salesforce. Rather than designing common interface patterns from scratch, UX Designers can reuse established component patterns, spacing conventions, typography, iconography, accessibility guidance, and design-system resources. Salesforce describes SLDS as a collection of resources for creating interfaces consistent with Salesforce UX principles, design language, and best practices. Official Salesforce Trailhead material also identifies APIs, plugins, and design kits as resources that make building with SLDS faster and easier. This directly addresses the requirement to accelerate the visual design process. Option A would increase fragmentation because separate custom stylesheets can create inconsistent styling and additional maintenance. Option B is not a standard Salesforce design workflow for producing reusable visual assets from layouts. Therefore, using established SLDS designer resources minimizes redundant design work while improving consistency, accessibility, and implementation alignment between UX Designers and developers.

Study Guide reference/topics: SLDS resources, design systems, UI kits, reusable components, visual consistency.

==================================

The uploaded Master Study Guide identifies C. Utility Classes as the correct SLDS resource for maintaining consistency in alignment, grids, spacing, and typography.

Utility classes provide reusable styling mechanisms that can be applied to interface elements without creating a separate custom CSS solution for every layout or presentation requirement. Within the study-guide framing, they are the appropriate SLDS resource when designers and developers need consistent control over common visual properties.

Option A, Component Blueprints, is used to communicate the structure and presentation pattern of complete Salesforce-style components. Blueprints are important when implementing component patterns, but this question focuses specifically on commonly reused styling concerns such as spacing, alignment, and typography.

Option B, BEM Naming Classes, relates to CSS naming methodology and structure. It is not the resource keyed by the guide for applying the visual utilities described.

The underlying design-system principle is reuse instead of reinvention. Applying standardized utility classes helps different pages and components use common spacing and alignment behavior rather than accumulating inconsistent custom CSS rules.

That consistency makes Salesforce interfaces more predictable visually and easier to maintain.

Study Guide reference/topics: SLDS Utility Classes, alignment, spacing, grids, typography, Salesforce Lightning Design System.

==================================

The correct answer is B. Have users sort the cards based on similar categories or groups, as confirmed by the study guide. Card sorting is a UX research method used to understand how users naturally categorize and mentally organize information. Salesforce Trailhead specifically describes card sorting as suitable for grouping things into categories, giving navigation-menu items as an example. For an Experience Cloud site's navigation structure, the designer can represent pages, tasks, topics, or content items as cards and ask representative users to organize them into groups that make sense to them. Depending on the research design, participants may also label those groups. The resulting patterns help inform the site's information architecture, including menu categories, grouping, hierarchy, and terminology.

Option A describes a comparative evaluation of alternative menu designs and is closer to usability comparison or A/B-style testing than card sorting. Option C imposes an arbitrary alphabetical structure instead of investigating users' mental models and expectations.

The core Discovery principle is that information architecture should reflect how users understand the domain rather than how the organization's internal structure happens to be arranged. Card sorting therefore converts user-generated grouping patterns into evidence for designing more intuitive navigation.

Study Guide reference/topics: Discovery research, card sorting, information architecture, navigation, mental models.

==================================

The correct answer is A. Journey Maps, as specified in the uploaded UX Designer study guide.

Journey maps are a core Discovery artifact because they document how users experience a process or service across stages and touchpoints. A journey map can capture user actions, goals, pain points, interactions, and opportunities for improvement.

For an Experience Cloud website redesign, this helps the UX Designer understand how users currently navigate and interact with the service before deciding how the redesigned site should work.

Option B, User Stories, are typically produced when research insights are translated into actionable requirements or backlog items. They are useful after the team has developed sufficient understanding of the user and problem space.

Option C, Interactive Prototypes, belong later in the design process. They represent proposed solutions and are commonly used for evaluation and usability testing. Creating them during early Discovery can cause the team to commit prematurely to an interface before the underlying journey has been sufficiently understood.

The study-guide sequence is therefore important: first understand the user experience, then define and prioritize requirements, then prototype potential solutions.

For Cloud Kicks, preparing Journey Maps gives the redesign effort an evidence-based foundation and highlights the moments where the new Experience Cloud site can improve the overall customer experience.

Study Guide reference/topics: Journey Maps, Experience Cloud discovery, current-state experience, pain points, opportunities, Discovery.

==================================

The uploaded UX Designer study guide identifies C. Determine the change in scope and impact of each enhancement request as the correct answer.

User acceptance testing has produced enhancement requests, but the next step should not be to implement them immediately. The study guide first requires the team to evaluate how each requested change affects the existing solution.

Assessing scope and impact allows the team to understand whether an enhancement is minor or substantial, what parts of the solution it could affect, and how it may change the originally planned work.

Option A moves directly into prioritization. Prioritization can be useful, but the guide's answer indicates that the requests first need to be understood in terms of their impact and scope before deciding how to implement them.

Option B suggests developing all requests in a sandbox. That assumes all requests should proceed to development, which is premature before their implications have been analyzed.

The testing principle represented here is controlled response to feedback. UAT findings may reveal valid improvements, but each change should be assessed systematically before implementation so that the team understands what the enhancement means for the overall solution.

Study Guide reference/topics: User Acceptance Testing, enhancement requests, scope analysis, impact analysis, Testing.

==================================