How to design a table without complexity.
Draw some boxes and arrows.
May 13, 2020
Tables can get very complex very quickly. This fact, paired with a frequent desire to throw all possible features into a table (the kitchen sink table), creates a situation for project teams that quickly results in a poor user experience. Let me take a pause and say this in one line for dramatic effect:
Avoid complex tables until absolutely, objectively necessary.
I can hear the knee-jerk reaction now: "But our customers need table feature A, table feature B, table feature C...!"
No. No they do not. (read also as: not necessarily... to be more objective about it)
People who use software need elegantly designed product experiences that do not throw them into an overwhelming interface that requires them to read a manual. Do people have time for that? If you asked the people who use your software, what would their answer be?
So how do you avoid complex tables? Here are a few guidelines to mitigate unncessary table complexity.
1. Say "no" to adding table interactions
Make it hard to add feature upon feature to tables. Instead of jumping to immediate solutions like "we need column filters!", say "no", and take an investigative approach. This gives you time and space to fully understand the true needs of people who maybe don't need column filters. They might just need you to discover and understand the unmet need of comparing items in a table by two very specific columns of information.
2. Focus on workflow
If you take a step back and very meticulously list out core workflows that a user needs to complete their tasks, you give yourself an entire new realm of possible experiences to create.
Instead of a table with selection AND search AND column filters AND column view options AND being all responsive AND being all accessible (good luck, and don't get sued!), you map out diagrams of workflows independently and re-ask the question: "Does this really all need to be on one page with one component to rule them all?" (answer: nope!)
Focus on workflow, and make it a point to create workflows that work in parallel with each other so that the flow of the experience, regardless of task, works similarly. You're still enabling the user to become extremely efficient in this way since cohesion in workflow is just as important, if not moreso, than consistency in features. Plus, you'll be setting yourself up for success with people who use small devices.
3. Assume people only use their phones
Building on the previous guideline, we have this last one. Small devices just don't have the same amount of luxurious space to design a complex, overly-information-dense interface. So if you assume (and work with and not against) this constraint, you design in a way that limits interaction and thus limits complexity. You simplify the experience into managable steps that can be navigated screen-by-screen.
Not the guidelines you expected
By now it should be clear that table guidelines are not like you may have expected. It's not a question of "where do filters go on a page?" or "what's best to use: column filters or side panel filter?" The question is really a hard ask: are you doing enough to reduce complexity of the product experience by focusing more on understanding people to a depth where you don't need that complexity to begin with?
Back to top