What are examples of a broken element?

Examples include a button that does nothing, a form field that cannot accept valid input, a menu that will not open, a filter that returns the wrong result, a link that sends users to the wrong destination, or a component that is hidden behind another layer. A visual defect can also be a broken element when it prevents users from seeing or using the intended control.

Is a broken element the same as a bug?

Not always. A bug is a defect in software or its behavior; a broken element describes the user-facing result. The cause may be a code defect, an API or server problem, a browser incompatibility, a configuration error, or a content and layout issue.

How can a broken element affect conversion?

If an element blocks a key action—such as adding an item to a cart, submitting a form, opening product details, or continuing to checkout—users may abandon the journey. Even when the element technically works, confusing feedback or poor responsive behavior can create enough friction to reduce completion.

What is the difference between a broken element and a dead click?

A dead click is an observed interaction pattern: a user clicks or taps, but there is no apparent response. It can be a sign that an element is broken, but it can also happen when a user clicks an image, label, or other area they mistakenly believe is interactive. A broken element is the underlying interface problem; a dead click is one possible signal of it.

How do teams detect broken elements?

Teams can combine automated checks, error monitoring, customer feedback, interaction metrics, heatmaps, and session replay. Real-user evidence is especially useful when a problem appears only for a specific browser, device, audience, or sequence of actions.

Can a broken element be visual rather than functional?

Yes. An element can be broken when it is clipped, overlapped, too small to use, unreadable, or placed outside the visible area even if its code is technically running. What matters is whether users can recognize and complete the intended action.

How should teams prioritize broken-element fixes?

Start with the issues that affect important journeys, many users, or high-value outcomes. Compare the affected segment with an appropriate baseline, investigate the user experience and technical cause, and validate the fix after release to make sure the problem is resolved without creating new friction.

What is a broken element?

Definition

A broken element is any visible or interactive part of a digital interface that fails to deliver its intended behavior. A “broken” button may not respond to a click, a form field may reject valid input, a menu may not open, or a component may render in a way that hides or blocks the action it is meant to support.

The problem can be functional, visual, or both. It may come from a software defect, a failed API call, an incompatible browser or device, a layout change, an incorrect configuration, or content that no longer matches the surrounding experience. A broken element is more specific than a design preference: the key issue is that the element prevents or significantly disrupts the expected task.

Teams usually investigate broken elements in context rather than in isolation. They look at the user’s device, browser, journey, previous actions, error messages, and business outcome to understand who is affected and how serious the issue is.

What does that mean

Imagine a door handle that looks usable but does not open the door. A broken element is similar: it is part of the interface, but it does not let the user complete the action they reasonably expect.

Why this matters

Broken elements add effort and uncertainty to digital tasks. For product and IT teams, finding the cause supports faster fixes and safer releases; for UX/UI and data teams, understanding who is affected helps prioritize changes that improve completion, reduce frustration, and protect conversions.

Use cases

Find a non-working element after a release

Relevant for: Product, IT

After a redesign, feature launch, or code change, a call-to-action, form control, navigation item, or filter may render normally but fail when users try to use it. This can be difficult to catch with a small set of scripted checks, especially when the failure depends on a particular path, browser, device, or account state.

Teams can combine interaction data, error signals, and recordings of real journeys to see what users attempted, whether the element responded, and what happened immediately afterward. The result is a shorter path from an observed failure to a reproducible issue and a fix that addresses the affected experience.

Diagnose element problems across devices and audiences

Relevant for: UX/UI, Marketing, Data

An element may work on desktop but be hidden, clipped, misaligned, or difficult to use on mobile. It may also affect only a particular browser, traffic source, region, or audience segment, making overall page metrics look normal while a smaller group struggles.

Comparing element interactions and replaying affected sessions by device, browser, or audience helps teams distinguish a technical failure from a usability or responsive-design problem. The expected benefit is a more precise fix, fewer false assumptions, and a better experience for the users who are actually affected.

Prioritize and validate fixes

Relevant for: Product, Marketing, UX/UI

Teams often discover several broken or unreliable elements at once, but not every issue has the same effect on users or business outcomes. A broken element on a high-intent checkout step may deserve attention before a similar problem on a low-traffic page.

By connecting the issue with frustration, drop-off, conversion, revenue, and affected segments, teams can decide what to fix first and then compare behavior after the change. This supports evidence-based prioritization and helps confirm that a release solved the original problem without introducing a new one.

How Contentsquare helps.

Error Analysis surfaces technical and functional errors, shows how they affect user journeys, and helps teams prioritize issues that have the greatest impact.
Session Replay lets teams watch what users saw and did, including the moments before and after an element failed or caused confusion.
Frustration Score surfaces patterns such as repeated attempts and rage clicks so teams can find experiences where users are struggling.
Heatmaps shows how users click, tap, hover, and scroll around page elements, helping teams spot ignored, misleading, or underperforming interface areas.
Impact Quantification connects an issue or behavior with affected audiences and business outcomes so teams can prioritize high-impact fixes.

FAQs on broken elements.

Examples include a button that does nothing, a form field that cannot accept valid input, a menu that will not open, a filter that returns the wrong result, a link that sends users to the wrong destination, or a component that is hidden behind another layer. A visual defect can also be a broken element when it prevents users from seeing or using the intended control.

Contentsquare x Škoda