Scenario testing before development

The MTS product catalog needed to retain the reason for a change: who updated a product, when and why. The requirements contained few details. I reviewed the task with an analyst before preparing designs.

Several product managers could work on the same product. Colleagues needed to understand why changes were made, including when investigating disputes. I asked who needed this information, who could enter it and who could view it.

A new version went through a draft, preparation for testing, possible returns for revision and final publication. Asking for a reason at every intermediate save would generate many records within one work cycle.

At the meeting, we agreed on a provisional approach: request a comment when editing the current version, editing a historical version or publishing a new one. Intermediate draft saves were outside this approach.

I checked an edge case: one person sends a version for testing and another returns it for revision. Does the first person need to know why it was returned? This scenario was left for further clarification with the process owner.

The final step already offered a transition to the content catalog to configure basic content. I pointed out the overlap: adding another dialog would change the existing flow.

We discussed a two-step approach: enter the reason for the change, then move to content setup. I asked separately whether the comment was mandatory and what would happen if it was empty. The analyst confirmed server-side validation before publication.

For the initial design, we chose one free-text field. This was a working agreement at the meeting; evidence of implementation has not yet been found in the archive.

We considered showing the comment in the version list and on the product page. I suggested accounting for frequency of use: change reasons were needed when investigating disputes, so this information should not overload the header.

I then asked how repeated changes within one version would be retained. The discussion exposed an overwrite problem: a version could change several times, losing the reasons for earlier edits. The analyst acknowledged this risk. The transcript does not record a final storage model.

The task gained specific comment-entry points, a provisional step sequence, a required-input rule and questions about history storage. Open issues were recorded alongside them: reasons for returns from testing, repeated edits and the final location for viewing comments.

This episode was recovered from a working meeting in September 2025. The source confirms the scenario discussion and provisional agreements. It does not record a prototype demonstration or the eventual release of this feature.

For disputed scenarios across the two catalogs, I built interactive prototypes in Figma Make and reviewed them with the team before development. Some hypotheses were rejected at this stage. I then shared rapid prototyping practices with designers in the tribe.

Prototyping and the design handoff standard together reduced engineering rework by 15%. Their individual contributions were not measured; I am still recovering the counting method and comparison period. This combined measurement is not attributed to the episode described here.