Overview
Object-detail floorplans balance comprehensive context and focused actions.
The objective is quick understanding before edits, approvals, and related object navigation.
Understand and move a single record
Explore stable record sections, edit governed attributes, inspect relationships, and compare the authorized and read-only action rails.
Payment reconciliation delay
Production · Payments platform
Incident attributes
- Owner
- Maya Chen
- Priority
- High
- Detected by
- Reconciliation monitor
- Next checkpoint
- 10:15 IST
Anatomy
Use each piece in this order to keep interpretation and automation consistent.
- 1Header
Object identity, status, and highest priority actions.
- 2Overview columns
Key metrics and attributes in one glance.
- 3Activity timeline
Recent events and communication history.
- 4Relationship panel
Associated entities and quick links.
- 5Action rail
Primary object commands by role and state.
The ordering here is not visual-only; it reflects interaction priority and expected user cognition. Keep this order unless policy demands a specific domain exception.
When to use
Use this pattern when the user needs guided consistency, state, and reuse at scale.
Recommended
- Customer records
Use for records requiring rich context and action.
- Incident workflows
Use for troubleshooting and progression tracking.
- Approval artifacts
Use where details + review actions are co-located.
When not to use
Avoid forcing this pattern where simpler, direct interactions are sufficient.
Avoid
- Overview-only modules
Use dashboard floorplan when no object-specific actions exist.
- High-cardinality lists
Use list-report for batch operations.
- Simple forms
Use form screens for one-step edits.
Variants
A small number of variants helps teams choose correctly without adding complexity.
Split view
Primary content plus side details.
Tabbed detail
Sections for overview, history, settings.
Editable detail
Inline edits with explicit save checkpoints.
States
States communicate readiness, risk, and expected user behavior.
| State | Trigger | Visual response | Interaction |
|---|---|---|---|
| Loading | Fetching details | Skeleton header and summary | Keep action controls disabled. |
| Loaded | Data ready | Complete object sections available | Enable contextual controls. |
| Read-only | Permission restrictions | Disabled edit affordances | Show request-access path. |
Behavior
Behavior should remain predictable across devices, permissions, and async edges.
Predictable layout
Keep section order stable across object types.
State-aware actions
Action availability driven by object status and user role.
Context links
Cross-link related entities for workflow continuity.
Accessibility
Keep interaction clarity high and ensure assistive technologies get the same meaning.
| Key | Action |
|---|---|
| Tab | Navigate sections in logical object order. |
| E | Open primary edit path when authorized. |
| Ctrl/CmdS | Save local edits. |
- Use landmark regions for header, main content, and related sections.
- Keep required fields marked in label and helper text.
- Announce transition from read-only to editable state.
Content guidelines
Consistency is achieved by language standards, not by design only.
Object title
Keep object titles unique and actionable.
Invoice INV-1122 — Payment pending
Section naming
Use short and stable section titles.
Timeline
Action wording
Use verbs matching user intent.
Approve invoice
Examples
Reference implementation style, payloads, and practical behavior.
Production use
- Show status chips and owner in header to reduce hunt time.
- Keep history section visible but compact on first paint.
- Avoid placing destructive actions next to neutral controls.
Props / API
Use these API entries as a baseline contract and validate them against your domain layer.
These names are implementation-oriented and should map to your local contracts.
Props