Data tables are one of the most difficult features to work on, especially when we are talking about the table’s responsiveness. Nowadays, data is crucial, and how to show it could be a game changer for a business and its users.
As designers, we must think about how this data will be displayed, the relevance of rows and columns, what is customizable by the user or not, and of course, fitting in different screen sizes without missing relevant information.
Here, I will show some scenarios with data tables in them and how to create a better user experience for these tables.
Everything is storytelling, so what is the story your table is displaying?
You should understand the goal of this table and ask yourself: What, who, when, where, and how? If your table is not answering all or some of those questions, it is not working properly.
With these answers, you will be able to decide which fields are mandatory, columns and row sizes, the correct headers, how to sort the table, and any customizations that users might require.
When it comes to editing, it is always a challenge deciding the best approach to take. It depends on some external factors like the company’s DSM, how complex the table is, if it has lots of inputs, backend concerns, and so on.
After all, what is the best UX in that case?
If your table has lots of editable rows with different inputs (dropdowns, input text, radio buttons, and checkboxes), a modal could be the best solution because the user will have more space to read the data and decide what to add or edit.
However, inline editing takes place when you have fewer columns and the editing is simple. Also, the table should have room for save and cancel buttons.
Another point is that if your data table is on a modal, it is not a good user experience to have a modal trigger another modal, as when the user closes the first modal, another one is opened, blocking the user from seeing the main page.
Again, the amount of content on the table is the key to deciding which approach to take between pagination and infinite scroll.
Let’s picture a scenario here. You have a table with 200 rows; can you imagine how long it is? How much scrolling might it demand? Pagination can fill this gap; your task is figuring out how to sort the table (alphabetically, by date, etc.).
For example, 200 rows are sorted alphabetically on 10 pages with 20 rows each, and your user needs to edit a row that starts with the letter “L,” so with one or two clicks, this person can find out where the desired information is located.
When designing a data table with infinite scroll, the first thing you must think about is the space you have on the page. If you have enough room to add a table with infinite scrolling, you can go for it.
It also reduces interruption by avoiding unnecessary clicks, which could lead to frustration and misunderstandings, keeping the users engaged.
Another point favorable to infinite scrolling is the speed. Meanwhile, with pagination, your data could take some time to load once the user opens each page. If you go for infinite scrolling, everything loads once the browser shows the entire page. All the data is there but hidden, and as soon as the scrolling starts, the page will display it.
When it comes to mobile, infinite scrolling also has some advantages. Normally, pagination buttons are small, and fingers and thumbs are not as precise as the cursor, which could lead the users to a missed tap. In addition, users are familiar with infinite scrolling on social media, and scrolling with the thumb is a common behavior.
Data tables could be very large, which could be hard to fit into your designs.
One way to sort it is by adding horizontal or vertical scrolling. If your table has 30 columns, you can’t just squish information to place it on your project; by doing so, you will decrease readability, so you can decide a width to apply to that table and add a horizontal scrollbar to it:
Another scenario you might face is a page with multiple tables, so how can you display all of them at once? Setting a fixed height for each one of them and applying a vertical scrollbar to it:
“Custom settings”—this term is a nightmare to all designers. When it comes to data tables, we can have thousands of different situations. We can have tables created by admins, and “regular” users have read-only access to them or different levels of editing access.
Another possibility is an individual view for each user.
As a designer, we need to have all scenarios covered, so you have to understand user behaviors properly and the results they are expecting to see before you make any design decisions.
Searching, sorting, and filtering are almost mandatory when we are talking about tables.
The search field is a great component to have because users can refine their view and select exactly what they want, so here again, you need to have a design done for a full table scenario and a single row as a result of the search. On some occasions, you can have more than one search field, which will refine the search and show curated results.
Giving the users the ability to sort the table is crucial for a good UX. They know better than you what they want to see; however, depending on the situation, you might have to make that decision, and according to your research, you might have to sort the table by yourself.
One good example is when you have a list of names and due dates. If the prime focus of that list is to organize a bunch of information about people or companies, sorting it alphabetically solves the problem, although if you are handling a contract list, for instance, sorting by due date could be the best outcome.
Adding filters leads to a better user experience as well. Allowing the users to set some parameters to show the results they need is a common practice because it helps to display only their desired information without making people struggle to find what they need. It is a matter of speeding up the process and avoiding fatigue and unnecessary frustrations; in addition, it improves satisfaction and user retention.
We’ve covered all the big considerations for building a data table. Now is the time to think about how you will display your data.
You should follow a design system; if your product doesn’t have one, you should think about creating it. But how can you implement UI concepts into a busy data table?
You don’t need to reinvent the wheel. Left align your text if you have a Western audience because Western people’s reading order is from the left to the right; if you are working with a language that has a different reading order, you must respect it, and for the sake of consistency, headers and “regular” rows should have the same alignment:
If you have a sum at the bottom of your table, aligning it to the right is best practice. Just think about when you were learning mathematics at school. How did you align items? Placing decimals to the right and starting the calculation from the right to the left, even if you are showing the result, is a normal behavior when a person sees it, to start counting up mentally:
Repetition is a terrible practice. For example, if you have a list of employees and their working hours, you don’t need to repeat the word hours over and over again; just the header and the numbers below are enough:
However, if those numbers have a link, you should increase the clickable area, because if the user is on a touch screen, fingers and thumbs are not as precise as the cursor, so in that case, removing the header and adding the words “worked hours” beside the number would be a good user experience:
The font size and weight are also keys when it comes to hierarchy and readability, so highlight the header, the sum, or extremely relevant data in bold or in a different color. Users don’t read, they scan, so applying them will help them reach the data they want faster.
Again with colors, you must follow a design pattern here; apply a light background, and the text on it should have a great contrast. Separator lines should be visible without creating a conflict with the color you have in the text:
DO:
DON’T:
Use different colors to highlight errors, warnings, achievements, results, and links.
Also, if the design system allows you to have zebra stripes, your table will have more impact and readability on the page:
A hover-over could be helpful because you are showing the users where they are and what they are about to click. Many of the best tables have a hovered state.
It depends on the DSM you have and how crowded your table is whether you keep or remove lines; removing separator lines could make your design lighter but could lead the users to confusion when reading, so be careful:
Sometimes, we need more than just text on a table.
Adding more items to a table could be a game-changer for its ability to communicate properly. You can have check boxes, buttons, warnings, toggles, and different icons to add more context to your content.
Just be careful with images; normally, a profile picture, for example, is okay; however, a very complex, small picture that is barely understandable adds unnecessary visual noise.
The amount of information in a row could be a challenge; one way to sort it is by adding expandable rows to your designs.
To avoid messing up the data or making it hard to comprehend, you can split it into different rows “inside” another row. An accordion displaying that the user can open the “drawer” to see more would help its usability:
A summary could play an important part in the user experience; summing up data and showing the results will help users make better decisions faster.
As mentioned before, people scan, so showing a summary in a very user friendly and visual way will be a time saver, and by doing it, you will guarantee their satisfaction:
This part could be very tricky. We all know that editing a table on a mobile device is a challenge. Even Excel or Google Sheets do not have the best user experience when we are talking mobile.
To be honest, I had this challenge recently. The developers and I had a few talks to come up with a solution.
First, we decided to approach every single column individually by setting a fixed width for columns where users can’t add lots of characters, dates, or any preset information. However, columns with customized information, especially text fields like names, accounts, and comments, will have an individual percentage settled to fit on every screen size:
You need to be careful when you decide to truncate information; never truncate the headers, and add a tooltip or a hover effect if you shorten any piece of data to display the entire piece of information somehow:
Regarding readability, lots of data on a mobile device screen could be hard to understand.
One possibility is transforming the columns into rows to fit the screen size; it would lead to more scrolling, but at least all data will be readable and the designs will not be visually busy:
In conclusion, data tables are a big design challenge; however, if you apply the correct design strategy and talk to the right people (product managers, developers, and, of course, users) to understand business goals, the technology behind this data, and user needs,
You should have in mind why this data is so important to your users and, in addition, what they will do with that information in their hands.
How about you, designers? Have you ever faced those issues when designing data tables? How have you sorted it out? Have you applied any of those tips? Please share your thoughts.
Header image source: IconScout
LogRocket's Galileo AI watches sessions and understands user feedback for you, automating the most time-intensive parts of your job and giving you more time to focus on great design.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Design engineering has always lived between design and code. But with AI tools turning prompts into interfaces and code into editable canvases, that bridge is becoming a new way of building.
A three-week mobile banking project taught me that the “proper” UX process is not always realistic. Sometimes, the better approach is to work with what you know, identify what you still need to learn, and make the strongest decision possible under real constraints.
A/B testing compares two versions of a design to see which performs better with real users. Here’s how UX teams can use it to test hypotheses, measure outcomes, and make smarter product decisions.
This case study shows how one ad experience redesign increased total ad exposure while lowering perceived friction, proving that timing and context can matter more than raw interruption.
Learn more →
