Empty, loading and unavailable are different states and should not look like the same blank panel. A customer needs to know whether to wait, choose another item or take a different action.
Treat these states as part of the storefront design from the beginning. They are not temporary developer screens that can be ignored after launch.
Distinguish the causes
An empty bag contains no selected items. A loading bag is waiting for information. An unavailable service cannot currently provide the result.
Use language that matches the cause. “No products” is misleading when the catalogue failed to load.
The implementation must identify the state accurately; design cannot repair a false underlying classification.
Give empty states a useful next step
An empty bag can link back to a relevant collection. A category without products can explain the situation and offer broader browsing.
Do not fill the space with invented products or unsupported restock promises.
Keep the action proportionate. The customer should understand the state without being forced into a promotional popup.
Reserve layout during loading
Use stable space for images and key content so the page does not jump repeatedly as information arrives.
A placeholder should not resemble a purchasable product or a confirmed amount.
Do not show an old price as current merely to avoid an empty area while data is loading.
Keep waiting feedback honest
If an operation is pending, explain that it is in progress without claiming success. Avoid endless animation with no route to understand a prolonged delay.
A retry may be appropriate for a read, but uncertain order or payment submissions require more care.
Do not invite repeated commitment actions before checking whether the original attempt was recorded.
Explain unavailable products
Show whether an item or a particular option cannot currently be ordered. Preserve useful product information where appropriate.
Do not silently select a substitute. The customer should make any changed choice.
If the business offers a genuine enquiry or notification process, describe it accurately. Do not promise a feature that the store does not provide.
Design service outages separately
A temporary inability to load the store should not appear as a permanently empty catalogue.
Use a concise explanation and a safe next step. Keep technical details and secrets out of public error text.
Avoid a fallback to fictional demo content that could be mistaken for the merchant's live range.
Make controls match the state
A disabled action should be visibly and functionally disabled where appropriate, with an understandable reason. Do not rely only on a faded colour.
A retry action should indicate what it retries. A contact route should provide useful context without exposing private information.
Check keyboard access and focus behaviour as part of the implementation review.
Keep brand treatment consistent
Use the store's typography, spacing and colour rules while preserving the message's clarity. An unavailable page should not look like an unrelated unfinished application.
At the same time, do not decorate an error so heavily that the explanation becomes hard to find.
The state should be calm, recognisable and useful.
Test transitions
Move from loading to content, empty to populated and unavailable to recovered in a safe environment. Check that old messages and controls do not remain.
A screenshot of each state is not enough to prove the transition works.
Use representative content and a phone-sized view, including a focused field if the state occurs within checkout.
Distinguish stale from confirmed information
If earlier data remains visible during a refresh, make sure the customer is not encouraged to rely on an amount or availability that the system cannot currently confirm. The appropriate treatment depends on the operation, but the interface should not disguise uncertainty simply to avoid a visual gap.
Keep the state inventory
Record the expected message and action for the important states. Revisit it when integrations or workflows change.
A good fallback does not pretend the system succeeded. It tells the truth about what is known and helps the customer take the next safe step without losing the store's identity.
Examples are illustrative. Confirm current features, charges and suitability before making a business decision.
Explore this topic → · Find an oBizee setup guide · Ask about your store