Tables tend to have a somewhat (undeserved) bad reputation in the world of digital interfaces. They are often perceived as cold and overwhelming. Yet in so many cases they are the most efficient way to organize complex information in a digestible manner (which of course is central to data dashboard experiences as well as they are often paired together). A well-thought-out table interaction experience in enterprise software design can enhance clarity, ease users’ lives and maximize the data’s potential.
Enterprise software companies regularly serve up large quantities of data to their users, making well designed table experiences are a priority.
Things to consider when creating your table UX
Before embarking on your data table design, there are a couple key factors to consider. Here are some prompts to get started:
What type of data will be contained in the cells?
You need to know beforehand if your data is mainly composed of short numerical strings like dates and amounts, or if it might contain more complex data like paragraphs of text, links and files.
What is the user’s intended use for this table?
Table UX can vary greatly depending on if users are expecting to manipulate the data to scan and compare information in order to derive insights or if it’s more action-driven like editing values, updating statuses and assigning people.
Which types of devices will the table be viewed on?
The interaction experience can vary greatly between a mobile device and a large desktop monitor.
Does the table need to be actionable by the user?
The user might need to modify values and delete entries as opposed to simply consulting a read-only table.
Should the table offer customizable viewing options?
This is about how much help you want to provide the users in getting to what they want to see. This can take many shapes; searching, filtering, sorting, adjusting the display density, etc.
Where is the current experience falling short (or shine 🌞)?
If you’re working with an existing table experience and struggling through assessing the UX of the existing thing, we have a UX checklist you can use to put on your reflection glasses, and have a long hard look at your experience 👓. This will give you an idea of where you currently stand.
Now that you have a clearer idea of what the end experience should feel like, we’re ready to jump into some of the best practices to employ for enterprise table UI design. Be prepared, we’re about to get all up in the tiny details that allow this all to come together into a delightful experience.
What kind of table are you dealing with?
The mechanics of the table itself are tough to get right, there are a lot of choices you have at your disposal, which this article outlines in detail. However, it’s also quite important to think about the data table you’re solving problems for, in the context of the ‘table view’ it belongs to, this informs at a deep level your design rationale. A table view is just the screen a table is part of. We broke it down, based on our enterprise experience with tables:
👟Action oriented👓 Info oriented👟👓Action & Info Oriented
This is when you’re serving a super user and requires depth of complexity for viewing, filtering, multiple and actions.
Elements of a table
If we break it down to its core, a table is essentially made up of three things. Data, columns and rows. The goal is to achieve peak table interaction by juggling all that can be done with those elements and finding the perfect balance for your specific enterprise software needs.
Types of data
A core part of a table is the data that it is meant to show. Whether that data is textual (strings, links, paragraphs) or numerical (amounts, dates, percentages), it deserves specific considerations to allow for an optimal experience. Here, we’ve wrapped up some of the best practices.
Text
Left-align text columns
Everything that’s made up of letters should be left-aligned. This is what Western brains are used to. We’ve been reading words from left to right since childhood so, let’s not reinvent the wheel here.
Match heading alignment to column
Column names (a.k.a headers, heads, titles) should always align according to their column content. Not following this rule creates off putting whitespaces and brings in unnecessary visual noise
Don’t (ever) use center alignment
Using the right alignment for the right type of content is key for enhancing the user’s readability, mental calculations and comparisons between rows. Center alignment prevents quick scanning and noticing irregularities and ultimately makes the eye jump around unnecessarily.
Avoid duplication
When possible, avoid repeating the title in every cell of a given column. For example, you can omit repeating the word “lead” in every cell like “Qualified Lead” or “Nurturing Lead”. Placing the word “Lead” in the heading and just using qualifiers in the rows will help reduce visual noise.
Especially in the case that you have a fixed header for this table. The user will still be able to quickly refer back to the column head if ever they forgot its context.
Numbers
Right-align numeric columns
Unlike text, numerical values are much easier to compare and contrast when they’re right-aligned. The goal here is to align numbers according to the position of the decimal. If you’ve properly formatted your data so that numbers all show the same amount of decimal digits, aligning them to the right of the cell is the most logical way to display them.
Use tabular typography
It is highly recommended to use a monospace font for numerical values. This type of typography is much easier to scan and compare because instead of having proportional spacing (where “W” is wider than “I”, or “9” wider than “1”), all characters are the same size. This avoids such problems as $1,111.11 looking visually smaller than $999.99.
Some exceptions
If the first column is a date written in numbers, it is recommended to use left-align. Yes, dates are technically numbers, but they’re not exactly a numerical value and it just seems odd that the first column should be right-aligned. In fact, all qualitative numbers can be flexible to accommodate such a situation. Here are some examples:
Quantitative numbers (always right-aligned)
- Amounts (money, quantities)
- Measures
- Percentages
Qualitative numbers (can be left-aligned)
- Date
- Zip/Postal code
- Phone number
Otherwise, all numbers should always be right-aligned.
Table UI design examples
There are a lot of enhancements you can make to how your data in the table is displayed by combining related data, grouping rows by type, adding visual cues including images, icons, colour-coding, progress bars, font weights and sizes and adjusting your units. The UI of table design and the UX of table design work together to enhance viewing your table and applying table actions.
Columns
The columns of a table house the distinctive types of information relating to the row/record. Information across columns generally tends to be about the same thing, so vertical separators are optional.
Column separators
Vertical separators can make the table become visually busy. They are not always necessary. Make sure you stick to a very thin border of 1px max and a light grey colour.
Rows
The rows of a table are the distinct records, the core entities of data being displayed. They deserve more visual distinction, so let’s look at some row styles you can choose for your interface.
Division styles
Zebra Stripes
When rows have a background colour alternating between white and a light grey, that’s called zebra stripes. This used to be a widespread practice but has become more difficult to manage with increasing levels of interactivity.
It can become tricky, when using zebra stripes, to effectively differentiate between disabled, hover, focused and active states. These states are usually distinguishable by the row background color changing to a light grey.
The user ends up having three swatches of grey to visually filter through; the zebra stripes on every other row, the ‘disabled’ overlay, as well as the instances when both of these fall on the same row. (That’s not even counting the basic white of every other row and the assumed overlay colour of a row when selected, which brings us to five semantic levels, causing a break in visual continuity within the table.)
Line Divisions
A simple line division can do the trick just fine. Make sure the border colour is light enough as to not become visual noise. It needs to melt into the background.
The “card” approach
We’re seeing this type of design more and more. This is a great option to leverage if your app already has a slight background colour.
Free form
If your data isn’t that dense or complex, you might be able to afford having a free form table, with no separators at all.
Vertical alignment
We’ve already touched on the horizontal alignment for text and numbers. But what about how to align the content vertically within and across the cells?
This depends on how much variation exists between your cells’ content, or the row height.
Use vertical center-align for when the row height varies only slightly (up to 3 lines). Centering the text vertically within row height spreads out the white space within the table and thus eases visual scan.
If row height varies more than 3 or 4 lines, using top-alignment makes most sense in terms of legibility and ensuring everything is visible.
Multi-line cells should stick to the top of the cell to ensure everything is visible at first glance. Sticking to the bottom of the cells sometimes causes content to be hidden away (cells risk being clipped by browser viewport edges) and requires scrolling, but then if scrolling jumps to the next row, the experience is very jerky and disorienting and you risk never seeing the full cell content.
Viewing options
Providing customizable viewing options is a great way to improve the data table design of consulting complex tables. Having options like a ‘Columns Showed’ dropdown as well as an allocated spot for a horizontal scrollbar are great starting points.
Those two elements, along with many others, provide good visual cues for the user to feel in control of what they’re looking at. They’re aware they can customize the visible columns, and understand that it would enable the horizontal scroll if needed. It’s putting some power in their hands.
Column management
Freeze
In a horizontal scroll situation, having the leftmost column ‘sticky’ is just as important as the fixed header is for the regular vertical scroll. Sometimes also the rightmost column which typically houses summary content such as totals.
Some of these preferences can be built in the table UI itself, or offered as options for the user to set up for themselves. This can happen by having an options dropdown for each column heading.
Reorder & hide
Giving your users control over what they see is a sure way to make the interaction more engaging and productive. Forcing users to scroll through dozens of columns of data that’s not relevant to their particular role or goal overloads cognitive load and risks creating frustration.
Resize
Giving users the option to resize columns is optional depending on the type of table you’re working with. Actually, the best situation is when resizable columns are not needed because the table has proper spacing by default. But this implies having very clean, regular and predictable data which isn’t always the case, especially if said table supports user-editable content. That being said, having a drag handle show up when hovering over column separators has come to be expected in editable tables.
Add or remove columns
Giving users the option to add or remove columns is an explicit viewing option which allows users a greater degree of control over their table viewing experience. As users parse information, their use cases can change and context is important. To accommodate this reality, this super flexible feature is helpful. Note: you can make the feature completely flexible (everything can be removed or added, or you can restrict some things being removed), as long as there is a prominent ‘reset’ functionality where users can revert what they did. Take these into account and your data table UX will thrive!
What if there are too many columns in your table?
This issue comes up with data table design and there are a few strategies, as outlined above that you can take to solve this problem, to review:
- Resizing columns to make them more scannable
- Freezing left most column (and introducing a horizontal scroll)
- Add or remove columns to control what’s shown
Another key consideration (that takes a bit of a nuanced approach), is to improve the default state of the table – prioritize as a product team which columns are the most important for the user to see upon page load, in the context of that table view itself. We talk about defaults in our improving microinteractions and interaction patterns article – defaults are an under-appreciated part of the table design process (and any design really!).
To ensure you make a good decision for your ‘too many columns’ problem, make sure you get users involved in this process (you might even want to consider involving power users). This issue can be a symptom of jamming #allthethings into a screen, so zooming out a little bit and understanding user needs may be your best approach.
Row management
Display density
Letting users adjust the density of the table is another powerful way to give them control and make them feel comfortable using the interface. We all have preferred ways of reading and being able to customize your view is just a delight, especially for data-heavy tables that can otherwise feel overwhelming.
It also depends on the screen size; if I’m sitting at my desk and viewing the table on my monitor, I can afford a less dense UI and a more relaxed reading experience. But if I need to quickly compare things on a smaller screen, that’s when I need to maximize the real estate and see more rows at once.
Typically, row density gravitates around these pixel measures:
- Condensed: 40px
- Regular: 48px
- Relaxed: 56px
inspired by the blog of Fanny Vassilatos and Ceara Crawshaw
