Turning requirements into decisions

Two product managers and three analysts worked across the catalogs. I reviewed their requirements and prepared scenarios, designs and implementation rules for three feature teams.

Product catalog
Product and service creation and composition: a wizard, nested products and bundles.
Content catalog
Descriptions and media used on storefronts.

I worked through the creation wizard and product composition with the analysts: which data each step needs and how the interface responds to a selection. My working questions included whether to show a nested product’s description and where it should be edited.

Test behavior before the sprint

Disputed transitions and selection flows needed discussion with the team. Separate screens made it difficult to check the full journey before development.

I built interactive prototypes in Figma Make and reviewed them with the team before development. Some hypotheses were rejected at this stage.

I then introduced rapid prototyping within the design tribe and trained designers in Figma Make and AI.

Hand off decisions with their states

Designs reached engineering without some empty lists, errors and intermediate loading states. Questions arose mid-sprint, during implementation. With one designer supporting three teams, these gaps generated additional clarification work.

I introduced a handoff standard: components come with their states, and edge cases are recorded in the file. I standardized the Figma file structure so designs could be found by task.

Component state example

Choose a state to see both the interface and its implementation rule.

Add a service to a bundle

Home internet

A service to add to a bundle

Handoff rule

Show an available record. Confirm selection and retain its value.

Interactive reconstruction of the handoff principle. Demo data; this is not an original MTS screen.

What travels with the design

Behavior
Component states and transitions.
Edge cases
Empty results, errors, loading and unavailable actions.
Task context
The task and its design in a shared file structure.

The combined outcome

15% less rework during implementation

Rapid prototyping and the handoff standard together reduced engineering rework by 15%. The contribution of each change was not measured separately.

I am still recovering the counting method and comparison period.

The next measurement step would be to separate task returns by cause: an untested scenario, a missing state, an unclear requirement or an implementation constraint. This would help identify the contribution of each change.

Product descriptions: a review of working notes

The problem comes from my working questions. The solution and interface are reconstructed for this review; deployment is unconfirmed.

Legacy description and short-description fields remained in the product, while new storefront copy was expected to come from the content catalog. My notes ask: hide the old fields or retain them for comparison? Copy the new text or show its source?

For this review, I chose a preview of published copy with a reference to its source. Descriptions are edited in the content catalog; drafts do not change storefront copy. Legacy values remain available for comparison.

Which text will the customer see?

Create a draft, disconnect the source and try publishing the change.

Content catalog

Source available

Published · version 1
Short description
Home internet with a rental router.
Full description
Connection is subject to availability at your address. Router rental is charged separately.

Preview in the product catalog

Web storefront · English locale

Published · version 1
Short description
Home internet with a rental router.
Full description
Connection is subject to availability at your address. Router rental is charged separately.

One source for the copy. Edit descriptions in the content catalog.

Legacy description · for comparison

Home internet. Router included in the bundle.

Illustrative example with fictional terms and versions. Actions affect this demo only.
Alternatives and constraints
Copy the text into the product
A transitional option if the API requires legacy fields. It needs synchronization rules and a way to resolve conflicts after local edits.
Remove the fields and leave a link
Enough if descriptions are checked infrequently. It requires switching systems; legacy values can still be kept separately for comparison.
Reference the source and preview its publication
Useful for frequent checks. It requires integration, stable identifiers, permissions and publication rules for each storefront and locale.

Implementation requirements

Legacy data
Retain for comparison. Hiding fields in a form does not delete them from the model: check API requirements and other consumers first.
Composition and bundles
Viewing a nested product should not create another editing location for its copy. Inheritance and overrides need separate agreement.
Source outage
The proposed preview retains the last retrieved publication with a freshness warning. The live storefront's outage behavior needs a separate agreement with engineering.

To validate this proposal, I would ask someone to go from draft to publication and explain which copy customers currently see. I would also check a connection failure and a product without content, which needs an explicit Description not yet published status.

Sources for the reconstruction

Patterns were checked against current documentation. These sources do not describe MTS's implementation.