By Eugen Stoicov, Senior Product Designer, Vienna. Published 2026-02-04.
In regulated software, the record of what happened is not logging. It is the product, and it should be designed like one.
Most teams treat the audit trail as exhaust. The feature does the work, the log records that the work happened, and someone exports a CSV when an auditor asks. That arrangement holds right up until the moment it matters.
In regulated development the record is not a byproduct of the work. It is the deliverable. A change to a requirement, a risk or a test is only as good as the account you can give of it later, sometimes years later, to someone who was not there and has no reason to be generous.
A log answers what the system did. A record answers what a person decided and why. Those are different questions, and the gap between them is where audits go badly.
The usual log has a timestamp, an actor and a field that changed. Useful for debugging. Nearly useless for explaining a decision. The reviewer is not asking which value moved. They are asking who judged that it should, against what, and whether anyone competent disagreed.
So the interface has to capture the reasoning at the moment it exists, which is the moment of the decision. Ask afterwards and you get reconstruction. Reconstruction is what people do instead of remembering.
The person who reads this record is the one user who never gets a persona. They arrive late, they did not attend the meeting, and they are looking for a reason to doubt you. That is the job, and it is a fair one.
Designing for them changes small things. Identifiers get resolved to names. Relative time gets an absolute date next to it. A superseded version stays reachable rather than being quietly replaced. Every one of those is a five-minute engineering decision that decides whether the record survives contact with a stranger.
It took me longer than I would like to admit to stop designing these screens for the team that writes the record, and start designing them for the person who has to believe it.
The cheapest moment to record a rationale is while someone still holds it in their head. The most expensive is the week before an audit, when three people reconstruct a decision from a chat thread and a calendar invite.
That argues for one field, at the point of change, with a real question attached. Not a mandatory comment box that everyone fills with "updated". A specific prompt earns a specific answer. A generic prompt trains people to defeat it.
The test I use: if the only way to produce the compliance artefact is a separate exercise after the fact, the interface has failed and the documentation is fiction with good formatting.
It costs steps, and the honest version of this argument admits that. Every rationale captured is friction on someone trying to finish a release. The design question is not how to remove the friction. It is where to spend it.
Spend it on the changes that carry risk, and take it off everything else. A traceability tool that treats a typo fix and a requirement change with equal ceremony has not made anyone safer. It has taught its users to click through ceremony, which is worse than having none.
Topics: Compliance, Traceability, Product design.