Record Experiences

Design what each person needs to see and do throughout an Elementum process.

Limited Release. The EDK is currently in limited release and is not available to all customers. Commands, generated file layouts, and package APIs may change before general availability. Confirm you’re on the latest EDK version before starting new projects.

Record-experience design defines what people need from Elementum at each stage of a process. It connects the process map to the information, decisions, and actions that should shape the eventual solution.

This is a design activity for process owners and subject-matter experts. You do not need to write TypeScript or configure Elementum. Use the /elementum-design playbook to lead the workshop and capture the result.

Complete Design with EDK first so the business outcome, personas, stages, and handoffs are clear.

Define Each Stage

For every materially different stage, describe:

• Persona: Who owns the work now, and who else needs visibility?
• Primary job: What single outcome must that person produce?
• Decision: What must the person understand, approve, reject, or resolve?
• Required inputs: What do they need to see, enter, or update?
• Evidence: What documents, relationships, history, or prior decisions support the work?
• Primary action: What should they do next, and what is the consequence?
• Failure path: What blocks, returns, escalates, or cancels the work?

Create a distinct experience only when the person’s job changes. A new status alone does not require a different experience if the same person is making the same decision with the same information.

Shape the Record Experience

Describe the experience in layers:

1. Orientation: Identity, ownership, stage, urgency, and the few facts needed to understand the record.
2. Work area: Information the current person must review or change.
3. Decision and action: The primary outcome, action label, confirmation, and possible failure.
4. Evidence: Attachments, relationships, findings, approvals, and source material.
5. History: Activity and audit detail that should remain available without dominating the work.

The first view should answer three questions: What is this record? What matters now? What should I do next?

Do not design around every available field. Include information because it supports the current job, decision, evidence, or handoff.

Do not repeat information or actions already supplied by the record header. Prefer one clearly labeled primary action for each stage, and never communicate state through color alone.

Design How People Find Work

Record pages support one item at a time. Also define how each person finds and prioritizes multiple records.

For each useful list or queue, identify:

• The person and repeatable task it supports.
• The records that belong in the view.
• The fields needed to recognize and prioritize work.
• The default order and useful filters.
• The empty state and next action.

A focused view usually needs an identifier, stage or status, owner, urgency or risk, and one or two process-specific facts. It should support scanning rather than reproduce the entire record.

Account for Different States

Describe how the experience should behave when:

• Information is missing, sparse, unusually long, or high risk.
• A person can view but not edit particular information.
• An action is unavailable, requires confirmation, succeeds, or fails.
• Work is reassigned, returned, rejected, cancelled, escalated, or completed.
• Related records or evidence are empty, loading, or extensive.

These scenarios become design requirements and later acceptance tests.

Work with a Coding Agent

Give the agent the process material and a clear design-only request:

Use elementum-design to design the record experiences for [process].
Do not write code or configure Elementum.

For each persona and stage, define the outcome, decision, required
information, evidence, primary action, exceptions, and list-view needs.
Identify open questions and assumptions, then produce a design brief
for the delivery team.

Review the agent’s recommendations with the people who perform and own the process. The agent should expose missing decisions and conflicting requirements rather than fill them in without evidence.

Create the Design Brief

The final brief should include:

• The business outcome and process boundaries.
• Personas, responsibilities, and handoffs.
• A stage matrix with primary jobs, decisions, actions, and exceptions.
• The record experience and information hierarchy for each distinct stage.
• List or queue requirements for each persona.
• Required information, evidence, relationships, and history.
• Access, governance, reporting, and Automation considerations.
• Assumptions, open questions, and platform capabilities that need confirmation.
• Representative scenarios for design validation.

Describe the intended behavior without prescribing implementation details. The delivery team should decide how to realize the approved design and confirm what the platform supports.

Continue with Design Validation to review the brief before implementation.