UX artefacts

A UX practice produces artefacts. The question this page answers is which of them should be digitised into something a machine reads, and which should stay a photograph of a wall.

Getting it wrong is expensive in both directions: a tool tax paid on something that changes hourly, or a wall photograph that was the only record of a decision six people are now implementing differently.

The test

An artefact deserves to be digital when something downstream consumes it automatically. Not when it is important — importance argues for writing it down, not for tooling it.

Artefact	Consumed by	Verdict
Design tokens	The build, every application	Digital. Hand-copying is the failure mode the whole contract exists to prevent
Component contracts	Scaffolding, stories, tests, docs	Digital. This is the technical contract
State cards from example mapping	Stories, interaction tests, scenarios	Digital, once agreed — they name the states that must exist
Change requests against a contract	The contract’s own backlog	Digital. A request that lives in a session photograph is a request that never happened
Usability findings	The work, and the contracts	Written down, per finding. A recording nobody indexes is a recording nobody watches
Green cards from example mapping	Journey tests, with the same values	Digital — as Gherkin, not retyped
The journey map	Nothing automatic; it informs people	Wall, then a page. Digitising it buys nothing but tidiness
The story map	The ticket tracker, loosely	Wall while it is argued about, a shared canvas once it stabilises
Personas	Nothing	Wall. And revisit them, or they go stale with authority
Critique notes	The next design iteration	Wall. Decisions go in the design; the notes are scaffolding
Research recordings	People, carefully	Stored, not digitised. Clips over transcripts over summaries

Why the top half is worth the tooling

Because each of those has a second implementation problem. A token copied into CSS, a state named in a card and again in a story, a value written on a green card and again in a test — each duplicate is a place where the two copies can disagree while both continue to look correct.

That is the same failure as a hand-written API stub, and it has the same cure: one source, generated downstream, and a hand-edit downstream treated as a bug in the source rather than as a local fix.

Why the bottom half is not

Because nothing reads them, and tooling something nothing reads adds cost and subtracts candour. A journey map in a wiki gets updated by whoever remembers; a journey map on a wall gets updated by whoever is standing in front of it, which is more people more often.

There is a second reason, less often admitted: the artefacts in the bottom half are worth more as a record of a conversation than as a record of a conclusion. Digitising them tends to keep the conclusion and lose the argument, and the argument was the part that would have told the next person why.

The rule of thumb

Digitise what a build reads. Photograph what a person reads. Revisit anything that is cited more than once a quarter.

The last clause is the one that catches the persona in amber and the story map that has not changed since kickoff. An artefact being cited often is not evidence that it is still true; it is evidence that being wrong would be expensive.