You are viewing legacy documentation. View the most recent documentation.

Responsive Data Tables

Responsive data tables provide our users access to complex tabular information regardless of the device they are using.

A diagram showing the overflow behavior for a table viewed on a smaller screen, locking the first column in place and allowing a user to scroll horizontally through the table.

Problem Statement

When viewing a data table on a small screen or within a narrow container on a large screen, users need the table to provide the same value as it does at full size.


There isn’t a one size fits all solution for responsive data tables. Your approach must always be defined by both the table’s underlying data as well as the job a user is seeking to complete when using the table. Across Morningstar products, we use three general approaches when designing responsive data tables:

You can also consider hiding less important columns to reduce the amount of content a user must navigate on a smaller screen.

Horizontal Scroll

When a table is used for comparison—for example, market performance data—it is critical to maintain a traditional row and column-based layout that allows a user to compare cell values across multiple rows. By allowing a user to scroll horizontally through columns, this approach can scale to support as many columns as is needed.

A diagram showing how the horizontal scroll approach locks the first column and allows the rest of the columns to scroll horizontally.

Locking the first column in place and allowing the table’s data to scroll behind that locked column provides a user with a consistent frame of reference as they scroll horizontally through columns.

Place drop shadows around the table’s scrollable area to provide a user with dimensionality that hints at additional content out of view, as well as the ability to scroll the table behind the locked column.

When the scroll bar reaches an edge of the scrollable area, hide the shadow on that edge to indicate there is no more content in that direction.

A locked column and drop shadows add dimensionality to the table, hinting at the ability to scroll.

Set the locked column’s width to ensure that more than half of the table width is devoted to the scrollable area and make sure that multiple columns are visible within the table’s scrollable area. Don’t allow a single column to become so wide it occupies the full width of the scrollable area.

An example showing column widths that allow a user to see multiple columns in the scrollable area of the table.
Do devote more than half of the table’s width to the scrollable area, and ensure that multiple columns are visible in the scrollable area.
An example with a too-wide first column, obscuring the scrollable area of the table.
Don‘t constrict the scrollable area to less than half of the table width.

If a table is taller than the viewport, consider locking the column headers in place so a user can always tell which columns they are seeing.

Locking the column headers provides a user with context as they scroll vertically through a tall table. Locking headers in place ensure columns can be identified as you scroll through the table.

Additional Scroll Affordances

One of the challenges of the horizontal scroll approach is making sure that a user understands they can scroll within the table. In addition to the locked column styling, there are additional ways to ensure they know that more content is available.

Use a subtle animation on the table’s content to draw attention to the scrollability of a table. Consider triggering this animation automatically when a table enters the viewport.

A subtle leftward bump animation on a horizontally scrollable table calls a users attention to the ability to scroll the table's content. A subtle animation on a table’s scrollable area draws a users attention to the ability to scroll the content.

Place additional affordances, like a label or animated icon above the table to draw a attention to the scrollable content.

Once a user scrolls the table, consider fading out these elements so as not to distract from the table’s content.

A label placed above the table includes an icon with left and right arrows and says scroll for more. Additional descriptive affordances can be used to reinforce the scroll functionality to a user.


  • Allows for easy comparison across many rows of data.
  • Maintains the traditional tabular display users are already familiar with.
  • Features like sorting, row selection, and table actions are consistent with large screen experiences.


  • Requires horizontal scrolling to display all columns, so a user must understand that they can scroll within the table.
  • Viewable area for the table content is small.
  • Can result in simultaneous horizontal and vertical scroll bars.


When a table presents a set of unique objects—for example, client contact information—you can make bigger structural changes to avoid horizontal scrolling. The stack approach takes all of the cells in a row and stacks them vertically with their label, usually wrapping them in a Module Container.

A diagram showing how the stack approach takes the cells in a row and vertically stacks them, grouping them within a module container component.


Since the table no longer contains columns, the approach for applying sorting must be adapted. Consider moving the sorting function in to Selects above the table.

An example of how sorting options, like sort direction and sorted column, can be placed above a table in select components. Sorting actions can be placed above a stacked table as Selects.


  • Completely avoids horizontal scrolling.
  • Provides a clear grouping for a related set of information.
  • Provides more flexibility to improve touch target sizes and adjust a design to account for smaller screens.


  • Not suited for performing comparisons. Don’t use when analysis and comparison is a user’s primary job.
  • Adds significant height to a table.
  • In the absence of column headers, the sorting actions need to be moved to a different location.


When a data table contains only two or three columns you may not need to do anything additional to account for responsiveness. The Data Table component will respond fluidly to the viewport, with each column retaining its proportional size.

A diagram showing how the fluid approach simply scales down columns proportionally as the viewport width shrinks.

Text Wrap

For longer data points, consider allowing content to wrap to multiple lines rather than employing truncation. Since touch screens do not support hover actions, revealing a Tooltip with the full version of truncated data is not possible in those cases.

An example demonstrating how cell content can wrap to multiple lines as column width decreases. Letting text in cells wrap to multiple lines ensure they can be read without needing a Tooltip.

If truncation is your best approach, remember to stay conscious of which part of the truncated data is most important to a user. If the information at the end of the string is critical for a user to see, consider truncating data points at the beginning or in the middle of the string.

An example demonstrating how cell content can truncate with an ellipses as column width decreases. When truncating, make sure the most important aspects of your content is visible.


  • Doesn’t require any additional development work.
  • Maintains parity with experiences on larger screens.


  • Not suited for tables that contain more than two or three columns.

Hiding Non-Essential Content

When designing a table that will be responsive, work with your product team to determine if there are any non-essential columns in the table that can be hidden on smaller screens. Minimizing the amount of scrolling required will allow a user to more quickly find what they are looking for.

When possible, always ask your users directly what is most important to them. Consider working with the User Research team to discover which content matters most to your users.

Toggle to View Full Table

By defining smart defaults, you can provide a user with a simplified view of a table but give the ability to toggle the table to its full view.

An example of a switch placed above a table allowing the user to show all columns. Use a switch to allow a user to toggle between a simple and full version of a table.

User Customization

Consider allowing a user to customize the columns displayed in a responsive table.

An example of a menu component placed above a table allowing a user to customize the visible columns in the table. Use a menu to allow a user to customize a table to their needs.
©2020 Morningstar, Inc. All rights reserved. Terms of Use