Widget UX that does not interrupt (but does advise)

Widget UX that does not interrupt: product help at the right moment

An AI widget can help a visitor choose, compare and resolve doubts. It can also do the opposite: cover a product image, block a filter, disrupt a mobile thumb path or demand attention too early. Good widget UX is not about maximising chat starts. It is about making help available when a shopper benefits from it, without taking over the shopping experience.

Fynd is an AI product advisor for webshops. Its widget can have a distinct persona, theme colours, welcome and suggested prompts. Those options are valuable when they respect the context of the page. This practical guide covers placement, open versus closed behaviour, mobile design, accessibility and a safe launch process.

Start with page intent

A home page, product listing page and product detail page have different jobs. The widget should support that job, not repeat it.

On a listing page, a shopper is usually narrowing the field: selecting a category, applying filters, scanning products and possibly comparing options. Fynd is most useful here as search and decision support. A closed widget with a quiet, concise hint usually works better than an automatically open chat. Consider “Need help choosing?” or a category-specific prompt such as “Which size or option is right for me?”

On a PDP, intent is more specific. The shopper has found a product and wants reassurance: will it fit, work with something else, or differ from an alternative? The widget can be more visible here, provided it does not cover the purchase button, price, images or variant selector. Suggested prompts can be more concrete:

• “Will this work for my situation?”
• “Compare it with an alternative”
• “Which size do I need?”
• “What else do I need with it?”

The chat should not duplicate an existing, clearly visible size guide or specifications tab. It can explain that information and translate it into a decision.

Choose open or closed intentionally

An open widget asks for attention immediately. A closed widget waits for a visitor to decide that help is useful. Neither is always correct.

Use a closed widget when:

• the page has substantial primary interaction, such as filters, configurators or checkout;
• the visitor is still browsing;
• the widget has little space on mobile;
• you are still learning which placement and prompts work;
• the offer already contains a lot of visual or written explanation.

A closed state can still be inviting. Use a clear label, recognisable icon and perhaps one short contextual sentence. Avoid pulsing animation, automatic sound and repeated opening. Those are interruptions, not assistance.

Consider an open widget only when a route clearly calls for advice: a gift finder, a complex category, a campaign with few products or a dedicated advice page. Prefer opening it after an intentional action such as “Find my match,” rather than at page load. If you do auto-open, do it no more than once per session, after a delay, and only when the panel cannot cover core content.

Always respect a close action. Once someone closes the widget, it should not spring open again on the next page. Preserve that choice for at least the current session.

Keep the floating control out of the way

The lower-right corner is familiar, but it is not automatically safe. Check every template and breakpoint. Cookie banners, chat tools, sticky add-to-cart bars, discount buttons and mobile navigation often compete for that same location.

Make a simple map of fixed elements for each page type. For every element, ask whether it is essential, temporary or dismissible. The Fynd trigger must not cover an essential control. On PDPs in particular, a sticky add-to-cart bar may appear after a shopper scrolls. Move the widget above it, keep it clear of the bar, or choose another logical corner in your layout.

Also keep it away from:

• product carousel arrows;
• filter and sort controls;
• consent banners;
• form fields and checkout navigation;
• iOS and Android system controls;
• content visible only at narrow widths.

Test with real product names and badges. A button that looks fine on an empty staging page can still cover something important on a PDP with a sale badge, stock message and sticky CTA.

Design for the mobile thumb zone first

Mobile shoppers are often the largest audience, yet simply shrinking a desktop widget is not enough. The lower edge is easy to reach with a thumb, but it is also crowded by browser controls, safe areas and sticky navigation. Put the trigger within reach without pushing it against the edge.

Useful mobile rules:

• provide a generous tap target, not only a tiny icon;
• respect the safe-area inset on devices with a home indicator;
• avoid the space occupied by sticky add-to-cart or bottom navigation;
• do not make the chat consume the full viewport without a clear close action;
• keep the keyboard, input field and send button usable together;
• prevent horizontal scrolling and text hidden behind the input bar.

Open the widget on mobile as a calm, clearly bounded panel. Keep the product page visible where possible so a shopper can check details while typing. A longer conversation may justify a larger view, but always provide an obvious back or close action and restore the page’s scroll position when it closes.

Suggested prompts matter especially on mobile because typing costs more effort. Do not show eight at once. Start with two or three short choices that fit the screen, such as “Which size?” and “Compare options.” Make them easy to tap and ensure the wording does not truncate halfway through.

Make the first message contextual

A general “How can I help?” is safe, but it does not use the reason the widget exists on that page. Match welcomes and prompts to placement and persona without pretending to know personal information about the visitor.

A general shop bot on a listing page can say, “I can help you find the right option.” On a PDP, the same bot can say, “Questions about this product? I can help with size, use and alternatives.” A B2B persona on a parts page can ask, “Are you searching by model, connection or part number?”

Avoid demanding language such as “Wait! Need help?” and do not use fake urgency or suggest that the bot has found a solution before a question was asked. A welcome should offer permission to help, not claim attention.

Let colour support the brand, not replace controls

Theme colours make Fynd recognisable within a webshop or a specific brand line. Choose a primary accent that fits the brand, while retaining conventional signals for opening, closing, sending and focus. A green tick, small cross or icon alone is not clear to everyone; pair it with text or an accessible name.

Check at least:

• sufficient contrast between text and background;
• sufficient contrast for borders and focus states;
• readable prompt buttons in normal, hover and selected states;
• consistent colours for links and actions;
• no information conveyed by colour alone.

A quiet closed widget can carry the brand accent. An open panel does not need to be entirely that colour. Neutral backgrounds reduce visual load and keep product links, prices and comparison tables readable.

Accessibility is part of conversation UX

A widget is an interactive application layered over your shop. Treat it as a fully accessible interface element.

The trigger needs an accessible name, for example “Open product advice.” It must be keyboard reachable and have a visible focus ring. When the panel opens, focus should move logically to a title, welcome message or input field. When it closes, focus should return to the button that opened it.

Also verify:

• can Escape close a dialog or panel?
• is screen-reader reading order logical?
• do icons have text alternatives?
• are new responses announced without pulling a visitor away from the input?
• are suggested prompts actual buttons rather than clickable text?
• does content remain usable under text zoom and reflow?

Avoid automatically moving attention effects that cannot be stopped. Give visitors enough time to read responses. When the bot offers a product or policy link, make its destination clear.

Connect pages to bot personas

If Fynd supports multiple bots in one shop, the widget should not switch arbitrarily. Select a persona by storefront, collection, brand or route, but show one primary widget at a time. A skincare PDP can use a brand expert; a general category page can keep the general shop advisor.

Make the persona apparent through its name and welcome, not colour alone. It can use different suggested prompts and, where appropriate, isolated knowledge. That prevents a specialist from recommending products from another brand line. Make sure basic service knowledge such as returns and delivery remains available when it matters to the decision.

Do not unexpectedly change bots in the middle of a conversation when a visitor changes page. Preserve session context, or explain that support is now moving to a broader shop advisor. The experience should feel like a continuous shopping route, not an unexplained transfer.

Validate in the playground before launch

The Fynd playground is where you evaluate content and interaction together before visitors see the widget. Test the route to an answer, not answers alone.

Create a small desktop and mobile test matrix:

• open and close the widget on the home page, listing page and PDP;
• try a product comparison and a size or compatibility question;
• test every suggested prompt for relevance and length;
• enter a long product name and long question;
• open the widget with keyboard and screen reader;
• test with sticky banners, cookie consent and add-to-cart active;
• ask something outside its knowledge and check the honest hand-off;
• switch language or storefront if you support NL and EN.

Ask someone unfamiliar with the setup to complete a task too. They will notice sooner that a button resembles a cookie icon, the chat covers the price, or a prompt is unclear.

Launch checklist

Before going live, work through this list:

• Is there at most one Fynd trigger visible at once?
• Does the closed or open widget cover no CTA, filter, product image or form?
• Is open behaviour deliberate rather than repeatedly automatic?
• Do welcome and suggested prompts fit the current page and persona?
• Are controls comfortable to reach in the mobile thumb zone?
• Do close action, focus, keyboard and screen reader behaviour work logically?
• Do colours, text and focus rings have adequate contrast?
• Does the bot point to the correct products and market or brand information?
• Has the configuration been tested in the playground on mobile and desktop?
• Do you know which post-launch signals to watch, such as repeated questions and abandonment?

Help that does not have to fight for attention

A good Fynd widget is available without being dominant. On listings it supports discovery; on PDPs it supports a decision. On mobile it respects the thumb zone and limited space. In every context it uses colour and persona to clarify who is helping while keeping controls and accessibility consistent.

Start closed, make prompts page-specific, and open only when the shopper clearly asks for help or the route calls for it. Test the full experience in the playground before launch. That makes product advice feel like a natural next step in the shop, rather than an interruption.