A Website Feature Needs an Acceptance Example

A website feature can look finished and still leave the owner unsure what to approve. “Add catalogue filters” names a feature, but it leaves the expected behaviour open.

Which products should appear? When should the list update? What happens when the chosen filters match nothing?

Agree a few concrete examples before development starts. Each example should describe the starting point, the visitor’s action and the result they should see.

What should the website feature do?

Start with the visitor’s task. In this case, a person wants to narrow a product catalogue by type and colour.

For our example, the brief says:

• Visitors can choose one type and one colour.
• A product must match both choices to appear.
• Results update after the visitor presses Apply.
• The selected choices remain visible after applying them.

Those four lines already settle several questions that the phrase “add filters” leaves open.

A developer can choose how to build the feature around these requirements. The business owner can check the same visible behaviour without reading code.

Use a small catalogue with known data

Use a fixed set of products on an agreed preview page. Here is a fictional catalogue for the examples below:

All four products are available and shown when no filters are selected. There are no other products on this preview page.

For this example, all type and colour choices remain selectable. That allows a visitor to choose a combination with no matches. A design that disables impossible combinations would need a different example.

Keeping the data fixed makes the review repeatable. If someone adds products during the review, the expected list may change even though the filter logic stays the same.

Example 1: show the matching product

Starting point: The catalogue shows all four products. No filters are selected.

Action: The visitor chooses Backpack and Blue, then presses Apply.

Expected result: Only Blue Backpack appears. The result count is one. Backpack and Blue remain visible as the selected filters.

This checks more than whether the controls respond. It confirms that the feature uses both choices together.

If Blue Tote also appears, the result fails this example. The visitor asked for a blue backpack, so a blue tote does not belong in that list.

Software teams often use the labels Given, When and Then for this structure. Cucumber’s Gherkin reference explains the same sequence: starting context, action and expected outcome. A short document with plain headings is enough for this discussion.

Example 2: explain an empty result

Starting point: The catalogue shows all four products. No filters are selected.

Action: The visitor chooses Backpack and Green, then presses Apply.

Expected result: No product cards appear. The result count is zero. A message says, “No products match these filters.” The selected choices remain visible, and the visitor can reach the Clear filters control.

There is no green backpack in our sample catalogue. An empty result is therefore correct.

The message and the route back to the catalogue are part of this agreed example. A blank area with no explanation would leave the visitor unsure whether there were no matches or whether the page had failed to load.

Agree the wording and the recovery action while writing the brief.

Example 3: return to the full catalogue

Starting point: Backpack and Green are selected, and the empty-result message is visible.

Action: The visitor presses Clear filters, then Apply.

Expected result: Both selections are cleared. All four products return. The count is four, and the empty-result message disappears.

This example also clarifies what Clear filters means in this design. Here it clears the choices, and Apply updates the results.

Another design might reset the results immediately. Either behaviour can be described and checked; the team needs to agree which one it is building.

Decide which other behaviours need examples

The three examples cover a small, defined part of the feature. Other choices may matter to your project:

• Can a visitor select several colours at once?
• Should filters survive a page refresh or a shared link?
• What should happen when the visitor uses the browser’s Back button?
• Where will Apply and Clear filters appear on a phone?

Add examples for the behaviours included in the brief. Keep each one focused enough that someone can repeat it and recognise the expected result.

Also agree the devices and browsers used for the review. These examples address filter behaviour; the wider project still needs its agreed checks for accessibility, security and performance.

Record the result against the agreed example

For each review, keep a short record:

• Preview-page address and version reviewed.
• Sample products used.
• Example checked.
• Expected result and actual result.
• Any issue that needs a fix.
• Reviewer and date.

A screenshot can support the record. A short screen recording can help when the issue involves several actions. Both are more useful when attached to the example they demonstrate.

If the data is missing or the preview page is unavailable, record the check as blocked. If the observed result differs from the agreed example, describe that difference so the developer can reproduce it.

For businesses discussing website development with Salestudia in Germany, a concrete feature example is useful material to bring to the project brief. Salestudia is an independent agency based in Idstein, working on websites and digital marketing for businesses in Germany.

Choose one feature from your next website project. Write its starting point, one action and the result a visitor should see. Then ask the person building it to walk through the same example with you before development begins.

Written by Vladyslav Yanchenko, who works on marketing at Salestudia.