Design for the second visit
A newly created asset record can look complete on the day someone enters it. There is a name, a photograph, a serial number and a set of attachments. The harder test comes three months later, when another person needs to identify the equipment, understand its recent history and decide what to do next. A record that survives that second visit needs a purpose beyond collecting fields.
This guide uses a fictional workshop compressor to work through the design. The aim is an operational record that helps people find and maintain information. It is not a determination of legal ownership or a substitute for the equipment manufacturer's instructions. The useful question is which details allow a real operator to complete a recurring job with less searching.
Write the task before the form
Begin with a sentence such as: a workshop manager needs to identify a compressor and find its last service note before arranging maintenance. That sentence identifies a user, an object and a reason for opening the record. It also makes it possible to test the design. A sample record either helps the manager find that information or leaves them looking elsewhere.
Choose a second task to check the record from another angle. A colleague might need to confirm which machine has been moved to another work area. A new operator might need the current manual. These tasks may reveal missing details, but do not immediately add every possible field. Ask which information belongs in the main view and which belongs in a dated event or linked document.
The NIST Cybersecurity Framework's asset-management guidance includes maintaining inventories and considering assets through their life cycles. That provides a useful reason to treat an inventory as maintained work. It does not specify the exact fields for a workshop compressor. Those fields should come from the people who use and maintain the equipment.
Separate identity from description
Give the compressor a stable internal identifier. A display name such as Workshop compressor may change when the business acquires another unit, but links to the record should continue to point to the same asset. Keep the manufacturer's model and serial number in separate fields when they matter to the workflow. A photograph can support recognition, particularly where two units look similar, but should not be the only way to distinguish them.
The description can explain the equipment's role in the business. For example, it supplies the finishing area and is normally kept beside a particular workbench. That is different from its current location, which may change. Separating these details allows the interface to show the current position while retaining a useful account of what the machine is for.
Ask an operator to identify the actual machine using only the prototype record. If they cannot, inspect the mismatch. Perhaps the internal label is unfamiliar, the serial number is difficult to locate or the photograph shows an old configuration. That observation should determine the next edit. Adding more descriptive text without understanding the failed identification may make the record longer without making it better.
Make responsibility easy to update
A useful record names the person or role responsible for keeping it current. That is not always the person who uses the machine most often. The workshop manager might coordinate service, while several colleagues add observations. The interface should make those responsibilities understandable and allow them to change when the team changes.
Avoid relying on one person's personal email address as the permanent identity of a role. If the responsible employee leaves, the record still needs an owner inside the organization. A prototype can model this with a role plus a named assignee. Test what happens when the assignee changes and whether outstanding actions appear for the next person.
Access should follow the task. A colleague may be allowed to add a maintenance note while only a manager can change key asset details. Someone helping with a repair may need a manual and recent history without access to unrelated internal records. Start with a small set of clearly described permissions, then test them with realistic role changes and old links.
Keep events separate from the current state
The current record might say the compressor is in the finishing area and available for normal use. An event history explains how it reached that state. A location change, a repair and a periodic check are different events, each with a date and a person attached. Keeping them separate makes it easier to read the latest state without losing the sequence behind it.
For the service event, ask what another operator will need later. A date, a short description of the work, the person or provider involved and a link to supporting information may be enough for the initial test. If the task requires more detail, add it deliberately. Avoid a free-text field that becomes the only place for dates, names and follow-up actions.
The system should also distinguish the date an event happened from the date someone entered it. Late entry is common in ordinary workflows. Preserving both dates prevents a colleague from mistaking yesterday's upload for yesterday's service. Let people correct an error with a visible history appropriate to the product's purpose, rather than quietly replacing every trace of the original entry.
Link documents with context
An attachment called scan-final-new.pdf is hard to use even if it is stored safely. Give each linked document a readable title, a type and enough context to explain why it belongs to the asset. The compressor's manual, a service note and a supplier message have different jobs. A reader should be able to select the right one without opening every attachment.
Record where a document came from when that matters to the task. The interface can say a manager uploaded it on a particular date, or that it is linked from an identified external source. This describes provenance within the workflow. It should not silently present every uploaded file as current, complete or authoritative.
Think about replacement before the first version ships. If a new manual or corrected service note is added, the old one may need to be marked superseded. Decide what the reader sees first, who can make that change and how the record explains it. A simple current-document label can be useful if the underlying rules are clear and the old link behaves predictably.
Test a handover, then test an export
Hand the prototype to someone who did not create the record. Ask them to identify the compressor, find the last service event and locate the current manual. Watch the sequence without explaining the screen. If they need the creator's memory to interpret a field, the record has not yet captured enough context for a handover.
Then export the record. Open the result outside the product and check whether the asset identifier, dates, document names and event sequence still make sense. An export that contains only internal IDs may be technically complete but unusable to the operator. Explain which attachments are included, which remain links and how those links behave after access changes.
For a product called Ownerships, this is a concrete first working example: one machine, a record that stays readable and a handover another person can complete. Test it with the actual users before expanding to more asset types. Their second visit will tell you which information deserves a permanent place in the product.