Pragmatic B2B SaaS Design: The Listing Page

The listing page: definition

A listing page is a screen that displays a collection of items, records, or entities in a structured format, typically as a list, cards, or table.

These items could be contacts, transactions, projects, files, support tickets, or any data relevant to the application’s users. The purpose is simple: give users a clear overview so they can quickly find, understand, and act on the information they need.

If you’ve used any SaaS product, you’ve seen listing pages. They’re the contacts list in a CRM, the projects view in a PM tool, the transactions log in a billing app.

How to design a good listing page

A good listing page combines several elements, some required and some optional depending on context. Use this checklist as your starting point.

Required elements for a SaaS listing page

Every listing page needs these two things:

1. Choose the right content type for your data

• Card row

• Card grid

• Table

The right choice depends on what users need to do with the data. We break down each option below.

2. Add these core elements

• Title

• Content

• Filters

• Pagination

• Sorting

• Empty state

To learn more about each element and when to apply them, read the sections below.

Additional/Optional elements

Depending on your product, you may also need:

• Call to action (if the listing requires a creation or import action)

• Search

• Sections or categories

• Total number of elements

• Skeleton/loader

• Bulk actions

• View toggle (switch between table, card, and list views)

Content types for a good listing

The right content type depends on the data you’re showing. If users need to compare many fields, a table works best. If the content is visual, cards are better. Here’s the breakdown.

Card row

When to use it ✅

• There’s a lot of information in mixed formats (photos, text, CTAs, status badges)

• Users need to read longer text snippets (table rows get too wide)

• You need to avoid horizontal scrolling

• The layout needs to be responsive on mobile

When not to use it ❌

• Users need to compare data across many items side by side

Real-world examples

Expedia uses row cards for search results, combining images, pricing, ratings, and CTAs. Monday.com uses them for project items with mixed content types.

Card grid

When to use it ✅

• Users need a visual overview of the data

• There isn’t too much information per item (compact content that reads well as a whole)

• Horizontal scrolling needs to be avoided

• The layout needs to be responsive on mobile

When not to use it ❌

• Users need to compare data fields across items

Real-world examples

GitHub uses card grids for repository listings. LinkedIn uses them for job recommendations. Both prioritize visual scanning over detailed comparison.

Map listing

When to use it ✅

• Items have a geographic component and location context matters

• UI elements help distinguish categories of items (pins, clusters, color coding)

When not to use it ❌

• Your target audience isn’t comfortable with map interfaces. It’s a complex UI pattern that requires spatial reasoning

  
  

Real-world examples

Trivago and Google Maps both use map listings, but for different purposes: Trivago ties map locations to card results, while Google Maps makes the map itself the primary interface.

Table

When to use it ✅

• Users need to compare elements directly, especially across many records

• Bulk actions are needed (select multiple rows, batch operations)

• Column headers eliminate the need to repeat labels for each item

When not to use it ❌

• The primary audience is on mobile (tables are harder to read horizontally on small screens)

  
  

Design tips for tables

• Right-align numbers, left-align text. This lets users compare values at a glance because place values line up. Headers should match column alignment. Centering content in cells creates “visual wobble” and slows scanning.

• Add row highlighting on hover. This prevents “lost in grid” syndrome in wide tables.

• Consider zebra striping (alternating row backgrounds at 5-10% grey) for tables with many rows. It’s debatable for well-spaced tables, but helpful for dense ones.

• Freeze the first column and header row for tables wider than the viewport.

Real-world examples

Notion is a strong example: its table view supports sorting, filtering, column customization, and formula columns while keeping the interface clean.

Choosing the right content type

Tip: Let users switch views. Many SaaS products (Notion, Airtable, Asana) let users toggle between table, card, and list views. This removes the need to guess which format every user prefers. If your data supports it, consider offering a view toggle.

Types of filters for a SaaS listing

Before designing your filters, keep three principles in mind:

1. Filters must mirror the data. Every filterable field should appear in the list results, and vice versa.

2. Prioritize order. Put the most-used filters first. Not every filter deserves equal visibility.

3. Set a limit. Too many visible filters overwhelm users. Show 5-6 by default, hide the rest behind “Show more” or an accordion.

One more thing: filter state must be visible at all times. Applied filters need a 3-layer feedback system:

1. The original filter controls stay checked/selected

2. Active filters get visual indicators (bold text, count badges like “Status (3)”)

3. A dedicated summary area shows all active filters as removable pills/tags with a “Clear All” option

Missing a “Clear All” button is one of the most common filter complaints in user testing.

Sidebar filters

When to use it ✅

• There are multiple filter groups with many values each (they can be expandable)

• You need scalable space (unlike a horizontal bar, which is limited to page width)

• Users need to see applied filters without losing context

When not to use it ❌

• The number of filters is limited. You’d waste horizontal space

  
  

Real-world examples

Expedia uses sidebar filters with expandable groups, count badges, and a clear filter summary.

Filter area

When to use it ✅

• Filters can be positioned in specific parts of the page (e.g., within different tabs), but it must be clear what they apply to

• Users need to see their filter selections without losing the list context

When not to use it ❌

• Space is limited and there are many filter options

Real-world examples

Toggl combines preset date options with custom calendar selection in its filter area, a pattern that’s consistently praised by users.

Filter button

When to use it ✅

• There are many filters but screen space is limited

• It works well on mobile

When not to use it ❌

• When the button opens a full overlay, users may lose the application context

When using a filter button, you can use three different interactions:

Modal - Best when the focus should be on filters, or when filter logic is complex.

Drawer - Useful when users need to peek at the list while adjusting filters.

Popover - Best when you don’t want users to lose the listing page context.

Filter interactions on mobile

All filter interactions collapse on mobile. Two proven patterns:

• Bottom sheet for quick, lightweight filter sets

• Full modal for complex filters with many options

  
  

Advanced filtering patterns

Saved filters / filter presets. Let users save filter combinations for repeated workflows. This is especially valuable for power users who run the same queries daily.

Search within filters. For filter groups with 100+ values (like tags, assignees, or categories), add a search field inside the filter panel.

Show result counts. Display how many items match as users select filters. This prevents zero-result dead ends, one of the top user complaints.

Sorting & Search in a listing

Sorting and search become essential when there are many results and users can’t find what they need at first glance.

Sorting makes sense when users need to identify extremes or rank items (newest, highest value, most recent activity). Search must clearly communicate its scope: does it search titles only, or full content?

Inside the filtering area

Use when you want everything in one place. Works well for simpler filter setups.

Separated from the filtering area

Best used with tables and card rows. The search field should be prominent and above the list, not hidden inside a filter panel.

Tip: For power users, consider a command palette (Cmd+K) pattern. Products like Linear have shown that a single powerful search bar can sometimes replace dozens of filter dropdowns.

Bulk actions

Bulk actions are essential for any table-based listing where users manage large datasets. They save time and reduce friction.

When to add bulk actions

• Users frequently need to update, delete, or export multiple items

• The listing contains 50+ items

• Common tasks involve applying the same change to many records (status updates, assignments, tags)

Best practices

• Use checkboxes in the first column. Support “select all on this page” and “select all matching items”

• Show a floating action bar when items are selected, displaying the count and available actions

• Add confirmation steps for destructive actions (“Delete 47 items?”)

• Group row-level actions under a single dropdown when there are 5+ actions per row

Dealing with many items

Listing pages usually handle large datasets. Here are two patterns for managing them.

Pagination

When to use it ✅

• Best pick for tabular data in B2B applications

• Provides a clear overview of the total number of elements

• Users have clarity and control over their position in the dataset

• Supports shareable URLs that point to exact pages

When not to use it ❌

• Not easy to use on mobile with touch targets

Design tip: Add a “Go to page X” input for power users who know exactly where they need to be.

Real-world examples

Employment Hero uses pagination with a clear page counter and items-per-page selector.

Load more button

When to use it ✅

• Allows access to the page footer

• The list grows as users need more, keeping all items visible on one page

• Users can return to previously viewed items without changing screens

• More usable on mobile than pagination

When not to use it ❌

• Users need to review the same set of results multiple times (they’d have to click the button repeatedly)

Note on infinite scroll: For B2B SaaS, avoid infinite scroll on data-heavy listing pages. Users lose their position, can’t share specific views, and have no sense of how many items exist. Infinite scroll works for content feeds (social media, news), not for task-oriented work.

Real-world examples

GitHub uses the load more pattern on their repository lists and issue trackers.

Split a listing into sections

Sections help users navigate large listings. They must be immediately visible, not hidden.

With title

When to use it ✅

• Content is limited and sections are clear

When not to use it ❌

• Titles alone may not create enough visual separation

  
  

Tabs

When to use it ✅

• Users need to compare across sections (e.g., “Active” vs “Archived”)

• There’s a limited, fixed number of categories

• Sections represent different states or statuses

When not to use it ❌

• The number of categories will grow over time (tabs don’t scale well past 5-6)

  
  

Accordion

When to use it ✅

• There’s a lot of content to compact into a manageable view

When not to use it ❌

• Data is critical and shouldn’t be hidden. Users might miss collapsed items

  
  

Real-world examples

Asana uses accordions to split project tasks into sections, letting teams collapse completed sprints while keeping active ones visible.

Number of items in a listing

Showing the total count immediately provides useful context. With filters applied, users instantly see how many items match their criteria.

At the top of the list

More suitable when using infinite scroll or a “load more” button. Format: “Showing 1-50 of 2,341 results.”

At the end of a table (like a counter)

More suitable with table layouts and pagination.

Real-world examples

Notion shows the number of elements at the bottom of each database view.

Where to put the main CTA in a listing?

Understanding what the CTA refers to is important, especially when using categories.

Within the header

Best for application-wide actions or wizards. Example: “Create new project” button in the page header.

Within the page

Best when the action involves the items displayed in the listing. Example: “Add contact” button positioned near the contact list.

Real-world examples

Typeform places its “Create new form” CTA prominently in the header, making it accessible regardless of scroll position.

Empty states: dealing with no items

Empty states are strategic moments, not afterthoughts. They help users understand what belongs on the page and what action to take first.

Research shows companies using onboarding checklists in empty states see activation rates of 40%+, compared to the industry average of 25-30%.

Follow this hierarchy for empty state design:

1. Assurance - the system is working correctly

2. Information - what data will appear here

3. Empowerment - how to populate it (clear CTA)

4. Delight - branded moment that builds trust

Basic

Features an illustration, a title, and a short description of the page’s content. Gives users confidence they’re in the right place.

With action

Add a primary CTA when you want to push a specific first action. “Create your first project” or “Import contacts” are more effective than a blank screen.

No results found

When filters or search return zero results, prompt users to adjust their criteria. Show which filters are active and offer a “Clear all filters” shortcut.

Tip: Consider showing starter or dummy content (like Whimsical does) to demonstrate what the page will look like when populated. This reduces cognitive load and helps users understand the interface before they add real data.

Real-world examples

Loading patterns for a listing

Listing pages often require heavy data fetching, especially on slow connections. Loading feedback tells users the system is working.

Skeleton

Skeletons show a wireframe-like preview of the data layout. They reduce perceived loading time because users get a hint of what’s coming.

Loader

A spinner or progress indicator works as a simpler alternative, especially for partial page updates.

Performance note: For datasets over 1,000 rows, consider virtualized scrolling (rendering only visible rows). Tools like AG-Grid handle this out of the box and can scale to millions of records without performance issues.

Accessibility considerations

Listing pages need to be usable by everyone, including users who navigate with keyboards or screen readers.

Key considerations:

• Keyboard navigation. Users should be able to tab through rows, activate sort controls, and trigger actions without a mouse

• ARIA landmarks. Mark the listing region, filter controls, and pagination as distinct landmarks

• Screen reader context. Announce sort state (“Sorted by date, ascending”), filter state (“3 filters active”), and pagination position (“Page 2 of 15”)

• Focus management. After a bulk action or page change, return focus to a logical position rather than the top of the page

• Icon labels. Always pair icons with text labels. Icon-only actions in tables look clean but create friction for daily users and fail accessibility checks

Responsive design for listing pages

Mobile isn’t an afterthought. Here’s how each pattern adapts.

Tables on mobile:

• Show only essential columns. Hide secondary data behind a row expansion

• Consider stacking rows into mini-cards with label-value pairs

• Use horizontal scrolling with a frozen first column as a fallback

• Offer collapsible row details for complex records

Cards on mobile:

• Card grids naturally reflow to single-column layouts

• Card rows stack vertically with minimal adjustment needed

Filters on mobile:

• Collapse all filters into a bottom sheet or full modal

• Show active filter count on the trigger button (“Filters (3)”)

Pagination on mobile:

• Replace page numbers with “Previous / Next” buttons

• Consider “Load more” as a mobile-friendly alternative

  
  

What’s next?

This was a long run, but we hope it helps you design better listing pages for your product. We’ve used these patterns across 80+ SaaS products at Donux, and they consistently lead to interfaces that are easier to use and faster to build.

If you’re working on a listing page or any complex SaaS interface and want a second opinion, book a free expert review. We’ll look at your product and give you specific, actionable feedback.

To be notified when the next playbook drops, subscribe to Product Donuts, our newsletter.

Need help designing your SaaS product? Book a discovery call and let’s talk about what you’re building.

Related reading

• UX Audit: Process, Checklist & Services for B2B SaaS - how to systematically evaluate your product’s usability, including listing pages

• A Practical Guide to the Double Diamond Design Process - the discovery-delivery framework behind these design decisions

• Design System: A Guide to Streamlined, Scalable Design - how to turn listing page patterns into reusable components

• An Introduction to Design Tokens - the building blocks for consistent spacing, color, and typography across listing pages

• What Is Product Design? How to Create User-Centric Products - the broader product design process that informs UI pattern choices