Example: Scope Decisions (Business Affiliates)

This file excerpts three of the most instructive scope decisions from the Business Affiliate UX project. Each decision records what was chosen, what was deferred or eliminated, and the reasoning. Future projects should record decisions at this level of specificity.

See the Scope Analysis template for the full template structure.

SD-1: Detail Panel Layout

Decision: Continuous scroll with collapsible sections replaced the original 4-tab stepped layout.

Rationale: A stepped tab layout imposes navigation friction when a record has a moderate number of fields spread across categories. Users repeatedly switched tabs to cross-reference values, which the stepped layout made expensive. A continuous scroll with collapsible sections gives the same visual organization while keeping all fields reachable without a navigation action. The collapsible sections preserve scannability for users who only need one section. This decision applies whenever a detail view has 3-6 logical groupings and fewer than ~40 total fields; beyond that threshold, tabs or a side-nav should be re-evaluated.

SD-3: Roles — Silent VENDOR Assignment

Decision: During Business Affiliate creation, a single VENDOR role is automatically assigned in the background. No role selection UI is presented. All role management is deferred to a separate workflow.

Rationale: Every Business Affiliate requires at least one role to be functional, so creation without a role would produce a broken record. However, role selection UI during creation adds steps and concepts that distract from the primary creation flow. The VENDOR role is the correct default for virtually all initial creation scenarios. Surfacing role management only after the record exists keeps the creation wizard focused and removes a source of creation-time errors. This pattern — “assign a sensible default silently, expose management later” — is reusable for any entity that has a required association with a short list of valid initial values.

SD-5: History — Deferred

Decision: REF::BA::0006 (View History and Restore) is deferred entirely. No history UI was built as part of this project.

Rationale: Browsing and restoring historical versions of a record requires bitemporal version browsing: a timeline model, a diff view, and a restore confirmation flow. These concerns are not specific to Business Affiliates. Designing them correctly for Business Affiliates and then re-designing them for every other entity is wasteful and risks producing an inconsistent UX across entities. The right approach is to design a generic GEN::ENT-DA::0008 History and Restore pattern first, then implement it for Business Affiliates as a thin consumer. Until that generic pattern exists, the History feature is deferred. This principle — defer entity-specific work that depends on a missing generic pattern — should be applied whenever a feature would require designing a cross-cutting concern from scratch.