Write a brief for a comparison list that keeps the buyer's priority
A useful brief identifies the task, source and acceptance result without pretending to choose every implementation detail. This fictional example concerns a buyer who wants to print three catalogue options in the order they intend to discuss them with a colleague.
Describe the present problem
The buyer selects C-21, C-22 and C-23, then places C-23 first because it is their preferred option. The on-screen comparison reflects that order. The print view queries the catalogue again and returns the items alphabetically, so the printed page begins with C-21.
The facts are correct, but the printout loses the buyer's deliberate discussion order. The requirement is not to change the catalogue's default sorting.
State the first delivery
Let a buyer arrange selected catalogue items for comparison and print the same ordered list with its item references and approved characteristics.
The source of the product facts remains the catalogue. The source of the comparison order is the buyer's current selection. The first delivery covers the comparison and print views; it does not save a customer account, create a quotation or reorder the public catalogue.
Supply the acceptance fixture
| Check | Expected result |
|---|---|
| Select C-21, C-22 and C-23 | Three distinct references appear |
| Move C-23 first | Screen order becomes C-23, C-21, C-22 |
| Open the print view | The same order and approved facts appear |
| Return to the catalogue | Its ordinary ordering is unchanged |
| Remove C-21 and print again | C-23 and C-22 remain in that order |
The content owner confirms which characteristics belong in the comparison. The design review includes long labels and the final printed layout so the item reference does not become separated from its values.
Name the decisions still open
The brief asks the implementer to inspect the current comparison tool and supported print route. It does not assume that the existing platform can store selection order in the required form. If it cannot, the estimate should explain the smallest supported change.
The owner also needs to decide whether selections should survive closing the browser. That is a separate persistence requirement, deliberately excluded from this first task until there is evidence it is needed.
Leave the conversation with a reviewable scope
The completed brief identifies one observable failure, two different ordering sources and a compact acceptance set. An implementer can assess the current system and propose a bounded change without turning the request into a full customer portal.
Use the same pattern for your own task: explain what should remain attached to the user's decision, what comes from an authoritative source and what must remain unchanged. The project planning guide and handover sheet help gather those details before you contact us.