Pega CPSSA study materials
Pega CPSSA study resources

Pega CPSSA: User experience design in Pega CPSSA

Pega CPSSA · Work through your exam, one topic at a time.

All guide sections

User experience design in Pega CPSSA

What the domain tests

User experience design tests how Pega screens are assembled and governed: portals and navigation, harnesses, sections, layouts, views, styling, responsiveness, accessibility, and localization. The exam favors designs that separate presentation from business logic and remain maintainable.

Core rules

  • A portal defines the user's navigation and landing experience; a harness composes the case-processing screen; sections and layouts organize fields.
  • Reuse sections and views, and use circumstancing or inheritance for variations instead of cloning screens.
  • Put behavior in flows, data transforms, and validations, not in UI scripts. Use action sets to invoke declared actions and refresh sections only when needed.
  • Use responsive layouts and test at defined breakpoints; design for keyboard navigation, visible labels, sufficient contrast, and screen-reader semantics.
  • Store user-facing text in field value/localization resources rather than hard-coding labels.
  • Visibility conditions improve usability but are not security controls; enforce access with privileges and access policies.

Worked example

A claim review screen must work on a desktop and a phone. Build one section with a responsive layout: two columns at the large breakpoint and one column below it. The Approve button uses an action set to invoke the approval flow action and is visible only when the case status is PendingApproval and the user has the ApproveClaim privilege. The button label comes from a localized field value. Reasoning: the layout adapts without a duplicate mobile harness; the action is declared, not scripted; the privilege enforces authorization while the visibility condition only reduces confusion.

Traps

Duplicating a harness for each device creates drift. Hiding a field with a display condition does not prevent a crafted request from reading or changing it. Hard-coded labels block localization. Overloaded action sets that refresh the whole harness hurt performance and can discard user input. Accessibility is a design requirement, not a post-launch fix.