Our company is trying to make our website simpler and easier than our competitors, and one thing that's difficult about that is our data. A big table of data is shown on most of our website's pages, so it's essential that we make this simple. We've tried to slim down the table by removing unnecessary information but from a business perspective, a lot of it needs to be kept there. Here are a few things we've done so far:

  • Add collapsible rows for things which are "sub-tables". Imagine a list of companies, and each company has a sub-table for a list of employees; that sub-table is a collapsible row that expands beneath the company's row in the table.
  • Add tooltips for more detailed information about things such as cost if there any complications.
  • Add modals/popups for a very, very detailed breakdown of that row which are opened by clicking on a link (using the row ID).

Now I'm at a point where I see a table which can't have too many things removed. We have important things such as customer info, prices, edit/delete buttons, checkboxes etc. that can't really be removed.

Do you guys have any tips for keeping your tables simple? Or do you have any little tricks you use to save space/columns with your tables?

  • Why don't you post a mock up of your table so we can advise you accordingly on what to trim. You could probably start with removing unnecessary aesthetic. I recalled someone posted this, I thought this is just clever so I'm just going to post darkhorseanalytics.com/blog/clear-off-the-table for your reference. – adamsoh Feb 25 '16 at 4:17
  • Do you feel like the changes that you have made is resulting in a 'simpler' table? What is the feedback from users or from other people in the company? – Michael Lai Feb 26 '16 at 1:21

Minimizing Table Real Estate

You say you want to “simplify” the tables, but it sounds like what you’re really after is reducing the space they require. That can help the user by making more information visible at a time, reducing scrolling or paging. Here’re some ways to do that:

  • Progressive disclosure. You’ve already done that by moving some fields to popups/drilldown windows (generally they should not be modal), collapsible rows, and tooltips. Another method is a master-detail, where you have a pane below the table (ideally collapsible) to show less important fields (an “overflow”) or a “subtable” for the current object in the table. Putting a subtable in a detail pane preserves the ability of the user to scan down a column in the main table, which is often the reason you’re using a table in the first place.

  • Eliminate redundant/unnecessary controls. Many web apps have a separate control for each action on each row of table, which can make for a lot of command buttons. The alternative is have an object-selection-action UI, where you have a single centralized menu of actions (could be a pulldown) that acts on the selected row(s). This is often worth it if you have more than a couple actions possible per row. You can also use edit-in-place, and eliminate the Edit button, saving space in addition to saving effort for your users.

  • User groups. Not all users necessarily need all fields. You could create different groups of users depending on their position or role in the organization, and show each only the fields they need. The user group is associated with the user’s login so they don’t have to choose it on each login.

  • Table customization. If you can’t anticipate which users use which columns, it sometimes makes sense to have the users handle this issue by letting them add and remove columns, like can be done in MS Outlook with their Field Chooser.

  • Grid (versus list). A true table, with columns for each field, a field header at the top, and horizontal scrolling (if necessary), typically makes more efficient use of space than a list, “tiles,” or “cards,” where one field can appear under another in a given row (like the questions list used here at Stack Exchange). You can squish rows closer together and you don’t have to have redundant labels in each row for non-obvious fields.

  • Compact presentation. Minimize the graphics used to delineate fields and rows so you can move fields and rows as close as possible to each other. All you need to delineate a field is a faint flat box or maybe just a line. Try to get each row to be no more than 25 pixels high equivalent.

  • Abbreviations. Field names (in column headers) and field values can use abbreviations. “Has Extended Warranty” can become “Ext. Wty” for example. “Delivery Date” can be simply “Delivery” (“date” is implied by the fact the value is clearly a date). Icons can also save space, but often text abbreviations are easily to learn and remember. A tooltip can show the full text to help learning.

  • Compound graphic coding. While abbreviations often take no more space than an icon while being easier to learn, graphic coding can be more compact if a single graphic encodes multiple fields, each with a different graphic code. For example, a single icon can indicate (a) the class of product by shape, (b) availability by darkness/saturation (e.g., light gray means out-of-stock), and (c) sale status by outline (e.g., a green circle around the icon for products on sale). Your tooltips can show with text what the icon means to aid learning.

  • Multiline or angled headers. If your field headers tend to be much wider than your field values (e.g., your field values are just checkmarks or “Yes” or “No”), don’t hesitate to make your headers be multi-line. You may even want to hyphenate some words. Another approach is to angle the headers (generally going from lower left to upper right), like MS Excel does to cell with the Orientation – Angle Counterclockwise feature. This allows you to “spoon” columns, making them no wider than they are high.

Maximizing Table Ease-of-use

You say the ultimate goal is to make the web site easier. A “simpler” smaller table is not necessarily an easier table. A more compact table means less scrolling/paging, but many of the things I listed above can make using the table harder to use. Each has a trade-off.

  • Moving fields to a different window can make them harder to find and access.

  • Putting fields in an “overflow” detail pane makes it harder to compare multiple rows on that field or scan for rows on those fields.

  • An object-selection-action UI means it takes two clicks to do an action (like delete a record), rather than one.

  • Table customization shifts the design burden from the designer to the user.

  • Abbreviations and graphic codes have to be learned and remembered.

  • Heavily hyphenated or angled headers can be harder to read.

Whether anything actually makes the web site easier depends on the details of the users and their tasks. For example, the benefits of abbreviations and graphic codes are greater if your users frequently use the app, so the benefits justify the cost of learning/training. Conversely, when thinking about how to improve the web site, study the users’ tasks. There a lot of ways a table can be difficult to use in addition to having a lot of fields.

  • Tables are good for the task of comparing multiple records or scanning for a record with certain field values. If those aren’t your task, maybe you don’t want a table. Maybe you want a single Search blank for the user to enter the (known) record identifier, and then you display all the fields for a single record as neatly laid-out (with a good visual hierarchy) form or page.

  • Redundant graphic coding of field values can make items in a table easier to scan and compare. For example, a small bar graph integrated in the cost field can represent cost graphically. Bold print or colors can draw attention to records with certain field values.

  • Consider grouping fields in the table into sensible groups. This can be done with additional white space, vertical rules, and group labels that span multiple column headers.

  • Consider the users may have an intrinsically complex task. Maybe this isn’t an issue so much of the table appearance. Maybe what the users need is better analysis or decision support tools. These could be sorting, filtering, find, or aggregation features, or it could be more sophisticated automation (e.g., an alerting feature for user-set criteria).

  • Little things can make a big difference, things like getting the column order right, having fixed row and column headers that don’t scroll away, zebra striping for the rows, resizing the table width and height to fit however big the window is, and using a scrolling pane rather than paging.

  • Wow, that is a pretty comprehensive list... just past experiences or is there a handy reference somewhere? – Michael Lai Feb 26 '16 at 1:22
  • Great pointers. As mentioned by the last comment, are these based on your own experiences or did you read up on some of these somewhere? If so, I'd be interested in reading that. Awesome reply anyway. Some things like the icons would be extremely handy but I would have to check on our retention rate. I was also thinking that moving the delete functions to outside of the table rows would be good as you suggested. – germainelol Feb 26 '16 at 6:54
  • @Lai & germainelol: The list is from experience –things I’ve seen done before. The only other place I know with a similar list is my answer to a similar question on Stack Overflow (stackoverflow.com/questions/3474247/…), written before this site forked off of it. It has references for a few individual items… mostly to my own web site. – Michael Zuschlag Feb 26 '16 at 18:57

As I see it, there are in principle three ways to keep tables simple:

  1. Keep the data simple - after all, you can't easily design a simple table when the data is complex. You can however make a table complex when the data is simple, but that's a much worse offense.
  2. Keep the design simple - there are many questions about table design on UXSE, and you can browse some of the more popular answers. Sometimes the data is simple but the design of the table makes it more difficult to visually process the information, so there are things you can improve around those design elements.
  3. Keep the presentation simple - if there is a lot of things to show, work out whether you need to show all of it at once because it is possible to show just what they need and provide more when they ask for it.

If none of those things work for you, perhaps a table is not the answer and you need a more complex data structure to present the content. In this case you might want to consider various data visualization techniques and go for something that is custom designed for your information and processes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.