Pega’s structure uses UI components to build regions of the screen. The reuse of structure provides uniformity across screens, applications, and devices. These components include the header, navigation, and sections that make up the work area.

Application headers

The application header serves as a global action area for an application.

Usage

Functions that do not require on-screen context should reside in the header (e.g., search, help, user actions).

Pega logo

The Pega Platform logo portrays the spirit of Pegasystem's industry-leading software products. It is elegant and clean—representing the platform's ability to simplify and clarify an organization's business practices.

Application name

Application names should be concise and not include industry markers (e.g., not "Underwriting for Insurance," simply "Underwriting").

Search

Pega applications have a universal search bar searches all objects and content in the application.

Notifications

System updates and notifications specific to the logged in user will appear here.

User actions/preferences

User specific actions/preferences should be put in this menu. Sample actions include profile settings, system preferences, switching apps, and logging out of the system.

Assignment area

The user's main work area on any screen should appear inside the assignment area.

This action container typically includes the name of the assignment, due date, and the task owner’s avatar. The background of this container is blue to call attention to the task that the user needs to complete. This color distinction separates the task from other information on the screen, keeping users focused, while allowing them to reference the surrounding data easily.

Actions in assignment area

The main actions on the assignment area are “Submit” and “Cancel”.

“Submit” — the primary action — sits flush right in the container, completes the current assignment, and advances the case to the next step of the case lifecycle.

“Cancel”— the secondary action — sits flush right in the container, cancels the current action, and removes the user from the assignment at hand. If data has been entered and the Cancel action is triggered, the user will be prompted to save current work.

Cards

Cards are a UI element that represents actionable information about an object. A card should be presented as one of many cards.

Content containers

Types

Primary container

Primary containers often hold dashboard widgets, charts, or other information on a page. They use a container style called “Default.” These tiles contain discrete widgets and content. They are most often used to segment information on a dashboard, review harness, or landing page.

A primary container should not be nested inside another primary container. Primary containers appear directly on a page or inside an action container. If a subheader is needed inside a primary container, use an “Alternate,” “Nested,” or a custom container style.

Action container

The user's main work area on any screen should appear inside an action container. This container typically includes the name of the assignment, due date, and the task owner’s avatar.

The background of this container is blue to call attention to the task that the user needs to complete. This color distinction separates the task from other information on the screen, keeping users focused while allowing them to reference the surrounding data easily.

Secondary container

Secondary information can be shown in various ways — either a “nested” container can be put inside a primary or action container, or a secondary container can be used. Secondary containers have a gray background which helps them take less attention from the primary information. The gray, secondary container can also be used inside a primary container to differentiate levels of content.

Behavior

Header actions

Primary and secondary content container headers display actions in the upper right corner. Common actions can be represented by an icon. Other actions should have a clear label. If the actions are common, two can be shown at a time. If the action is not common, one can be shown. When more than two common actions or one uncommon action need to be available, use a menu.

A header with two common actions, refresh, and add.

A header with one uncommon action, “evaluate application”.

A header with a primary common action and a menu.

Buttons

If a process is “moved” by an action, the action should be indicated by a button at the bottom of a card. Actions that move a process “forward” should be on the right side of the card. Actions that move a process “backward” or cancel should be on the left side. The primary action should be farthest to the right and should be the only one in the “strong” button style.

Example of the actions “Submit” and “Cancel”

Example of the actions “Next”, “Back”, and “Cancel”

Example of the actions “Approve”, “Reject”, and “Cancel”. Both “Reject” and “Approve” move the process along, so they are both on the right.

Size

Containers can be any size, but there are some guidelines to be aware of:

• Containers displayed in the secondary information area should be 386px wide.
• Case and action views have an overall maximum width of 1600px.
• Containers displayed in the primary information area have a minimum width of 720px.

Case overview

When a user reviews the content of a case, it is in a “review harness”.

The review harness has the same content as the perform harness. Components that make up a review harness include:

• Case header: includes case type, ID, name, and status of the case.
• Assignment area: lists all work on the current case for the user and others on their team.
• Case summary: a summary of all information collected throughout the case lifecycle.
• Case overview: important, high-level information about the case, as well as auxiliary tools necessary to the case.