A customer selects a budget, a location, and a time window. The recommendation tool responds with a polished set of options. That looks like success until the customer notices that none meets the original budget. Somewhere between the form and the result, a requirement became a preference without anyone saying so.
For a business building a selector, an empty answer can be more useful than an attractive answer to a different question. The challenge is to explain the absence without abandoning the customer. Good failure-state design shows which requirements remain intact, what the available catalog cannot supply, and which change the customer may choose to make next.
Join The European Business Briefing
New subscribers this quarter are entered into a draw to win a Rolex Submariner. Join 40,000+ founders, investors and executives who read EBM every day.
SubscribeDefine Which Answers the Tool May Refuse
Before writing the empty-state message, separate conditions that exclude an option from preferences that rank acceptable options. The difference should exist in the product brief, not emerge as a surprise in interface copy. If a maximum spend is an exclusion, an expensive result cannot be rescued by being otherwise appealing.
Small tools make this distinction visible. The friends-plan picker from Palaura describes group size, budget, setting, time, and a drinking preference as hard filters over a written activity catalog. Those boundaries explain what a result is meant to satisfy. They also provide a useful product-design question: what should the interface do when a finite catalog has nothing suitable left?
The answer need not be to generate more confident prose. A limited catalog has limited coverage. Calling an unavailable combination unusual can sound as though the customer supplied the wrong answer, when the actual limitation belongs to the service. State the scope plainly: the tool has no matching option in the set it can currently offer.
Write a few rejected combinations into the specification alongside the successful examples. A test should check that an excluded result stays excluded, not merely that the page returns a populated card. Otherwise a change that fills every screen may appear to improve the product while weakening the promise made by its controls.
Distinguish an Empty Catalog From a Broken Request
Several situations can produce a blank result area. The inputs may be incomplete, the request may have failed, or the search may have completed without a match. Each calls for a different next action. Asking a customer to change preferences when the service failed to load would make the customer repair the wrong problem.
Use the message to name the state the system actually knows. “Choose a time window” concerns missing input. “We couldn’t load the options” concerns retrieval. “No option in this catalog matches these choices” concerns coverage. These are suggested design examples, not messages observed in a particular product.
Preserve the selections on screen so the customer can inspect them. A generic reset button removes the evidence needed to decide what to change. If a group size was entered incorrectly, correcting that field should be enough. Re-entering the whole form creates extra work and can obscure whether the next result came from an intentional adjustment.
The business should also distinguish a genuinely empty catalog from a temporary inventory gap. A static idea selector and a booking service cannot make the same availability claim. In the first, the scope is the written collection. In the second, it may depend on current stock or time-specific capacity. An accurate explanation follows the underlying service, not the visual style of its result cards.
Ask Before Relaxing a Stated Requirement
Relaxation can be useful when the customer controls it. A tool might show that broadening the time window would reveal more choices, while leaving the original search unchanged until the customer agrees. Present the proposed change beside the requirement it affects. Avoid hiding it in a footnote under a result that already appears selected.
A contrasting example appears in the party-game tool at Palaura — Alternative to Speed Dating Apps. Its description says the room condition may be loosened when needed to fill three slots, while supplies and familiarity are never loosened. The useful lesson is the need to describe unequal treatment of inputs. The policy is specific to that tool, not a rule that all selectors should adopt.
For a hypothetical venue selector, a recovery message might say: “No match with these choices. Search an end time one hour later?” Only claim that the end time caused the gap if a controlled check with the other inputs unchanged establishes it. Otherwise several conditions may be responsible. The action should update that field visibly. If price and location remain fixed, show them as unchanged. The customer can then understand the new result as an answer to a revised request rather than an unexplained exception.
Palaura’s two tools illustrate why a single company may need more than one result policy. A constraint that is fixed in one selector may be handled differently in another. Teams should document the policy at the level where the decision occurs, so designers and support staff do not infer a universal rule from a neighboring product.
An optional alternative is to let the customer keep the requirements and leave with no result. That is a valid outcome. The interface should not repeatedly push a wider search after the customer has declined it. A service can acknowledge a limit without turning the interaction into a negotiation over the customer’s needs.
Treat Repeated Gaps as Catalog Evidence
An empty result can inform product work, but its meaning needs care. Repeated searches with the same unmatched combination may indicate missing coverage. They may also reflect a confusing label or an input that people interpret differently from its designers. Review the pattern before deciding that the catalog simply needs more entries.
Support feedback can help identify the misunderstanding. If users consistently think “evening” means one hour, adding ten more whole-evening options will not resolve it. A clearer time description may be the more useful change. Keep the investigation tied to the exact condition that failed rather than assigning a broad label such as low engagement.
This is a proposed business-side review, not a report of Palaura usage data or an observed empty result. For a written catalog like Palaura’s, expanding coverage would still require checking that each added idea satisfies the stated filters. More entries are not automatically better coverage. Several near-identical suggestions may leave the same practical gap while making the catalog look larger in a report. In an illustrative coverage check, adding more outdoor options does nothing for an unmatched indoor request. Record which previously unsupported combination the new entry can satisfy; that is a more useful addition to the release note than the catalog’s new total.
When the product team changes either the catalog or the relaxation policy, revisit the failure examples. Confirm that previously excluded options remain excluded where promised, and that any permitted change is visible to the customer. Successful screens deserve review, but the empty screen is where the tool reveals how seriously it takes its own inputs.
A recommendation service does not need an answer to every request. It needs a clear account of the request it answered. When there is no suitable option, an honest explanation and a controlled next step preserve that account better than a full screen of exceptions.
