How to write an AI brief for a product listing page

An AI brief for a product listing page should explain what someone needs to find, which information helps them choose, and what happens when the page cannot show results. “Make it clean and modern” leaves most of that work undecided. The border radius, however, will probably be very confident.

In a frontend guidance contribution for Dupe, I worked on how new features are defined: their purpose, placement, existing components, and interaction states. Here is how I would apply that guidance to a small listing task, using a fictional desk-lamp catalog.

Start with the shopper’s decision

Write the task in one sentence: “Help someone find an available desk lamp within their budget and open its details.”

That gives the page a useful center. The reader needs a name, image, price, availability, and a clear route to more information. A review carousel or recommendation panel needs a separate reason to exist.

Then identify the decisions you still owe the assistant. Does “available” mean in stock or available for preorder? Does the displayed price include delivery? A model cannot settle your product policy by choosing a nicer badge.

For this example, define availability as in stock and display item prices in Philippine pesos, with delivery excluded and labelled. Those are fictional requirements for the exercise.

Point to existing work

In an existing app, name the nearby page and components the assistant should inspect. Ask it to check how they behave before proposing reuse. Two cards can look alike while performing very different actions.

Give it the supplied data fields and any confirmed data source. When an endpoint or rule is missing, ask it to identify that prerequisite. A convincing mock response can hide a question the team still needs to answer.

The official OpenAI frontend guidance likewise emphasizes the audience, existing conventions, and expected controls and states. The useful part of your brief is the concrete context for this particular task.

Make the brief specific enough to review

Here is a compact example you could adapt:

Task: Build a read-only desk-lamp listing within the existing app shell. Visitors can search by name, set a maximum item price, and choose “In stock only.” Each result links to its detail page.

Data and defaults: Use fictional fixtures with an ID, name, image, item price in PHP, and in-stock flag. Start with no filters and sort by price, lowest first. Break equal-price ties by name. Display “Delivery excluded” beside the price context. Buying is outside this task.

Layout: Put the title and controls before the results. On narrow screens, stack the controls while keeping their labels visible. Keep product names, prices, availability, and detail links readable without horizontal page scrolling.

States: Distinguish initial loading, no matching items, and a failed load. Keep filter values after a failure and offer Retry. For no matches, offer Clear filters. Announce a short results update without moving keyboard focus.

Review: Demonstrate the default list, a filter combination with no matches, a failed load followed by retry, and keyboard use at a narrow width. Explain any requirement the available components or data cannot support.

You can make this smaller for a small change. The goal is to capture the decisions that affect behavior, rather than fill every box in a template.

Check the states a screenshot cannot settle

“No matches” means the search completed successfully. “Couldn’t load results” means the page cannot yet answer the request. Giving both the same empty illustration conceals that difference.

For a concrete check, set the maximum price below every fixture price. The expected result is a no-matches message and a working reset. Next, simulate a failed request with those filters still entered. The expected recovery is Retry with the values preserved. These are proposed checks for the example, not results from an executed test.

Labels and feedback belong in the brief too. W3C’s form guidance explains how controls need descriptive, associated labels. Its status-message guidance covers communicating updates such as a results count to assistive technology without taking focus. “Accessible filters” becomes easier to review when you name the actual behavior.

Review against the promise

When an implementation arrives, walk through the brief with the person who requested it. Check the stated defaults, try the empty and failed states separately, and reach the controls with a keyboard. Record what was verified and what remains unresolved.

For another starting point, Amito’s table specification includes filtering and recovery decisions you can adapt to a listing. More of the work behind these articles is on my projects page.

A useful brief gives the team a shared way to judge the result. The next question is practical: can someone complete the task you described?