---
title: Object Identity Header
slug: object-identity-header
kind: pattern
summary: A record page opens by saying what this record is, what state it is in, and the two or three facts that decide what you do next — before any detail.
problem: >-
  A record page starts with a field list, so the first thing a person reads is
  "Created at". They have to assemble the record's identity from fragments, and
  on a page of forty fields they may never find the one fact that decides the
  next action.
family: [orient, inspect]
data_shape: [record]
principles: [orientation, progressive-disclosure, surface-dont-bury]
interaction: [scanning]
density: low
complexity: low
status: stable
visibility: public
use_when:
  - The screen is about exactly one record.
  - There is a state, an owner or a number that changes what someone does next.
  - People arrive here from a list, a link or a search and need to confirm they have the right one.
avoid_when:
  - The screen is a collection. Then the identity is the filter, and it belongs in the page title.
  - The record has exactly two fields, in which case the header would be the whole page twice.
alternatives:
  - slug: lifecycle-status
    when: The state itself is the hard part and needs its own vocabulary.
  - slug: master-detail-drawer
    when: The record is being inspected from a list; the drawer's top is this header.
ask_leo: |
  Give this record page an identity header before any detail.

  - Line one: the name a person would say out loud. Not the id, not the class
    name. If an id is needed for support, show it small and secondary.
  - Line two: at most three facts that change what someone does next — usually
    the lifecycle state, the owner, and the one number or date that creates
    urgency.
  - Show the state as a word. If you add colour, the word must still carry the
    meaning without it.
  - Put the primary action for this record in the header, on the right. One
    primary; everything else is secondary or in an overflow menu.
  - Everything else on the record goes below, in sections or tabs. The header is
    not a place to add a fourth fact later.
  - Use the same header component everywhere this kind of record appears.
related:
  - title: Progressive Disclosure for Dense Detail Pages
    url: /cookbook/progressive-disclosure-detail-page
    summary: The implementation guide for what goes below this header, and at which layer.
  - title: Progressive disclosure
    url: /patterns/progressive-disclosure
    summary: The glance layer and its five-element budget.
---

## Anatomy

```
┌────────────────────────────────────────────────────────────┐
│ INVOICE #1043                              [ Send invoice ]│
│ Riverside Fit-Out Ltd                          ⋯ more      │
│                                                            │
│ Overdue 12 days   ·   Owner Dana   ·   $8,400              │
└────────────────────────────────────────────────────────────┘
  ↑ state first — it is what changes the next action
```

Four parts:

1. **The name**, as a person would say it.
2. **A type or number**, small, for the case where someone is checking they have
   the right record.
3. **Two or three deciding facts.** State, owner, the number or date that
   creates urgency. Not "created at". Not everything that fits.
4. **One primary action.**

## Why it works

It makes the record's *identity* and its *disposition* free to read, so the rest
of the page is optional. That is the glance layer doing its job: the person who
only needed to know "is this paid?" is finished in one second and never scrolls.

The three-fact cap is what makes it work over time. Every record accretes fields,
and without a fixed budget the header absorbs them one at a time until it is a
summary of everything, which is a summary of nothing. To add a fourth fact,
remove one.

## Getting it wrong

- **Opening with metadata.** Created at, updated at, and internal ids are the
  least useful facts about a record and they are frequently first.
- **State as a colour only.** A coloured dot with no word fails in greyscale and
  for anyone who does not read that hue, and it is exactly the fact people came
  for.
- **Two primary actions.** If both are emphasised, neither is, and people click
  the wrong one.
- **A different header per screen** for the same object, which is the
  [consistency](/patterns/consistency) failure — one object, one component.

## Exemplars

**Stripe's payment page** leads with the amount and the status, in that order,
because those two facts resolve most visits. Everything else — the timeline, the
metadata, the risk detail — is below, and the page is usable without it.

**Linear's issue view** puts title, status and assignee at the top and treats
everything else as properties. It also demonstrates the discipline: the header
has not grown as the product has.

The extractable rule: **a record header answers "what is this and what should I
do about it", not "what do we store about it".** The second question has a whole
page below to answer.