Toast notifications are the quiet workhorses of modern interfaces. They confirm actions, warn users about small issues, and communicate system events without interrupting the flow of work. Done well, they feel invisible until needed. Done badly, they block content, disappear too fast, or annoy users to the point of ignoring them entirely.

This guide walks through everything you need to build effective, accessible, and beautiful toast notifications, with real examples and the mistakes we see most often in production apps.

What Is a Toast Notification?

A toast notification is a small, auto-dismissing message that appears temporarily on top of the interface to give the user feedback about a low-priority event. The name comes from the way it pops up like a slice of toast from a toaster.

Unlike modals or dialogs, toasts do not require user action. They inform, then disappear. This write-up is worth a look.

Toast vs. Other Notification Patterns

When to Use Toast Notifications

Toasts are perfect for ephemeral, non-critical feedback. Use them when the user needs to know something happened, but the app can safely continue without their input.

• Successful save, upload, or copy to clipboard
• Item added to cart or moved to favorites
• Non-blocking connection warnings (e.g. “Reconnecting…”)
• Undo affordances after a destructive action
• Background task completion (“Report ready to download”)

When NOT to Use a Toast

• Critical errors that require user decision (use a modal)
• Persistent status information (use a banner or status bar)
• Long messages that need reading time (use inline text)
• Confirmations for irreversible actions (use a dialog)

Ideal Placement

Placement affects both visibility and how disruptive the toast feels. There is no single correct location, but a few patterns dominate modern design systems.

Consistency matters more than location. Pick one spot and stick with it across your product so users learn where to look.

Duration: How Long Should a Toast Stay Visible?

Too short and users miss the message. Too long and it becomes clutter. The sweet spot depends on the content length and severity.

1. Short message (1 to 3 words): 3 to 4 seconds
2. Standard message (one line): 4 to 6 seconds
3. Message with action button (like Undo): 6 to 10 seconds
4. Error or warning toast: persistent until dismissed, or minimum 8 seconds

A good rule: give users at least 1 second of reading time per 2 words, plus a buffer for focus shift. See logrocket.com for their take.

Styling Toast Notifications

Good toast design is about hierarchy and clarity. Users should be able to scan and understand the message in under a second.

Anatomy of a Well-Designed Toast

• Icon indicating status (success, error, info, warning)
• Concise message, one line ideally, two maximum
• Optional action such as Undo, Retry, or View
• Close button for users who want to dismiss early
• Subtle shadow to lift it from the background
• Rounded corners (8 to 12px is standard in 2026)

Color Conventions

Animation

Keep motion subtle. A slide-in from the edge combined with a fade works best. Animation should last 200 to 300 milliseconds. Any longer and it feels sluggish. Any faster and users may miss it appearing.

Accessibility Considerations

Toasts are one of the most commonly broken components for accessibility. Since they appear and disappear quickly, they can be missed entirely by screen reader users or people with cognitive disabilities. There’s a good explainer over at hpe.design.

Key Accessibility Rules

• Use ARIA live regions (role="status" for info, role="alert" for errors) so screen readers announce the message
• Ensure color contrast meets WCAG 2.2 AA minimum (4.5:1 for text)
• Never rely on color alone, always include an icon or text label
• Give users a way to pause auto-dismiss when hovering or focusing
• Provide keyboard access to any action buttons inside the toast
• Respect prefers-reduced-motion to disable slide animations
• Avoid stacking too many toasts, three is a reasonable maximum

Common Mistakes to Avoid

1. Using toasts for critical errors. If the user must act, use a modal or inline error instead.
2. Dismissing too fast. A 2 second toast is unreadable for most users.
3. Covering interactive elements. Never let a toast block a button or input the user might need.
4. Stacking too many toasts. Queue them or group them into a single message.
5. Forgetting mobile. Ensure toasts don’t collide with the on-screen keyboard, safe areas, or bottom nav.
6. No dismiss control. Always give users a way to close early.
7. Overly long copy. If the message doesn’t fit in two lines, it isn’t a toast.
8. Inconsistent placement. Toasts appearing in random spots break user expectations.

Real-World Examples of Great Toast Design

• Linear: Minimal top-right toasts with clear icons and subtle motion
• Gmail: Bottom-left undo toasts, the gold standard for reversible actions
• Notion: Bottom-center toasts with grouped stacking
• Vercel: Dark, glassmorphic toasts with tight spacing and clean typography
• Stripe Dashboard: Elegant top-right toasts with contextual actions

A Quick Design Checklist

Before shipping any toast component, run through this list:

• Is the message under 10 words?
• Does it have an appropriate icon and color?
• Is the duration between 4 and 10 seconds?
• Can users dismiss it manually?
• Does hover or focus pause the timer?
• Does it work with screen readers?
• Does it respect reduced motion preferences?
• Does it stack cleanly with other toasts?
• Is placement consistent with the rest of the app?

FAQ: Toast Notification Design

How many toasts should I show at once?

Three at maximum. Beyond that, queue them or consolidate into a single grouped notification. Overlapping toasts create visual noise and hide information.

Should toasts be dismissible?

Yes. Even auto-dismissing toasts should include a close button. Some users prefer to clear their screen manually, and accessibility guidelines recommend it.

Can toasts contain buttons or links?

Yes, but keep it to one action. Undo, Retry, or View are common. If you need multiple actions, you probably need a modal or banner instead.

What is the difference between a toast and a snackbar?

They are essentially the same pattern. Snackbar is the term used by Material Design. Toast is more common in the wider web community. Functionally, they are interchangeable.

Should error toasts auto-dismiss?

Generally no. Errors should either stay visible until dismissed or last significantly longer (8 to 10 seconds minimum) so users have time to read and react.

Do toasts work on mobile?

Absolutely, but placement is critical. Position them away from the keyboard, notch, and bottom navigation. Bottom-center with safe-area padding is the safest bet.

Final Thoughts

Great toast notification design is invisible when it needs to be and helpful when it counts. Keep messages short, placement consistent, duration reasonable, and accessibility non-negotiable. Small choices in toasts often reveal how much a team cares about craft, since users may not notice a good toast, but they will always notice a bad one.

The post Toast Notification Design: Best Practices for Non-Intrusive User Feedback first appeared on The Hangline.

In this guide, we break down the modal vs slide-out panel debate with practical examples, a side-by-side comparison, and clear recommendations based on real product scenarios.

Quick Definitions

What is a Modal?

A modal is a dialog box that appears centered above the main content, usually with a dimmed backdrop. It blocks interaction with the rest of the page until the user completes an action or dismisses it. Modals demand attention and are best for short, focused decisions.

What is a Slide-Out Panel?

A slide-out panel (drawer, side sheet, off-canvas panel) slides in from the edge of the screen, typically from the right or left. It overlays the main view but often leaves part of the underlying content visible, keeping the user anchored in context.

Modal vs Slide-Out Panel: Side-by-Side Comparison

When to Use a Modal

Modals interrupt users and demand an action. They work best when the interaction is short, self-contained, and critical to the current flow.

• Confirmations: “Are you sure you want to delete this file?”
• Alerts and warnings: Session timeouts, payment failures.
• Quick forms: Login, subscribe to newsletter, simple invites.
• Focused decisions: Choosing a plan, accepting terms.
• Media previews: Lightbox for images or videos.

Rule of thumb: if the content fits comfortably without scrolling and the user needs to make a decision before continuing, a modal is the right call. There’s a fuller breakdown if you want the detail.

When to Use a Slide-Out Panel

Slide-out panels are less intrusive. They let users reference the underlying page while working with secondary content, which makes them ideal for tasks that need more space or context.

• Detail views: Clicking a row in a table to see full record details.
• Filters and settings: Advanced search, sort, and filter controls.
• Multi-step forms: Creating or editing entities like users, products, or tickets.
• Contextual help or comments: Chat panels, activity logs, notifications.
• Shopping carts: Reviewing items without leaving the product page.

Rule of thumb: if users may need to reference the main view, or if the content is long and structured, a slide-out panel keeps them productive.

UX Pros and Cons

Modal Pros

• Immediate focus, hard to ignore.
• Simple mental model, familiar across the web.
• Fast to build and works well for one-off actions.

Modal Cons

• Interrupts flow and can feel aggressive.
• Poor for long content, forces awkward internal scrolling.
• Accidental dismissal can wipe out user input.
• Stacked modals (modal on modal) are a UX nightmare.

Slide-Out Panel Pros

• Preserves context, users see where they came from.
• Handles more content gracefully with vertical scroll.
• Feels native on mobile, similar to app drawers and bottom sheets.
• Great for repeated actions across list views.

Slide-Out Panel Cons

• Less attention-grabbing, easy to miss for urgent info.
• Takes more engineering effort, especially for responsive behavior.
• Can conflict with existing side navigation.

Mobile Considerations

Mobile is where the modal vs slide-out panel decision gets sharper. Small screens change the rules. This guide goes deeper on it.

1. Modals on mobile often need to become fullscreen sheets to remain usable. A centered modal with a tiny close button is a recipe for missed taps.
2. Slide-out panels on mobile commonly transform into bottom sheets or fullscreen drawers, which map naturally to native app patterns users already know.
3. Gestures matter. Swipe-to-dismiss on drawers and bottom sheets feels intuitive. Modals rarely support gestures well.
4. Keyboard behavior. When a mobile keyboard opens inside a modal, layouts often break. Slide-out panels adapt more gracefully.

Real-World Examples

Modal Examples

• Delete confirmations in Gmail, Notion, and most SaaS dashboards.
• Login and signup dialogs on marketing pages.
• Image lightboxes in galleries and social feeds.

Slide-Out Panel Examples

• Stripe Dashboard uses side panels for viewing payment and customer details.
• Linear and Asana open task details in a right-side drawer.
• Shopify Admin uses drawers for product editing and filters.
• E-commerce carts like Amazon and most Shopify themes slide in from the right.

A Simple Decision Framework

Ask yourself these five questions before choosing:

1. Is the action urgent or destructive? Yes, use a modal.
2. Does the user need to reference the underlying page? Yes, use a slide-out panel.
3. Is the content longer than one screen? Use a slide-out panel.
4. Will users perform this action repeatedly across a list? Slide-out panels win.
5. Is this a one-time, short decision? A modal is fine.

Common Mistakes to Avoid

• Stacking modals: Never open a modal from inside another modal.
• Cramming forms into modals: If it scrolls, it belongs in a panel or a full page.
• Silent dismissal: Closing on backdrop click without warning when a form has unsaved data.
• Hiding critical actions: Buttons stuck below the fold inside a modal or panel.
• Ignoring accessibility: Both patterns need focus trapping, ESC to close, and proper ARIA roles.

The Verdict

There is no universal winner in the modal vs slide-out panel debate. Modals are the right choice for short, interruptive, decision-driven moments. Slide-out panels are better for contextual, content-rich, task-oriented flows. Modern product design tends to favor slide-out panels for anything beyond a simple confirmation, because they respect user context and scale better to complex workflows.

If your product involves detail views, editing, filtering, or repeated actions across lists, default to slide-out panels. Reserve modals for the moments when you truly need to stop the user in their tracks.

FAQ

Is a slide-out panel the same as a drawer?

Yes. Drawer, side sheet, off-canvas panel, and slide-out panel all refer to the same pattern: a container that slides in from a screen edge.

Can I use both patterns in the same product?

Absolutely. Most mature products use modals for confirmations and alerts, and slide-out panels for detail views and editing flows. Consistency within each use case is what matters.

What about bottom sheets on mobile?

Bottom sheets are essentially slide-out panels that enter from the bottom of the screen. They are ideal for mobile because they are within thumb reach and support swipe gestures naturally. Source: https://developer.adobe.com.

Should modals be dismissible by clicking the backdrop?

Only if there is no risk of data loss. For forms or multi-step content, require an explicit close action or show a confirmation before discarding changes.

Are modals bad for SEO?

Modals themselves are not bad for SEO, but content hidden inside modals that only loads on interaction may not be indexed. Keep critical content on the page itself.

How wide should a slide-out panel be?

On desktop, common widths range from 400px to 720px depending on content density. On mobile, panels typically go fullscreen or take 90 to 100 percent of the viewport width.

The post Modal vs Slide-Out Panel: Which Is Better for Displaying Secondary Content? first appeared on The Hangline.

In this guide, we break down the patterns, copywriting tricks, and illustration principles that separate forgettable blank screens from empty states people actually enjoy.

What Is an Empty State in UX Design?

An empty state (sometimes called a zero state or blank state) is the UI a user sees when there is no content to display. This can happen for many reasons: a first-time user has not created anything yet, a search returned no results, a filter is too narrow, or an error prevented data from loading.

Instead of treating these screens as failures, treat them as onboarding real estate. Every empty state should answer three questions:

1. What is this screen supposed to show?
2. Why is it empty right now?
3. What can I do next?

The 3 Main Types of Empty States

1. First-Use Empty States

This is the empty state a new user sees the first time they open a feature. It sets expectations and drives activation. Slack, Notion, and Linear all invest heavily here because that first screen shapes retention.

Goals:

• Explain the value of the feature in one sentence
• Provide a single, obvious call to action
• Optionally show a preview or sample data

2. No-Results Empty States

Triggered when a search or filter returns nothing. This is where users most often bounce, so the copy needs to reassure and redirect.

Goals:

• Confirm the search or filter was applied correctly
• Suggest alternative queries or a way to clear filters
• Offer a recovery path (browse categories, popular items, contact support)

3. Error or System Empty States

Something broke: no internet, a failed API call, or expired permissions. Users need clarity, not jargon.

Goals:

• Explain what happened in human language
• Offer a retry action
• Preserve trust with honest tone (avoid blame)

Empty State Patterns at a Glance

Real Examples from Popular Apps

Dropbox: First-Use Simplicity

Dropbox greets new users with a big illustration, a one-line explanation, and a single upload button. There is nothing to distract from the primary action.

Notion: Templates as Empty States

Instead of a blank page, Notion offers templates and AI prompts. The empty state doubles as a discovery engine for features users might not know exist.

Airbnb: Helpful No-Results

When a search returns no matches, Airbnb suggests nearby locations, flexible dates, and the option to remove filters. The user is never stuck.

Todoist: Rewarding Inbox Zero

Complete all your tasks and Todoist shows a delightful illustration and a motivational message. It turns a routine moment into a small dopamine hit that drives habit loops. There’s a good explainer over at nngroup.com.

Linear: Contextual Empty States

Linear tailors each empty state to the specific view (issues, cycles, projects) with keyboard shortcuts front and center, reinforcing the product’s power-user identity.

Copywriting Tips for Empty States

• Lead with the benefit, not the technical state. “Your first project starts here” beats “No data available”.
• Use active verbs in buttons: Create, Invite, Import, Explore.
• Keep it under 20 words for the main message. Long paragraphs kill momentum.
• Match your brand voice. A B2B analytics tool should not sound like a meme, and a consumer app should not sound like a legal notice.
• Never blame the user. Replace “You have not created anything” with “Ready to create your first one?”.

Using Illustrations the Right Way

Illustrations make empty states feel human, but they can also become clutter if misused. Follow these rules:

• Purpose over decoration: the visual should hint at the action, not just fill space.
• Consistent style: match the illustration system across all empty states in your product.
• Neutral or optimistic tone: avoid sad mascots or crying folders. They amplify frustration.
• Accessible contrast: illustrations should never carry critical meaning alone. Pair them with text.
• Lightweight assets: SVG or optimized PNG. A slow empty state is worse than no illustration.

A Checklist for Designing Great Empty States

1. Identify every screen where content can be absent
2. Classify each as first-use, no-results, or error
3. Write the message before designing the visual
4. Define one primary action and one optional secondary action
5. Test copy with real users, not just stakeholders
6. Measure conversion from empty state to first meaningful action
7. Iterate based on drop-off data

Common Mistakes to Avoid

• Showing a generic “No data” label with no context or action
• Using the same empty state across totally different features
• Overloading the screen with three or four CTAs
• Forgetting the error variant (users always find network issues)
• Skipping empty states in design handoff, leaving developers to improvise

Frequently Asked Questions

What is an empty state in design?

An empty state is a screen or UI area shown when there is no content to display. It communicates system status and guides users toward the next useful action. This guide goes deeper on it.

What is an example of an empty state?

A new Dropbox account showing an upload prompt, a Gmail inbox saying “You are all caught up”, or a search result page saying “No matches, try different keywords” are all empty states.

What is the difference between zero state and empty state?

The terms are often used interchangeably. Some designers use “zero state” specifically for the first-use scenario, and “empty state” as the broader umbrella covering first-use, no-results, and error states.

How many empty states should a product have?

As many as it has content surfaces. Every list, dashboard, feed, or search result should have a dedicated empty state. Reusing a single generic one is a missed opportunity.

Should I use illustrations in every empty state?

Not necessarily. Dense B2B tools often work better with text-only empty states that emphasize speed and clarity. Consumer apps benefit more from illustration. Match the tone to your users.

Final Thoughts

Great empty state design is not about filling space, it is about removing friction. Every blank screen is a conversation with your user. Make it warm, make it useful, and make it point to a clear next step. The apps we admire most treat empty states as first-class citizens of their design system, and it shows in their activation and retention numbers.

Audit your product this week. Find every empty screen, classify it, and rewrite the message. You might discover that your best onboarding flow was hiding in plain sight.

The post How to Design an Empty State That Guides Users: UX Patterns and Examples first appeared on The Hangline.

What a Tooltip Actually Is (and What It Isn’t)

A tooltip is a small, contextual message that appears when a user hovers, focuses, or taps a UI element. It’s meant to clarify, not to teach, warn, or replace proper labels.

• Good use: Labelling an icon-only button (a gear icon showing “Settings”).
• Good use: Explaining a technical term in a form field (“CVV: the 3-digit code on the back of your card”).
• Bad use: Hiding pricing details, error messages, or legal disclaimers behind a hover.

If the information is essential to complete a task, it does not belong in a tooltip. Put it directly in the interface.

When to Use a Tooltip (And When Not To)

Use a tooltip when:

1. You need to label an icon-only element that lacks visible text.
2. You want to define a term or acronym that some users may not know.
3. You need to give optional context that helps but isn’t required.
4. You’re showing a keyboard shortcut (like Figma or Notion do).

Skip the tooltip when:

• The content is critical, long, or actionable (use a modal, inline text, or a popover instead).
• The element already has a clear label.
• The tooltip would block another important UI element.
• The user needs to interact with the tooltip content (click links, copy text). Standard tooltips should not contain interactive elements.

Tooltip Positioning Rules

Placement seems trivial but is one of the most common failure points. The tooltip should never cover the element it describes or the content the user is trying to read.

Basic positioning principles

• Default to top or bottom for elements in the middle of the screen.
• Flip automatically when there isn’t enough space (top becomes bottom, left becomes right).
• Point clearly to the trigger element using a small arrow or caret.
• Keep 8 to 12 pixels of distance between the trigger and the tooltip so the arrow is visible.
• Never let the tooltip go off-screen or under a fixed header.

Good vs bad positioning: quick reference

Timing: Delay, Duration, and Dismissal

Tooltips that appear instantly on every hover feel noisy. Tooltips that take 2 seconds to appear feel broken. Get the timing right.

• Show delay: 300 to 500 ms on hover. Immediate on keyboard focus.
• Hide delay: 100 to 200 ms after the pointer leaves, so users can move the cursor smoothly.
• Persistence: Stay visible as long as the trigger is hovered or focused. Do not auto-dismiss on a timer for hover tooltips.
• Dismissal: Users must be able to dismiss with the Escape key.

Writing Great Tooltip Content

The best tooltips read like a well-written label, not a paragraph.

1. Be concise. Aim for 1 to 2 short sentences. Ten words or less is a healthy target for icon labels.
2. Start with the value. “Export as CSV” is better than “Click here to export your data as a CSV file.”
3. Avoid redundancy. Don’t repeat the visible label of the element.
4. Use sentence case, not title case, unless your design system says otherwise.
5. Skip punctuation at the end of short labels. Add periods only for full sentences.

Examples from popular products

• GitHub: Icon tooltips are short and consistent (“Watch”, “Star”, “Fork”). Perfect execution.
• Figma: Tooltips include the keyboard shortcut in a subtle secondary color. A great pattern for power users.
• Google Docs: Toolbar tooltips show the action plus the shortcut, and they appear after a short delay to avoid noise.
• Bad example: E-commerce sites hiding shipping costs or return policies behind a small “i” icon. That’s critical information, it should be visible.

Mobile Tooltip Considerations

Here’s the honest truth: traditional tooltips don’t work on touch devices. There’s no hover. Trying to force them creates bad experiences.

What to do instead on mobile

• Replace hover with tap: A tap on an info icon reveals a tooltip or a small bottom sheet.
• Use inline help text under form fields rather than icons that require a tap.
• Consider bottom sheets or popovers for anything longer than a few words.
• Make the trigger big enough: minimum 44×44 px tap target.
• Dismiss on tap outside the tooltip.

If your desktop design leans heavily on tooltips, plan a different pattern for mobile from day one. Retrofitting is painful.

Accessibility: The Non-Negotiable Rules

Tooltip accessibility is where most implementations fall apart. If keyboard and screen reader users can’t access your tooltips, they’re broken.

Accessibility checklist

1. Keyboard focus triggers the tooltip. Tabbing to the element must show the tooltip, exactly like hovering.
2. Escape dismisses it. Without moving focus.
3. Use proper ARIA: apply role="tooltip" and connect it to the trigger with aria-describedby.
4. Contrast matters: minimum 4.5:1 ratio between text and background.
5. Don’t rely on color alone to convey the tooltip’s purpose.
6. Persistent on hover: users must be able to move the mouse over the tooltip content (useful for people with motor impairments) without it disappearing.
7. No essential info inside: if a screen reader user misses it, they should still be able to complete the task.

Visual Design Guidelines

• Contrast: Dark background with light text works well. Make sure it stands out against the page.
• Size: Keep max width around 200 to 320 px. Longer content probably shouldn’t be a tooltip.
• Typography: 12 to 14 px is standard. Don’t go below 12 px.
• Padding: 8 to 12 px of inner padding keeps things breathable.
• Animation: A subtle fade or scale (150 to 200 ms) feels polished. Avoid bouncy or slow animations.

Common Tooltip Mistakes to Avoid

1. Hiding critical information behind a hover.
2. Putting links or buttons inside a hover tooltip.
3. Forgetting keyboard and screen reader support.
4. Using tooltips on mobile without adapting the pattern.
5. Writing paragraphs instead of short labels.
6. Poor positioning that covers what the user is looking at.
7. No visible indicator that a tooltip exists (undiscoverable).
8. Inconsistent style across the product.

Quick Tooltip Design Checklist

Final Thoughts

Tooltips are a supporting player, not the main act. The best tooltip design best practices come down to one principle: use them only when they genuinely help, and never rely on them for anything important. Keep them short, accessible, well-positioned, and mobile-aware, and your interface will feel more polished without becoming cluttered.

FAQ

What’s the difference between a tooltip and a popover?

A tooltip is a small, non-interactive label triggered by hover or focus. A popover is larger, can contain interactive elements like buttons or links, and is usually triggered by a click.

Should tooltips appear on click or on hover?

On desktop, use hover with keyboard focus support. On mobile or when the tooltip contains interactive content, use click or tap and consider using a popover instead.

How long should a tooltip be?

Aim for 1 to 2 short sentences, ideally under 10 words for icon labels. If you need more space, use a different pattern like inline help or a popover.

Are tooltips accessible by default?

No. You need to add proper ARIA attributes (role="tooltip", aria-describedby), ensure keyboard focus triggers them, allow Escape to dismiss, and meet contrast requirements. Native HTML title attributes are not fully accessible.

Can I use tooltips on a mobile website?

Traditional hover tooltips don’t work on touch. Replace them with tap-triggered tooltips, inline help text, or bottom sheets. Never rely on hover for anything critical on mobile.

What’s the ideal delay before a tooltip appears?

Between 300 and 500 ms on hover feels natural. On keyboard focus, tooltips should appear immediately.

The post Tooltip Design Best Practices: How to Create Helpful Tooltips Without Cluttering Your UI first appeared on The Hangline.

This guide gives you clear, practical rules for choosing between the three most common single and multi selection inputs, based on the number of options, the user context, and the goal of the form.

The Core Difference in One Sentence

Radio buttons let users pick one option from a set, checkboxes let users pick zero, one, or many, and dropdowns hide options behind a click to save space when the list is long or secondary.

That is the foundation, but the real skill is knowing which one fits the moment. Let’s break it down.

Radio Buttons: For Mutually Exclusive Choices

Radio buttons should be your default when the answer is a single value from a small set of visible options. They keep every choice on screen, which lowers cognitive load and helps users compare options side by side.

When to Use Radio Buttons

• You have between 2 and 6 mutually exclusive options
• Users benefit from seeing all options at once
• Comparison between options matters (pricing tiers, shipping speed, plan types)
• You expect the answer distribution to be fairly balanced across options

Radio Button Rules of Thumb

1. Always pre-select a safe default when one exists, so users can move faster
2. Never use a single radio button on its own, it must be part of a group
3. Stack options vertically for easier scanning, unless space is tight and labels are very short
4. Make the label clickable, not just the small circle

Checkboxes: For Independent or Multi Select Choices

Checkboxes handle two very different jobs. A single checkbox represents an independent on or off state, like agreeing to terms. A group of checkboxes lets users select several items from a list.

When to Use Checkboxes

• Users can select multiple options from a list (filters, feature toggles, interests)
• You need a single yes or no toggle that stands alone
• The answer to a yes or no question is expected to lean heavily one way
• Options are independent from each other

The One Checkbox vs Two Radios Debate

For a binary yes or no question, use two radio buttons if you expect the answer to be roughly evenly split, because it forces a deliberate choice. Use a single checkbox when one answer is clearly the default and the other is the exception, like a newsletter opt in.

Dropdowns: For Long or Secondary Lists

Dropdowns hide their contents until the user clicks, which is both their strength and their weakness. They save screen space, but they add interaction cost and remove the ability to scan options at a glance.

When to Use Dropdowns

• You have 7 or more options and space is limited
• The choice is familiar to users (country, state, month, year)
• The field is secondary and does not need to attract attention
• You want a compact form layout on mobile

When to Avoid Dropdowns

• You have fewer than 6 options, radio buttons will convert better
• Users need to compare choices before selecting
• The choice is important enough that hiding it hurts the decision
• On mobile with only 3 or 4 items, tap targets are better as radios

Quick Decision Table

Visual Standards You Should Not Break

Users have been trained for decades to recognize these controls. Breaking their shape confuses everyone, including your team.

• Radio buttons are round. A filled circle means selected
• Checkboxes are square. A checkmark inside means selected
• Dropdowns show a chevron or arrow on the right side of the field
• Do not restyle radios as squares or checkboxes as circles, even if the brand designer thinks it looks cleaner

Common Mistakes to Avoid

1. Using a dropdown for 3 options. Radios take the same space and require one less click
2. Using checkboxes for a single choice question. This lets users accidentally select several and breaks your data
3. No default on radios when a safe one exists. Users end up doing extra work
4. Auto submitting on radio selection. This is fine for filters, but never for forms where users might want to change their mind
5. Hiding critical decisions in dropdowns. If the choice affects price, plan, or delivery, keep it visible

Accessibility Notes

All three inputs are accessible by default when you use the native HTML elements. A few reminders:

• Group radio buttons and checkboxes inside a fieldset with a legend
• Associate every input with a label using the for attribute
• Ensure keyboard users can tab to the group and use arrow keys to move between radios
• Do not rely on color alone to show the selected state

FAQ

When should I use radio buttons instead of checkboxes?

Use radio buttons when the user must select exactly one option from a group and the choices are mutually exclusive. Use checkboxes when the user can select more than one, or when a single toggle is independent from other fields.

What is the main difference between a radio button and a checkbox?

A radio button belongs to a group where only one can be active at a time. A checkbox is independent and can be checked or unchecked without affecting other checkboxes.

Are dropdowns worse for UX than radio buttons?

For short lists, yes. Dropdowns hide options, add a click, and prevent comparison. For lists of 7 or more familiar items, dropdowns are the more efficient choice because they save space without hurting comprehension.

Should a yes or no question use one checkbox or two radio buttons?

Use two radio buttons when both answers are equally likely and the choice is important. Use a single checkbox when one answer is the obvious default, such as opting into marketing emails.

Can I style radio buttons and checkboxes to look the same?

You can style them, but keep the shape difference. Round for radio, square for checkbox. This visual code is one of the few UI conventions that is nearly universal, and breaking it costs more than any aesthetic gain.

What about toggle switches?

Toggle switches are best for settings that take effect immediately, like turning notifications on or off. Inside a form that requires a submit action, a checkbox is usually the better fit.

Final Takeaway

Choosing between radio buttons, checkboxes, and dropdowns is not about personal preference, it is about matching the control to the task. Count the options, ask whether users need to see them all, decide if multiple selections are allowed, and the answer becomes obvious. Get this right and your forms will feel faster, clearer, and more trustworthy, without a single line of extra code.

The post Radio Buttons vs Checkboxes vs Dropdowns: Which Form Input to Use When first appeared on The Hangline.

In this guide, we’ll break down exactly how to structure an FAQ page using accordions, search functionality, and smart categorization. We’ll also look at what leading SaaS and e-commerce sites are doing in 2026 to turn their FAQ pages into genuine self-service tools.

Why FAQ Page Design Matters More Than You Think

A poorly designed FAQ page doesn’t just frustrate users, it actively costs you money. Every question a visitor can’t answer themselves becomes a support ticket, a lost sale, or worse, a negative review.

According to recent CX benchmarks, companies with well-structured self-service resources reduce support volume by 30 to 50 percent. That’s not a marginal gain, that’s a game-changer for support teams and conversion rates.

What a Great FAQ Page Actually Does

• Deflects repetitive support requests before they hit your team
• Removes purchase objections in real time
• Improves SEO through long-tail keyword coverage
• Builds trust by showing transparency
• Speeds up onboarding for new users or customers

The Core Elements of an Effective FAQ Page Design

Before we get into examples, let’s cover the non-negotiable building blocks. If your FAQ page is missing any of these, you’re leaving performance on the table.

Step-by-Step: How to Design an FAQ Page That Works

1. Start With Real Data, Not Guesses

The biggest mistake teams make is writing FAQs based on what they think customers ask. Instead, pull from actual sources:

1. Export your last 90 days of support tickets and cluster them by topic
2. Review live chat transcripts for recurring themes
3. Check your site search queries for questions that returned no results
4. Look at Google Search Console for question-based queries hitting your site
5. Ask your sales team what objections come up during demos

You should end up with a prioritized list of 20 to 40 real questions. Skip the fluff like “Why choose us?” unless it’s genuinely asked.

2. Group Questions Into Logical Categories

Once you have your list, cluster questions into 4 to 7 categories. Any more than that and users get overwhelmed. Common category structures include:

For SaaS products:

• Getting Started
• Billing & Plans
• Features & Integrations
• Security & Privacy
• Troubleshooting

For e-commerce:

• Orders & Shipping
• Returns & Refunds
• Product Information
• Payment & Discounts
• Account Management

3. Use Accordions, Not Long Scrolling Pages

Accordions are the gold standard for FAQ layout because they let users scan headlines and expand only what’s relevant. This solves the biggest UX problem: information overload.

A few accordion best practices:

• Keep questions closed by default so users see all options at once
• Allow multiple accordions to be open simultaneously
• Use a clear visual indicator (plus/minus or chevron) that changes on expand
• Include smooth animation but keep it under 300ms
• Make the entire question row clickable, not just the icon

4. Add a Real Search Bar (Not Just for Show)

If your FAQ has more than 15 questions, search is non-negotiable. But bad search is worse than no search. Make sure yours:

• Returns results as the user types (autocomplete)
• Handles typos and partial matches
• Shows results ranked by relevance, not alphabetically
• Displays a helpful message when nothing matches, with a link to contact support

5. Write Answers Like a Human

Corporate speak kills FAQ pages. Follow these writing rules:

• Answer in the first sentence, then expand if needed
• Keep answers under 100 words when possible
• Use bullet points for multi-step answers
• Link to detailed help articles for complex topics
• Avoid jargon unless your audience uses it daily

Real Examples: What Top Sites Are Doing Right

SaaS Example: Notion

Notion’s FAQ hub combines a prominent search bar with visual category cards. Each category leads to a dedicated page with accordion-style questions. What makes it work is the context-aware suggestions, when you land from a pricing page, the FAQ prioritizes billing questions.

SaaS Example: Linear

Linear keeps things minimal with a single-column accordion layout. No categories, just a smart order based on frequency. This works because their audience is technical and comfortable scanning. Lesson: match your layout complexity to your audience’s patience.

E-commerce Example: Allbirds

Allbirds separates FAQs into tabs (Shipping, Returns, Product Care) with accordions inside each tab. They also include a persistent “Still need help?” CTA at the bottom of every accordion group, catching users right when frustration might build.

E-commerce Example: Glossier

Glossier uses a two-column layout where the left side is category navigation and the right side displays expandable questions. Their answers are conversational and often include product images or short videos for demonstrations like “How do I apply this?”

Mobile FAQ Design: The Often Ignored Priority

Over 60% of FAQ page traffic now comes from mobile devices. Yet most FAQ designs are built desktop-first. Here’s how to fix that:

• Stack categories vertically instead of using tabs
• Make tap targets at least 44px tall
• Keep the search bar sticky at the top of the viewport
• Ensure accordion animations don’t push content off-screen
• Use system fonts and larger base sizes (16px minimum)

SEO Tips for FAQ Pages

An FAQ page can be a serious SEO asset if you build it right. Focus on these areas:

1. Use FAQPage schema markup so questions can appear as rich results in Google
2. Match question phrasing to real search queries using tools like AnswerThePublic or Search Console
3. Give each major question its own URL fragment so you can link directly to specific answers
4. Update quarterly based on new support trends and search data
5. Interlink from FAQ answers to relevant product pages, blog posts, and help articles

Common FAQ Page Design Mistakes to Avoid

Measuring FAQ Page Success

Design without measurement is guesswork. Track these metrics monthly:

• Support ticket volume for topics covered in your FAQ
• FAQ page bounce rate (lower is better, but context matters)
• Time on page combined with accordion expansions
• Internal search queries with zero results
• “Was this helpful?” vote ratios per question
• Contact form submissions originating from the FAQ page

FAQ About FAQ Page Design

What should a FAQ page include?

At minimum: a search bar, categorized questions, accordion-style answers, and a contact fallback for unanswered questions. Ideally add feedback voting, related questions, and schema markup for SEO.

How many questions should be on a FAQ page?

Between 15 and 40 questions works for most businesses. If you have more, split them into a dedicated help center with multiple pages instead of cramming everything into one page.

Are FAQ pages good for SEO?

Yes, when done right. FAQ pages naturally target long-tail question-based queries and can earn rich results in Google when marked up with FAQPage schema. They also improve dwell time and internal linking structure.

Should FAQ questions be open or closed by default?

Closed by default. This lets users scan all available topics quickly and choose what to expand. Opening everything defeats the purpose of an accordion layout.

What’s the difference between an FAQ page and a help center?

An FAQ page handles quick, common questions in one place. A help center is a larger structured resource with articles, tutorials, and search across multiple topics. Most companies benefit from both, with the FAQ acting as an entry point.

Final Thoughts

A great FAQ page design isn’t about looking pretty, it’s about solving problems fast. Start with real customer data, structure content with clear categories and accordions, make search work properly, and measure everything.

The companies winning at self-service in 2026 treat their FAQ pages as living products, not static footers. Review yours quarterly, update it based on support trends, and you’ll see support tickets drop while conversion rates climb.

The post How to Design an FAQ Page That Reduces Support Requests: Layout and UX Tips first appeared on The Hangline.

In this guide, we break down the three main breadcrumb navigation design patterns, show real examples, and help you decide when to use them, and when to skip them entirely.

What Is Breadcrumb Navigation?

Breadcrumbs are a secondary navigation element that displays the user’s current location within a website or app hierarchy. The name comes from the Hansel and Gretel fairy tale, where breadcrumbs were dropped to mark a path back home.

Typically displayed horizontally near the top of a page, breadcrumbs look something like this:

Home > Electronics > Laptops > Gaming Laptops

They are not meant to replace primary navigation. Instead, they complement it by giving users context and an easy way to step back up the hierarchy.

The 3 Types of Breadcrumb Navigation

Not all breadcrumbs work the same way. Choosing the right pattern depends on your site structure and user goals.

1. Location-Based Breadcrumbs

These show where the user is in the site’s hierarchy. They reflect the structure of the website, not the user’s browsing journey.

Example: Home > Men > Shoes > Sneakers

Best for: Multi-level websites such as e-commerce stores, documentation sites, and large content platforms.

Real-world example: Amazon, IKEA, and BBC News all rely on location-based breadcrumbs to help users navigate deep category trees.

2. Attribute-Based Breadcrumbs

These display the attributes or filters the user has selected to reach the current page. They are common on product listing pages where multiple filters are applied.

Example: Home > Women > Dresses > Red > Size M

Best for: Faceted search results, large catalogs, and filtered product pages.

Real-world example: Zappos and Newegg use attribute-based breadcrumbs that let users remove individual filters and refine their browsing.

3. Path-Based (History) Breadcrumbs

These show the exact path the user took to arrive at the current page, similar to a browser’s back history.

Example: Dashboard > Reports > Q2 2026 > Export

Best for: Web applications and multi-step workflows where users need to revisit specific steps.

Warning: Path-based breadcrumbs are often discouraged on standard websites because they duplicate the browser’s back button and can feel redundant. They shine in SaaS dashboards and complex tools.

Comparison Table: Which Breadcrumb Pattern to Use

When Breadcrumbs Improve UX

Breadcrumbs genuinely help users in these situations:

• Deep site hierarchies with 3 or more levels of navigation
• E-commerce sites where users browse across categories and want to backtrack quickly
• Knowledge bases and documentation where context matters
• SEO benefits, since Google displays breadcrumb trails in search results when properly marked up with schema.org
• Mobile experiences, where they save screen space compared to mega menus

When Breadcrumbs Add Clutter

Sometimes breadcrumbs do more harm than good. Skip them when:

• Your site has a flat hierarchy with only one or two levels
• The primary navigation already makes the page location obvious
• You’re designing a single-page application or landing page
• The breadcrumb would simply duplicate the page title or H1
• Users primarily arrive via direct links and never browse the hierarchy

11 Design Best Practices for Breadcrumb Navigation

1. Place them near the top of the page, below the main navigation but above the page title.
2. Use clear separators such as >, /, or ›. Avoid ambiguous symbols.
3. Make every level clickable except the current page.
4. Don’t link the current page, since it confuses users.
5. Keep them small and visually secondary. They should not compete with primary navigation.
6. Use real category names, not abbreviations or internal jargon.
7. Be consistent: same position, same style across the entire site.
8. Implement schema markup (BreadcrumbList) for SEO benefits.
9. Truncate gracefully on mobile by collapsing middle levels with an ellipsis.
10. Test with real users before rolling out a redesign.
11. Don’t use breadcrumbs as the only navigation. They support, not replace, your main menu.

Real Website Examples Worth Studying

Apple Support

Clean, minimal location-based breadcrumbs that reinforce hierarchy without dominating the page.

BBC News

Uses simple text breadcrumbs to help readers navigate between news categories and sub-topics.

Etsy

Combines location and attribute breadcrumbs, letting users remove filters individually.

GOV.UK

The UK government design system shows how accessible, no-frills breadcrumbs can serve millions of users.

Accessibility Considerations

A breadcrumb component is only good if everyone can use it. Make sure to:

• Wrap the breadcrumb in a <nav> element with aria-label=”Breadcrumb”
• Use an ordered list (<ol>) for semantic structure
• Mark the current page with aria-current=”page”
• Ensure sufficient color contrast between text and background
• Make separators decorative with aria-hidden=”true” so screen readers skip them

Mobile Breadcrumb Patterns in 2026

On smaller screens, full breadcrumb trails often break the layout. Modern designs in 2026 are leaning toward:

• Back-only breadcrumbs: a single “< Back to Category” link instead of the full trail
• Collapsed trails with an ellipsis revealing intermediate levels on tap
• Horizontal scrolling breadcrumbs for content-rich sites

Frequently Asked Questions

What is breadcrumb style navigation?

It’s a secondary navigation pattern that displays a user’s location within a website hierarchy, usually as a horizontal trail of links separated by symbols like > or /.

Why is it called breadcrumb navigation?

The term comes from the Hansel and Gretel fairy tale, where the children dropped breadcrumbs to find their way back home. The web pattern works the same way: it shows users the path back.

Are breadcrumbs good for SEO?

Yes. When implemented with BreadcrumbList structured data, Google can display breadcrumb trails in search results instead of plain URLs, which often improves click-through rates.

Should I use breadcrumbs on a small website?

Probably not. If your site has fewer than three navigation levels, breadcrumbs add visual noise without offering real value.

Can breadcrumbs replace the main navigation?

No. Breadcrumbs are a secondary aid. They support orientation, but users still need a primary menu to discover content they haven’t visited yet.

Final Thoughts

Great breadcrumb navigation design is invisible: users feel oriented without consciously noticing the trail. Choose the right pattern (location, attribute, or path), follow accessibility best practices, and don’t force breadcrumbs onto sites that don’t need them. When in doubt, test with real users. The smallest navigation element on your page can quietly become one of the most useful.

The post Breadcrumb Navigation Design: Best Practices and Examples for Better UX first appeared on The Hangline.

Cards are everywhere. From Stripe’s dashboard to Shopify product grids and Medium article previews, the card UI design pattern has become the backbone of modern web and mobile interfaces. But while cards look simple, designing them well is harder than it seems. Bad spacing, weak hierarchy or clumsy hover states can quickly turn a clean layout into visual noise.

In this guide, we break down what makes a great card, with real examples from SaaS, e-commerce and editorial sites, plus clear dos and don’ts you can apply today.

What Is a Card in UI Design?

A card is a self-contained, flexible container that groups related information and actions about a single subject. Think of it as a digital playing card: scannable, tappable and easy to rearrange in a grid. Cards work because they chunk content into digestible units, which helps users scan faster and act with confidence.

You’ll typically find cards used for:

• Product listings on e-commerce sites (Amazon, Shopify stores)
• Dashboard widgets in SaaS apps (Stripe, Linear, Notion)
• Article previews on blogs and news sites (Medium, The Verge)
• Profile and contact tiles in social or CRM tools
• Pricing tables on landing pages

The 12 Best Practices for Card UI Design

1. Establish a Clear Content Hierarchy

Every card should answer one question first: what is this? Make the primary element (a product name, article title or metric) the most prominent. Then layer in supporting info like price, author or date.

A solid hierarchy follows this order:

1. Visual anchor (image, icon or illustration)
2. Title or primary value
3. Supporting metadata
4. Description or snippet
5. Call to action

Example: Airbnb listing cards lead with the photo, then the location, then price, then rating. Each element earns its place.

2. Use Generous and Consistent Spacing

Padding inside the card matters as much as the gap between cards. Cramped cards feel cheap; airy cards feel premium.

3. Keep Card Dimensions Predictable

Variable heights in a grid break the visual rhythm. Either constrain content length (truncate with ellipsis) or align cards using CSS grid with equal row heights. Predictability helps the eye scan rows without re-anchoring.

4. Design Meaningful Hover and Focus States

A card should react when users interact with it. Subtle is better than dramatic.

• Do: Lift the card with a soft shadow (box-shadow blur 12 to 24px) and a 2 to 4px translate-Y on hover
• Do: Add a visible focus ring for keyboard users (accessibility matters)
• Don’t: Animate every element inside the card at once. It feels chaotic
• Don’t: Rely only on color change. Some users won’t perceive it

5. Choose the Right Card Style for the Context

Not all cards need a heavy shadow and border. Match the style to the surrounding UI.

6. Make the Entire Card Clickable When Possible

If the card represents one entity (a product, an article), wrap it in a single link. Don’t force users to aim for a tiny “Read more” button. Just make sure secondary actions inside (like a bookmark icon) use proper event handling so they don’t trigger the parent link.

7. Use Images and Media Intentionally

Visuals are the first thing users see. A few rules:

• Maintain a consistent aspect ratio (16:9, 4:3 or 1:1) across the grid
• Use lazy loading for image-heavy pages
• Always include a fallback or skeleton state during loading
• Avoid stock-photo overload, especially in B2B SaaS contexts

8. Limit Actions Per Card

One primary action per card is the gold standard. Add at most one or two secondary actions (like “Save” or a kebab menu). More than that and you’re building a toolbar, not a card.

9. Respect Typography Scale

Use no more than three font sizes inside a card. A typical scale:

• Title: 16 to 20px, semibold
• Body: 14px, regular
• Metadata: 12px, regular, muted color

10. Design for Empty, Loading and Error States

A card grid isn’t done until you’ve designed what happens when data is missing. Use skeleton loaders that mirror the card structure, not generic spinners. Empty states should explain why and offer a next step.

11. Optimize for Mobile First

On mobile, cards usually stack to a single column. Test your card at 360px width. Watch for:

• Touch targets at least 44x44px
• Truncated titles still readable
• Images that don’t dominate the viewport

12. Test for Accessibility

Ensure color contrast meets WCAG AA (4.5:1 for text). Use semantic HTML: an <article> tag often makes more sense than a <div>. Keyboard users should be able to tab to each card and trigger its primary action with Enter.

Real Examples Across Industries

SaaS: Linear’s Issue Cards

Linear uses dense, outlined cards with clear status indicators. The title is bold, metadata sits on a single row with icons, and hover reveals quick actions. There’s almost no decoration, which fits the productivity context.

E-commerce: Allbirds Product Cards

Allbirds uses large square product images, generous white space, a clear product name, color swatches and a single price. There’s no button, the whole card is the link. Hover swaps the image to a second angle, a subtle but effective trick.

Blog: Medium Article Cards

Medium pairs a small thumbnail with a strong title, author, reading time and claps count. The hierarchy is text-first because the value is the writing, not the image. It’s a great example of matching card design to content type.

Common Card UI Mistakes to Avoid

Quick Checklist Before Shipping Your Cards

• Hierarchy reads in under 2 seconds
• Spacing is consistent across breakpoints
• Hover, focus and active states are defined
• Empty, loading and error states exist
• Color contrast passes WCAG AA
• Touch targets are at least 44px on mobile
• Only one primary action per card
• Cards align to the same baseline grid

FAQ

What is the ideal card size in UI design?

There’s no universal size, but most product cards fall between 280px and 360px wide on desktop, with internal padding of 16 to 24px. The right size depends on your grid and content density.

Should cards have rounded corners?

Rounded corners (8 to 16px radius) feel friendlier and more modern. Sharp corners can work for editorial or enterprise UIs that want a more serious tone. Stay consistent across the product.

How many cards should appear per row?

On desktop, 3 to 4 cards per row is the sweet spot for product grids. Dashboards often use 2 to 3 larger cards. On tablet, drop to 2. On mobile, stack to 1.

Are cards still a modern design pattern in 2026?

Yes. Cards remain one of the most flexible and accessible patterns for grouping content. What’s evolving is the styling: flatter shadows, larger radii, more whitespace and stronger typography rather than heavy decoration.

What’s the difference between a card and a tile?

The terms are often interchangeable, but tiles tend to be more uniform and grid-locked (think Windows Start menu), while cards are more content-driven and varied in height. Cards usually carry more textual information.

Final Thoughts

Great card UI design isn’t about visual flair. It’s about clarity, rhythm and giving users exactly the information they need to make a decision. Start with hierarchy, respect spacing, design every state and resist the urge to add one more button. Do that consistently and your interface will feel polished, no matter the industry.

The post Card UI Design Best Practices: How to Create Cards That Improve UX first appeared on The Hangline.

What’s the Real Difference Between a Skeleton Screen and a Spinner?

Both are loading indicators, but they communicate very different things to the user.

• Loading spinner (throbber): A rotating animation that tells the user something is happening, without indicating what or how long it will take.
• Skeleton screen: A static or shimmering placeholder that mimics the structure of the final UI, giving the user a preview of where text, images, and buttons will appear.

The key insight: a spinner draws attention to the waiting itself, while a skeleton screen draws attention to the content that’s about to appear. That shift in focus is what reduces perceived wait time.

Skeleton Screen vs Spinner: Quick Comparison

When Skeleton Screens Win

Skeleton screens work best when you can predict the shape of the incoming content. They set expectations and make the transition feel seamless.

Real UI examples

• Social feeds (LinkedIn, Facebook): Gray cards mimic post structure while data streams in.
• E-commerce product grids: Placeholder tiles maintain layout stability, preventing jarring shifts when images load.
• SaaS dashboards: Skeleton widgets keep the user oriented while metrics fetch from multiple endpoints.
• Article pages (Medium-style): Lines of varying width simulate paragraphs and headings.

Why they work

1. They reduce cumulative layout shift (CLS), which Google rewards in Core Web Vitals.
2. They give a sense of progress even without a percentage indicator.
3. They shift the user’s mental model from “waiting” to “reading is about to happen”.

When Loading Spinners Still Make Sense

Despite their bad press, spinners are not dead. They are still the right pick in specific scenarios.

• Short async actions under 1 second: A skeleton would flash and feel buggy. A small inline spinner is cleaner.
• Form submissions and authentication: A button spinner replacing the label confirms the click was registered.
• Unknown or highly variable durations: Generating an AI response, processing a payment, or exporting a file. There is no predictable structure to mimic.
• Background actions: Saving a draft, syncing data. A subtle spinner in a toolbar is unobtrusive.

Pro tip: If a spinner runs longer than 4 seconds, swap it for a progress bar or status message. Uncertainty is what damages UX, not the spinner itself.

The Hybrid Approach Most Teams Miss

The best modern interfaces in 2026 do not pick one or the other. They orchestrate both:

1. 0 to 300ms: Show nothing. Users do not perceive delays this short.
2. 300ms to 1s: A subtle spinner if the layout is unknown.
3. 1s to 10s: Skeleton screens that map to the incoming content.
4. 10s and beyond: Progress bar with status text (“Fetching 2 of 5 reports…”).

This staircase approach matches user tolerance with the right pattern and avoids the classic mistake of slapping skeletons everywhere.

Common Mistakes to Avoid

• Skeleton shimmer that loops forever: If the API fails, a perpetual shimmer hides the error. Always pair with a timeout and fallback state.
• Skeletons that do not match the real layout: If the placeholder shows three cards and you render seven, you break trust.
• Spinners on top of skeletons: Redundant and visually noisy. Pick one signal per region.
• Ignoring accessibility: Both patterns need ARIA attributes so assistive tech announces the loading state.
• Using skeletons for sub-second loads: The flash makes the UI feel buggy rather than fast.

Measuring the Impact on Perceived Performance

You do not have to guess. Track these metrics before and after switching loading patterns:

• Task completion time: How long until the user takes the next meaningful action.
• Bounce rate on loading-heavy pages: Skeletons typically reduce abandonment by 10 to 20 percent.
• Self-reported speed (post-task surveys): Ask users to rate how fast the app felt.
• First Contentful Paint (FCP) and Largest Contentful Paint (LCP): Skeletons improve FCP because something visual paints immediately.

FAQ

What is the difference between spinners and skeleton screens?

A spinner is a generic animation showing that something is loading, with no indication of what or how long. A skeleton screen is a content-shaped placeholder that previews the layout of the incoming UI, helping users anticipate what they will see.

When should I use a spinner instead of a skeleton?

Use a spinner for short actions (under 1 second), for unpredictable durations like payment processing, for button-level feedback after a click, or when you cannot reasonably predict the structure of the incoming content.

Do skeleton screens actually make pages load faster?

No. They do not reduce real load time. They reduce perceived load time by giving the brain something structured to anticipate, which feels faster even when the network request is identical.

Are skeleton screens bad for accessibility?

Not inherently, but they require care. Use aria-busy=”true” on the loading container and ensure screen readers announce when content has finished loading. Avoid animations that can trigger motion sensitivity without respecting prefers-reduced-motion.

What about progress bars?

Progress bars are the right choice when you can measure progress (file upload, multi-step export). They are more reassuring than spinners for any wait longer than 10 seconds because they communicate movement toward completion.

Final Takeaway

The skeleton screen vs spinner question does not have one winner. Skeletons reduce perceived wait for content-rich screens with predictable layouts. Spinners remain the cleanest signal for short, atomic, or unpredictable actions. The teams shipping the fastest-feeling products in 2026 are the ones who treat loading states as a design system, not an afterthought, and match each pattern to the wait it is meant to cover.

The post Skeleton Screens vs Loading Spinners: Which Improves Perceived Performance? first appeared on The Hangline.

In this post, we break down what a bottom navigation bar on a mobile website actually delivers, where it falls short, and how it compares to the classic hamburger menu and top navigation.

What Is a Bottom Navigation Bar on a Mobile Website?

A bottom navigation bar is a fixed horizontal menu anchored to the bottom of the screen on mobile devices. It typically displays three to five primary destinations, each represented by an icon and (ideally) a short text label. Tapping an item takes the user to a top-level section of the site.

This pattern, popularized by Google’s Material Design guidelines for apps, is now appearing on mobile websites for ecommerce stores, SaaS dashboards, media outlets, and content platforms.

Why Bottom Navigation Is Trending on Mobile Websites in 2026

Phone screens keep getting bigger. The average smartphone today crosses 6.5 inches diagonally, which makes the top corners of the screen physically hard to reach with a single hand. That is the core reason designers are rethinking where the menu lives.

1. Thumb-Friendly Access

Steven Hoober’s well-known thumb zone research shows that users hold their phones in ways that make the bottom third of the screen the most comfortable area to tap. A bottom nav puts your most important links right where the thumb naturally rests.

2. Lower Cognitive Load

Unlike a hamburger menu, which hides navigation behind an icon, a bottom bar keeps key destinations permanently visible. Users don’t have to remember what is in the menu, they can see it.

3. App-Like Feel

Users now spend hours daily inside apps that use this pattern. Bringing the same interaction to a mobile site reduces the learning curve and increases perceived speed and polish.

4. Better Engagement Metrics

Multiple case studies (including the often-cited Smashing Magazine experiment) have reported that moving primary navigation to the bottom can boost menu interaction rates significantly, sometimes by more than 2x compared to a top hamburger.

The Drawbacks You Should Not Ignore

It is not all upside. Before you redesign your mobile site, weigh these issues:

• Limited space: You can realistically fit only 3 to 5 items. Sites with deep navigation still need a secondary menu somewhere.
• Conflicts with browser UI: Mobile browsers (Safari, Chrome) have their own bottom bars that show and hide on scroll. A fixed bottom nav can overlap or get hidden.
• Vertical screen real estate: A persistent bar eats roughly 56 to 64 pixels of vertical space, which can be costly on content-heavy pages.
• iOS gesture areas: The home indicator on iPhones lives at the bottom and can interfere with tap targets if padding isn’t handled correctly.
• SEO and crawlability: If your bottom bar uses icon-only links without proper labels or ARIA attributes, search engines and screen readers may struggle.

Bottom Nav vs Hamburger Menu vs Top Navigation

Here is a quick comparison to help you decide:

Real Examples of Bottom Navigation on the Mobile Web

Some recognizable names already use a bottom nav on their mobile sites, not just inside their apps:

• Facebook mobile web: A persistent bottom bar with Feed, Marketplace, Groups, Notifications, and Menu.
• Twitter / X mobile web: Bottom navigation that mirrors the app experience.
• YouTube mobile web: Bottom bar with Home, Shorts, Subscriptions, and Library.
• Pinterest mobile web: Bottom navigation for Search, Create, and Notifications.
• Many modern ecommerce PWAs: Home, Search, Cart, Wishlist, Account.

What these examples share is a high-frequency use case. Users return often and switch between core sections constantly. That is exactly when a bottom nav shines.

When Should You Use a Bottom Navigation Bar?

Good Fit

1. Your site has 3 to 5 clearly defined top-level sections.
2. Users come back frequently and switch between sections.
3. You operate an ecommerce store, a social platform, a SaaS dashboard, or a PWA.
4. Conversions depend on quick access to actions like Search, Cart, or Account.

Poor Fit

1. You run a brochure site or blog with deep, hierarchical menus.
2. Your visitors are mostly one-time readers arriving from search.
3. Your content is so immersive that fixed UI elements would be distracting (long-form reading, video).

Best Practices for Implementing Bottom Navigation in 2026

• Limit to 5 items max. More than that and tap targets shrink below the 44 to 48 px minimum.
• Always use labels under icons. Icon-only nav hurts accessibility and recognition.
• Respect the safe area. Use env(safe-area-inset-bottom) in CSS to avoid the iPhone home indicator.
• Auto-hide on scroll down, show on scroll up. This preserves vertical space during reading.
• Highlight the active state clearly. Color, weight, or a filled icon variant.
• Combine with a secondary menu. A Menu or More item can open a full overlay for deeper navigation.
• Test on real devices. Browser chrome behavior differs between Safari, Chrome, and Firefox on mobile.

What About SEO?

A bottom navigation bar is just HTML. Google sees it the same as any other navigation. To stay safe:

• Use real <a href> links, not click handlers on divs.
• Include visible text labels or proper aria-label attributes.
• Make sure the same key links also exist somewhere crawlable (footer, sitemap).
• Avoid heavy JavaScript that delays first input.

Final Verdict: Should You Use a Bottom Navigation Bar?

If your mobile website behaves like an app, with returning users and a small set of critical destinations, a bottom navigation bar is one of the highest-leverage UX upgrades you can make. It is thumb-friendly, visible at all times, and signals a modern, polished product.

If you run a simple content site with broad, shallow navigation, a clean top bar or a well-designed hamburger menu may still serve you better. The pattern is powerful, but it is not universal.

The trend is clear though: in 2026, ignoring the bottom of the screen on mobile means ignoring where users’ thumbs actually live.

FAQ

Is a bottom navigation bar good for SEO?

Yes, as long as it uses standard HTML links with proper labels. Google crawls it like any other navigation menu.

How many items should a bottom nav have?

Between 3 and 5 items. Fewer than 3 looks empty, more than 5 makes tap targets too small.

Should I combine a bottom nav with a hamburger menu?

Often yes. Use the bottom bar for the top 4 destinations and a Menu or More item to open a full overlay for everything else.

Does a bottom nav work on iPhone Safari?

Yes, but you need to account for Safari’s own bottom toolbar and the home indicator using CSS safe-area insets.

Will a bottom navigation bar slow down my site?

Not if it is implemented in clean HTML and CSS. Avoid bloated JavaScript frameworks just to render a simple bar.

Is bottom navigation only for ecommerce and social sites?

No. It works for any site where users perform frequent, repeated navigation between a small number of core sections, including SaaS, news, and PWAs.

The post Bottom Navigation Bar on Mobile Websites: Should You Use It? first appeared on The Hangline.