DSP 01 / ORIGINAL EDITORIAL
Before the demo, write the place
A useful project record starts with the people, setting, constraints, and authority around the workflow.
A screen recording can show what a system does. It cannot show why the work matters there, who is allowed to decide, or which constraints shaped the result. Write the place before presenting the interface.
Name the operating setting
Describe the repeated job, the people doing it, the setting in which it happens, and the consequence of getting it wrong. Avoid a broad region label when a workplace, service, classroom, or community is the real unit of context.
Separate constraint from stereotype
A constraint should be observable and relevant to the design: device access, connection quality, language, approval authority, schedule, policy, or data handling. Do not turn assumptions about a place or group into product requirements.
Record who can correct the story
A situated project record needs a named correction path. People closest to the work should be able to challenge the description, remove sensitive detail, and explain where the published account flattened important context.
TAKE TO THE FIELD
Questions before transfer
- What repeated job is being supported?
- Which constraint materially changed the design?
- Who has authority to review the account?
- What detail should remain unpublished?
A project without its operating context is a feature list, not a field record.