UX Designer Interview Questions

The five phases are: (1) Empathize — understand users through interviews, observation, and contextual inquiry. On a Salesforce project this means sitting with Sales Reps or Service Agents to understand daily pain points before touching configuration. (2) Define — synthesise research into a clear problem statement or "How Might We" question, e.g. "How might we reduce the time a Service Agent spends navigating between five tabs?" (3) Ideate — generate many potential solutions through brainstorming, crazy-eights, or affinity mapping. (4) Prototype — build low-to-high fidelity representations (sketches, Figma wireframes, or a sandbox org build) to test solutions cheaply. (5) Test — validate prototypes with real users, capture qualitative and quantitative feedback, and iterate. The process is inherently iterative — test findings loop back into Empathize or Define as needed.

Contextual inquiry is an observational research method where the researcher watches a user perform their actual work in their real environment, asking clarifying questions as they go. It is based on the master-apprentice model — the researcher is the apprentice learning from the expert user. Use it over a standard interview when: (1) Users struggle to articulate what they actually do (the "say vs do" gap). (2) You suspect the stated workflow differs from the real one. (3) You need to discover workarounds, shadow tools, and undocumented processes. (4) The task is procedural and context-dependent (e.g., how a Service Agent resolves a Case while also using Outlook and a spreadsheet). Standard interviews are faster and suitable when you need to understand attitudes, priorities, or historical context rather than observing live behaviour.

Moderated usability testing: A facilitator is present (in-person or remote via video call) while the participant completes tasks. The facilitator can probe for reasoning, redirect if the participant is stuck, and clarify ambiguous tasks. Best for complex workflows, early-stage prototypes, and when rich qualitative insight is needed. Unmoderated usability testing: Participants complete tasks independently using a platform (e.g., UserTesting, Maze). No facilitator is present. Results are captured via screen recording, task completion rates, and post-task surveys. Best for validating specific interactions at scale, benchmarking, or when budget/time does not allow moderated sessions. In Salesforce UX work, moderated testing suits complex multi-step Flows or page layouts, while unmoderated suits quick validation of single-component changes like a new quick action or compact layout.

(1) Open card sort: Participants group cards and name the groups themselves. Used in the discovery phase to understand users' mental models of how content should be organised. Ideal for designing new navigation or information architecture from scratch. (2) Closed card sort: Groups are pre-defined; participants place cards into existing categories. Used to validate a proposed structure or test whether items belong in expected categories. Useful when redesigning an existing navigation without changing the top-level structure. (3) Hybrid card sort: Participants can place cards into existing categories or create new ones. Balances discovery and validation — surfaces unexpected groupings while also testing the proposed structure. In Salesforce, card sorting informs App navigation, the order of page sections, and how to label Related Lists or Lightning App pages.

Card sorting is a generative method — it helps you build or refine an information architecture by learning how users mentally categorise content. Tree testing (also called reverse card sorting) is an evaluative method — it tests whether users can find items within an already-defined navigation hierarchy. Participants are given a text-only tree (no visual design) and asked to complete "find" tasks by navigating through it. Key metrics: success rate, directness (how many went straight to the answer without backtracking), and time-on-task. In Salesforce, tree testing validates whether users can locate a custom app, find a specific tab, or navigate a multi-level menu before investing in a full build. It isolates navigation problems from visual design problems, making it a clean test of information architecture alone.

A research-based persona is constructed from real qualitative and quantitative data — interviews, surveys, analytics, and contextual observation. It accurately represents distinct user segments and their goals, pain points, behaviours, and contexts. It takes time and budget but produces reliable design targets. A proto-persona (or assumption persona) is created from stakeholder assumptions and existing business knowledge without primary user research. It is fast and cheap but carries the risk of designing for a fictional user. Proto-personas are useful early in a project to align a team and establish shared language before real research is available, or in constrained timelines. The best practice is to start with proto-personas, then validate and evolve them through research. Both should focus on goals and behaviours, not demographics alone.

A traditional user story follows the format: "As a [role], I want to [action] so that [benefit]." It is role-centric and focuses on features. A JTBD job story follows: "When [situation], I want to [motivation/goal], so I can [expected outcome]." It is context- and motivation-centric, removing persona assumptions and focusing on the circumstance that drives behaviour. Example — User story: "As a Sales Rep, I want to see my pipeline on the home page so I can plan my day." Job story: "When I start my work day, I want to immediately see which deals need attention, so I can prioritise my calls before my morning meeting." Job stories are more durable than user stories because they focus on the underlying need rather than a prescribed solution, avoiding the risk of building the wrong feature correctly.

Findability is the ability of a user to locate something they already know exists — they are searching with intent. Optimising findability means improving search, navigation labels, and taxonomy. Discoverability is the ability of a user to stumble upon something useful they did not know existed — serendipitous learning. Optimising discoverability means surfacing related content, contextual recommendations, and progressive onboarding. In Salesforce, findability maps to: search bar results, App Launcher, list view filters, and report folders. Discoverability maps to: Einstein Next Best Action recommendations on record pages, in-app guidance walkthroughs, the "Related" tab showing related records, and featured items in AppExchange. Designers must balance both — too much discoverability creates noise, too little leaves features unused.

Design tokens are named, platform-agnostic variables that store visual design decisions — colours, font sizes, spacing, border radii, and shadow values. In SLDS, tokens follow the naming convention --slds-c-[component]-[property]-[variant] or the global --sds-g-[property] format. Examples: --slds-g-color-brand-base-50 (brand blue), --slds-g-font-size-3 (body font size). They are important because: (1) They enforce visual consistency across all Salesforce components. (2) They enable theming — changing one token updates every component using it. (3) They decouple design decisions from implementation, allowing designers and developers to communicate in shared language. (4) Custom components using tokens automatically inherit theme changes made in the Lightning Theme Builder, ensuring brand alignment across custom and standard elements.

The SLDS grid is a 12-column flexbox-based layout system. The container uses slds-grid, and columns use slds-col with size modifiers like slds-size_1-of-2 (half width) or slds-size_4-of-12. Responsive breakpoints use prefixes: slds-medium-size_ and slds-large-size_. Utility classes are single-purpose CSS classes for spacing, typography, and layout without writing custom CSS. Examples: slds-p-around_medium (padding), slds-m-bottom_small (margin), slds-text-heading_large, slds-truncate (ellipsis overflow). Blueprint components are SLDS-provided HTML/CSS patterns for standard UI elements (cards, badges, pills, data tables, modals) that establish the correct structure before adding JavaScript behaviour. Using utilities and blueprints ensures designs remain consistent with native Salesforce UI.

(1) Paper prototype: Hand-drawn sketches of screens. Takes minutes to produce. Best for initial ideation, team alignment, and testing gross navigation concepts. No investment wasted if the idea is wrong. (2) Wireframe: Greyscale digital layouts showing structure and content hierarchy without colour or imagery. Built in Figma, Balsamiq, or similar. Tests information architecture and layout decisions. (3) High-fidelity prototype: Full visual design with SLDS-accurate components, colours, and interactive hotspots. Used for stakeholder sign-off, usability testing, and developer handoff. (4) Coded prototype: A live sandbox org or LWC component with real data. Highest fidelity — tests actual performance, real API calls, and genuine interaction behaviour. Used for final user acceptance testing or performance benchmarking. Choose fidelity based on what you need to learn — lower fidelity earlier to fail fast, higher fidelity as confidence grows.

Nielsen's 10 heuristics: (1) Visibility of system status. (2) Match between system and real world. (3) User control and freedom. (4) Consistency and standards. (5) Error prevention. (6) Recognition rather than recall. (7) Flexibility and efficiency of use. (8) Aesthetic and minimalist design. (9) Help users recognise, diagnose, and recover from errors. (10) Help and documentation. Example — Heuristic 1 (Visibility of system status): Salesforce's Flow progress indicator shows users which step they are on and how many remain — keeping users informed and reducing anxiety during long data-entry wizards. Example — Heuristic 5 (Error prevention): Validation rules in Salesforce prevent incorrect data from being saved with an error message before submission — catching errors at the point of entry rather than later. Designers apply heuristics during expert reviews (heuristic evaluations) as a fast, cost-effective way to identify usability problems without recruiting participants.

WCAG 2.1 defines two levels of contrast compliance: (1) AA (minimum): Normal text (below 18pt/14pt bold) requires a contrast ratio of at least 4.5:1 against its background. Large text (18pt+ or 14pt+ bold) requires 3:1. UI components and graphical objects (icons, chart lines, input borders) also require 3:1. (2) AAA (enhanced): Normal text requires 7:1; large text requires 4.5:1. In Salesforce design: check contrast using tools like the Stark Figma plugin, WebAIM Contrast Checker, or browser DevTools accessibility panel. SLDS tokens are pre-checked for AA compliance on white backgrounds, but custom themes created in Lightning Theme Builder must be manually audited — especially brand colours used on coloured hero banners. Dark mode combinations require separate testing. Always test with real content, not placeholder text, as short labels on coloured badges are common failure points.

ARIA roles (Accessible Rich Internet Applications) supplement HTML semantics for complex widgets: role="dialog" identifies a modal, role="alert" announces dynamic status messages to screen readers, aria-expanded communicates accordion state. SLDS components include correct ARIA attributes out of the box — custom LWC components must add them explicitly. Keyboard navigation: All interactive elements must be reachable and operable via keyboard alone (Tab, Shift+Tab, Enter, Space, arrow keys). Salesforce Lightning enforces logical tab order following DOM order. Custom components must not break this with improper tabindex usage. Focus management: When a modal opens, focus must move to the first interactive element inside it and be trapped there (cannot Tab outside). When the modal closes, focus must return to the trigger element. Screen readers (NVDA, JAWS, VoiceOver) rely on this to maintain user orientation. Testing with keyboard-only navigation is the most common gap in Salesforce custom component audits.

Dynamic Forms allow individual fields and field sections on a Lightning Record Page to be placed anywhere on the page (not constrained to a single "Details" component) and controlled by visibility rules (component visibility filters). A field can be conditionally shown based on record field values, user profile, or device type — for example, showing a "Reason for Discount" field only when the Discount field is greater than 10%. This reduces page clutter and surfaces contextually relevant information. Dynamic Actions similarly apply visibility conditions to buttons in the action bar — a "Qualify" button is only shown when Stage = "Prospecting". Together, they replace the need for multiple record types and page layouts for minor variations. Component visibility rules (available on all Lightning components, not just Dynamic Forms) use AND/OR logic across field values, permissions, and device conditions, enabling a single page layout to adapt to many contexts — reducing admin maintenance overhead significantly.

Screen Flows are the primary tool for guided UX in Salesforce. Key design considerations: (1) Navigation: Use Back and Next buttons thoughtfully — avoid forcing users to restart if they navigate back. Store user inputs in flow variables so data is preserved. (2) Progress indicator: Enable the flow progress indicator (available in auto-layout and free-form) to show users where they are in a multi-step process — addresses Nielsen's Heuristic 1. (3) Auto-layout: Preferred for maintainability and clarity; elements are arranged in a single connector path making logic easier to follow. (4) Conditional sections: Use visibility rules on screen components to show or hide fields without creating separate screens, reducing cognitive load. (5) Accessibility: Flow screen components inherit SLDS accessibility. Custom LWC components embedded in flows must include proper ARIA attributes. (6) Error handling: Use Fault connectors and custom error messages to explain failures in user-friendly language. Avoid generic "An error occurred" messages.

Key mobile UX considerations: (1) Navigation bar: The Salesforce mobile app navigation bar supports a maximum of 5 items (including Smart Search Items). Choose the most frequently used objects — excess items are hidden behind "More". (2) Compact Layouts: Define up to 10 fields shown in the record highlight panel (top of a record page on mobile). Prioritise the 3–4 most critical fields since only the first few display prominently. (3) Page layout simplicity: Mobile screens are narrow — avoid horizontal multi-column layouts and long related lists. Use collapsible sections. (4) Quick Actions: Action bar quick actions are the primary interaction model on mobile. Ensure actions have clear labels and are ordered by frequency of use. (5) Offline: For field service use cases, consider which data must be available offline and configure the Mobile Offline feature accordingly. (6) Touch targets: Minimum 44x44px touch target size per WCAG and Apple HIG guidelines. Avoid hover-dependent interactions.

Salesforce In-App Guidance delivers contextual help and onboarding directly within the UI without code. The three types are: (1) Floating Prompt: A dismissible popover anchored to a specific element on a page (e.g., pointing to a new button). Ideal for announcing new features or explaining a specific UI element. (2) Docked Prompt: A panel docked to the bottom corner of the screen, not anchored to a specific element. Suitable for general contextual tips or surveys that should not obstruct the page. (3) Walkthrough: A multi-step guided tour that sequences multiple floating or docked prompts across one or multiple pages — ideal for onboarding new users to a process. Targeting is configured by: Profile (show only to specific profiles), Permission Set (show to users with a specific permission), App (show in a specific Lightning App), Page URL (show on a specific record or app page), and scheduling (start/end date and time). Prompts can be set to display once, daily, weekly, or always.

Key principles: (1) Chart selection: Match chart type to data relationship. Bar/column charts compare categories. Line charts show trends over time. Pie/donut charts show part-to-whole (use sparingly, max 5 segments). Funnel charts show stage conversion. Scatter charts show correlation. Never use 3D charts — they distort perception. (2) F-pattern layout: Users scan dashboards in an F-pattern — most important KPIs (revenue, open pipeline, SLA compliance) belong in the top-left. Place summary metrics first, details below. (3) Colour accessibility: Never rely on colour alone to convey meaning — add labels or patterns. Use SLDS chart colour palette which is pre-tested for colour-blindness. Avoid red/green combinations without secondary indicators. (4) Minimise chartjunk: Remove unnecessary gridlines, 3D effects, and decorative elements (Tufte's data-ink ratio principle). (5) Consistent scale: Axes should start at zero for bar charts; truncated axes mislead users about magnitude differences.

Label placement: Top-aligned labels (above the input field) are the SLDS default and best practice. They reduce eye movement, work well on mobile, and are faster to complete than right-aligned or left-aligned labels (Nielsen Norman Group research shows top-aligned labels reduce completion time). Avoid placeholder text as the only label — it disappears on focus and fails accessibility requirements. Inline validation: Validate on blur (when the user leaves the field), not on every keystroke — real-time validation creates anxiety. Show success states for important fields (green checkmark) to build confidence. Display error messages directly below the field with a clear icon and specific guidance: "Enter a valid email address (e.g., name@company.com)" not just "Invalid input". Error messaging: Be specific, blame the system not the user, and always provide a path to resolution. Required field indicators (*) must be explained at the top of the form. Group related fields visually. Keep forms as short as possible — ask for data only when truly needed.

Progressive disclosure is the UX principle of revealing information or controls only when they become relevant, reducing cognitive load on the user. It avoids overwhelming users with all possible options upfront. Applications in Salesforce: (1) Dynamic Forms: Show the "Escalation Reason" field only when Priority = "High" — the field is hidden until it is needed. (2) Collapsible sections on page layouts: Secondary information (e.g., system fields, audit dates) is collapsed by default and expanded on demand. (3) Screen Flows: Multi-step wizards break a complex process into digestible steps rather than presenting one long form. (4) Expandable Related Lists: Show 5 records by default with a "View All" link — users who need more can access it without it cluttering the primary view. (5) Utility Bar: Keeps secondary tools (CTI softphone, notes, recent items) in a collapsed bar at the bottom of the app, accessible when needed but not consuming screen real estate.

A mental model is a user's internal representation of how a system works, built from prior experience, analogy, and inference. Users approach new software with expectations shaped by tools they already use. When an interface violates a mental model, users make errors and feel confused. In Salesforce design: (1) Match real-world language: Use terminology your users already know — "Account" and "Contact" may map to "Company" and "Person" in users' vocabulary. Rename objects or use field labels that match the business's language. (2) Familiar layouts: If users come from a legacy system where details are on the left and related lists on the right, preserving this structure reduces retraining. (3) Consistent patterns: Using Salesforce standard components (SLDS) leverages the mental models users build across the platform — custom UIs that deviate cause learning overhead. (4) Research-informed design: Card sorting and user interviews surface actual mental models, enabling designers to align navigation structure with how users think rather than how the system is technically organised.

Internationalisation in Salesforce UX involves: (1) Translation Workbench: Field labels, picklist values, custom object names, validation rule messages, and help text can all be translated. Enable the Translation Workbench in Setup and add supported languages. (2) Text expansion: Translated text can be 30–50% longer than English — design layouts with flexible containers, avoid fixed-width buttons, and test all components with German or Finnish translations (some of the longest expansions). (3) Date, time, and number formats: Salesforce automatically formats these based on the user's locale setting — never hardcode format assumptions in custom components. (4) RTL languages: Arabic and Hebrew require right-to-left layout mirroring. SLDS has RTL support but custom components must be tested. (5) Icon meaning: Some icons carry cultural meaning that does not translate — thumbs up, postal icons, and colour associations vary by region. (6) Currency: Use Salesforce's multi-currency or advanced currency management for orgs operating across regions.

Dark mode in Salesforce is delivered through the Lightning Theme Builder and SLDS dark theme tokens. For custom components: (1) Use SLDS tokens, not hex values: Tokens like --slds-g-color-neutral-base-10 automatically switch between light and dark values when the theme changes. Hardcoded hex colours do not adapt. (2) Contrast re-testing: A colour pair that meets 4.5:1 in light mode may fail in dark mode — e.g., a mid-grey text on a dark background. Test all contrast ratios under both themes separately. (3) Avoid pure white on pure black: High-contrast extremes (#fff on #000) can cause halation for users with certain visual conditions. SLDS dark theme uses near-black and near-white by design. (4) Shadows and borders: Dark mode often requires replacing drop shadows (which disappear on dark backgrounds) with subtle border outlines for component delineation. (5) Images and icons: SVG icons using fill: currentColor adapt automatically. Raster images with white backgrounds appear as white boxes in dark mode — use transparent PNG backgrounds or CSS mask techniques.

A/B testing (split testing) is a quantitative experiment where two variants of a UI element are shown to different randomly assigned user groups simultaneously to measure which performs better against a defined metric. It requires a sufficient sample size to achieve statistical significance. Applying it in Salesforce: (1) What to test: Action bar button labels ("Log Call" vs "Record Activity"), compact layout field order, home page component arrangement, or different Flow screen designs. (2) Mechanism: Salesforce does not have a native A/B testing tool. Approaches include: using permission sets to show different page layouts/components to different user groups and tracking behaviour via reports, or using CRM Analytics to segment engagement metrics. (3) Metrics: Define a primary metric before running the test (e.g., task completion rate, time to complete a flow, click-through on a Quick Action). (4) Duration: Run tests long enough to account for weekly patterns and achieve statistical significance — typically at minimum 1–2 business cycles. Avoid changing multiple variables simultaneously.