Explanation

In Agile ceremonies like sprint planning, teams often need a quick, collaborative way to estimate the relative effort, complexity, or size of user stories or backlog items without diving into precise hours. This helps with capacity planning and prioritization. T-shirt sizing is a popular relative estimation technique used in Agile (including Salesforce teams) for this exact purpose during early planning discussions.

Correct Option

✅ C. T-shirt Sizing
T-shirt sizing is the ideal methodology here. It uses simple categories like XS, S, M, L, XL (similar to clothing sizes) to roughly estimate the work required for each item. It's fast, promotes team discussion, avoids over-precise numbers early on, and is commonly used in sprint planning to gauge relative effort before more detailed estimation (like story points). This fits perfectly for a UX Designer contributing to Agile ceremonies on the Salesforce Platform.

Incorrect Options

❌ A. Sprint Backlogging
This isn't a real estimation methodology. Sprint backlogging refers more to the process of adding or refining items in the backlog, not a technique for estimating work. It confuses backlog grooming/refinement activities with actual sizing or estimation methods used in planning sessions.

❌ B. Prioritization Matrix
A prioritization matrix (like a 2x2 effort vs. impact grid) helps rank items by business value or urgency, but it's not designed for estimating the rough effort or work required for implementation. It's focused on "what to do first" rather than "how big is the work," so it doesn't fit the question's focus on estimating effort during sprint planning.

Summary
A UX Designer in sprint planning is most likely asked to use T-shirt sizing for rough estimation of work items. This relative, quick method supports Agile collaboration without needing exact time commitments early. It aligns well with Salesforce's emphasis on efficient, user-centered design within Agile processes. Always lean toward simple, team-friendly techniques in early planning stages.

Reference
Salesforce Trailhead - Cert Prep: Salesforce Platform User Experience Designer module (covers Agile collaboration and design estimation practices in the context of the Salesforce Platform). For deeper Agile concepts relevant to UX, refer to official Salesforce UX Designer certification resources on Trailhead.

Explanation

Too many action buttons overwhelm users, especially when 80% don't apply to current record status. Dynamic Actions let UX Designers create filter rules (Status = "New" → show "Convert"; Status = "Closed" → hide "Edit"). Buttons appear/disappear automatically in the Highlights panel—no page reloads needed. Clean, contextual toolbar that adapts instantly to workflow stage.

Correct Option

✅ C. Dynamic Actions
In Lightning App Builder, select Highlights Panel → "Upgrade to Dynamic Actions" → Add Actions → Set Filters (Status equals "Draft" → show "Submit"; "Approved" → show "Send"). Users see only relevant buttons matching current record state. Perfect for custom objects with stage-based processes.

​ Incorrect Options

❌ A. Audiences
Audiences filter entire page layouts by user profile/permission set, not individual action buttons by record status. All users with access see same bloated button bar regardless of record state—doesn't solve per-status decluttering.

❌ B. Dynamic Forms
Dynamic Forms control field/section visibility on record detail pages, not action buttons in Highlights panel. Great for hiding fields by status, but toolbar buttons remain cluttered without Dynamic Actions.

Summary
Dynamic Actions = status-based button visibility in Highlights panel Single feature solves "too many action buttons" perfectly Filters tie directly to record fields like Status/Stage

Reference:
Salesforce Help - Create Dynamic Actions in Lightning App Builder

Explanation

When designing a solution that impacts both internal staff (using a Service Console) and external customers (using a Community), it is essential to first understand the human beings behind the screens. Before building layouts or mapping paths, a designer must synthesize research into a format that captures the diverse motivations and frustrations of each user group to ensure the new service meets their specific needs.

✅ Correct Option

C. User Personas:
A Persona is the primary tool used to document user goals, common tasks, and pain points. By creating archetypes for the internal service agent and the external customer, the designer can keep the project team focused on real user needs throughout the design process. This document serves as a reference point for making design decisions that directly address the specific challenges identified during the research phase.

❌ Incorrect Options

A. Storyboards:
Storyboards are visual narratives that show a user's interaction with a product over time, usually in a comic-strip format. While they are great for illustrating a specific scenario or the "flow" of an experience, they are not the primary document used to categorize and store detailed user goals, motivations, or a comprehensive list of pain points.

B. Wireframes:
Wireframes are low-fidelity blueprints of a user interface. They focus on the placement of buttons, text, and components. While they are a critical part of the design process, they represent the solution (the interface) rather than the documentation of the user's research data (goals and frustrations).

D. User Journeys:
A User Journey (or Journey Map) visualizes the specific steps a user takes to complete a goal. While it does include pain points and tasks, it is organized chronologically along a timeline. It relies on the User Persona as its foundation; you must first define who the user is (Persona) before you can map out their specific path (Journey).

📌 Summary
User Personas provide the "human" context necessary to design a balanced service experience. By documenting the goals and pain points of both internal agents and external customers, Cloud Kicks ensures that the Service Console and Customer Community are built to solve real-world problems. This leads to higher satisfaction and more efficient service delivery.

Reference:
Salesforce Help - User Personas

Explanation

When building a custom Lightning Web Component (LWC) with SLDS, designers need accessible, ready-to-use HTML markup, CSS classes, ARIA attributes, and clear guidelines to ensure consistency and accessibility. The SLDS website organizes this information in a specific section so teams can quickly copy structures and follow best practices without starting from scratch.

Correct Option

✅ A. Component Blueprints
Component Blueprints provide accessible HTML + CSS code snippets, ARIA roles, keyboard navigation rules, and detailed implementation guidelines for each SLDS component. Designers copy the markup directly into LWC templates, apply SLDS classes, and follow the rules to build custom, on-brand, accessible components that match Lightning Experience.

Incorrect Option

❌ B. Design Tokens
Design Tokens define variables (colors, spacing, typography) for consistent styling via CSS custom properties. They help with theming but don’t include full HTML structures, component examples, or implementation instructions needed to build complete accessible components.

❌ C. Development Tools
There’s no main “Development Tools” section on SLDS focused on HTML/CSS and guidelines. While SLDS links to validators and related docs, the actual blueprints and code live in Component Blueprints—not a separate tools area.

Summary
Go to Component Blueprints on the SLDS website for accessible HTML, CSS, ARIA, and implementation guidelines when creating custom LWCs. It’s the direct source for building consistent, accessible components. Tokens handle styling variables; Development Tools isn’t the right section.

Reference
LWC Developer Guide: Create a Component from an SLDS Blueprint
Trailhead: Get Started with the Salesforce Lightning Design System (SLDS)

Explanation

When implementing a company’s brand consistently across Salesforce, teams need a single, authoritative reference. This source of truth ensures visual consistency, interaction standards, and correct usage of components. While multiple documents support design work, only one should govern how the brand is applied across all Salesforce experiences.

✅ A. Style Guide
A style guide defines brand-specific rules such as colors, typography, spacing, tone, and logo usage. It acts as the primary source of truth when implementing a company’s brand in Salesforce, ensuring consistency across pages, components, and user experiences while still allowing Salesforce standards to be followed.

❌ B. Design Principles
Design principles describe high-level values and intentions behind design decisions. They guide thinking but do not provide concrete rules for visual or brand implementation, making them unsuitable as a source of truth for consistency.

❌ C. Pattern Library
A pattern library documents reusable UI patterns and components but often references an underlying style guide. It supports consistency but does not define the brand itself.

❌ D. Salesforce Lightning Design System
SLDS provides Salesforce’s base design framework, not a company’s unique brand identity. It must be adapted to match an organization’s style guide rather than replace it.

Summary
A style guide is the authoritative source for applying a company’s brand in Salesforce. Design principles and pattern libraries support design work but lack brand rules. SLDS provides the foundation, not the company-specific branding.

Reference
Salesforce Trailhead — Branding with the Lightning Design System