Modern Enterprise UI design — Part 1: Tables
Thoughts, patterns, and solutions.
Designing for enterprise is hard. Why? Because, generally speaking, Enterprise software is complicated. You have vast amounts of data to display, user configurable UIs, complex workflows, automated tasks and much more. Designing for all these things can be a bit of a challenge 😓.
As a result, some Enterprise applications offer a poor user experience and end up looking, well, a bit dull.
Over a series of posts, I’m going to break down some common enterprise application UI patterns, problems, and possible solutions.
It’s worth pointing out, there is no one size fits all. The patterns and solutions mentioned below are things I’ve found to work, through iteration, user feedback, and testing. Solutions should, of course, be tailored to your application and more importantly your users. Nothing beats speaking to your users and watching them use your software.
Let’s start with tables
Enterprise applications have to deal with vast amounts of data and since there is no better way of displaying a significant amount of data (yet) than a Table, let’s start there.
Above is a typical example of a table in an enterprise application. Lovely isn’t it. Let’s explore how we can improve the experience of complex tables and what we need to consider when doing so.
Here are some questions we need to consider when designing and building out a data table:
- What devices will be used to view the table?
- Do we have control over the data that will be displayed or is it configurable by the user?
- How can we aid quick scanning of the table data?- If the table will contain a lot of data, how can we make it’s easy for users to find the data they need?
- Will rows have shared actions, such as edit or delete?
- Could table cells contain lots of data, addresses or even paragraphs of text?
Above all, remember to speak to your users, find out how they will use the table and the data it will present.
Note: For the rest of this post, I’m going to assume we’re working on a web-based application although the majority of the points below apply to any enterprise application regardless of platform.
Basics first
We’ll start with a basic unstyled table showing fictitious customer details:
First, let’s add some basic styles that provide a clear separation of rows, aid readability and remove some of the default browser styles.
It goes without saying that the table should be accessible to all users. Using proper semantic markup is a must so that users of screenreaders can navigate through the table one cell at a time, hearing column and row headers spoken to them. Column headers should be descriptive and relevant. Table styles should meet WCAG 2 AA contrast guidelines (or even AAA depending on the level of compliance needed).
Responsive tables
Users could be viewing our application on any device, so we need to ensure our table will be usable whether displayed on mobile, tablet or desktop.
At the moment our table isn’t responsive so it won’t look great on devices with smaller screens. Responsive table design is a huge topic that’s outside the scope of this post. So, for now, let’s look at two common approaches:
Collapsing columns
With this pattern, any columns that don’t fit on screen are hidden. They can be toggled by the user to show the hidden data. You could take this one step further by defining which columns should be given priority at different viewport widths ensuring critical columns are still visible on smaller screens.
Horizontally scrolling tables
Perhaps users need to compare multiple rows quickly without having to jump around expanding things? One common pattern is to allow the table to horizontally scroll on smaller screens, removing the need for hidden columns. Consider using both patterns and provide an option to switch between the two.
Dealing with lots of data
At the moment our table looks ok but has some usability issues. Imagine we had 10,000 rows, finding one particular record might be a challenge.
Pagination
By adding pagination, we can limit the number of rows per page making the data a little easier to digest. Above we’re using ten rows per page.
Pagination has many benefits. It makes it easier for users to search through the list manually, gives them a sense of control (unlike infinite scrolling) and allows users to keep a mental note of a rows location. When using pagination we should allow the user to choose the number of items per page (ideally saving their choice for the future) and also display the total number of items in the list, and how many are in view.
Allowing the user to change the number of items per “page” can make it easier when comparing multiple rows than may span 1 or more pages.
It’s also worth considering at what amount of data the table will need paginating. For example, if we paginate to 10 items per page, but there are only 11 items, then a user would need to click next to view the final row. Why not programmatically check if there are, say more than 20 and if so enable pagination.
Lazy loading
Another common pattern, either by a “load more” button under the table or by loading additional data when the user scrolls to the bottom of the table. I’d recommend pagination over this, mainly for the benefits listed above. Infinite scrolling removes some aspects of user control (When will the data end? How many records have I viewed?). It’s more suited to apps that focus on users consuming a stream of data rather than a list of data where more user control is needed.
Searching the table
Another solution would be to filter the table data by specific search criteria.
Sorting by columns
Sorting data by columns allows users to group similar data by a column values.
These patterns work great in tandem, filtering the table to show relevant data, searching for fine-grain results and then sorting the results by value.
Providing a summary of data
Adding a visual summary above the table can assist the user in quickly analysing the data.
Designing for the unknown 🔮
In many applications, it’s entirely possible that the table structure and its data are defined by the user so you may not know what data will populate the table at all. A well-designed table should accommodate for this. Typically this presents a couple of additional challenges.
Could the table contain very long URLs or paragraphs of text (address data, user submitted messages, form field values)? We’ve got a couple of options here:
Truncate long text
Does the user need to view all of the potentially long text for each row at the same time? It’s unlikely. A solution would be to truncate text at a length that’s useful enough to give the user an overview of the data and provide a method for viewing more, either by linking to another page, showing more content within a modal or by some other way (we’ll touch on this later).
Wrap long strings
Long URLs can potentially break the layout of a responsive table. We should make sure any links (or long unbroken strings) within a table cell breaks correctly so as not to break the table layout.
Row actions
Common row actions should be grouped. If it’s possible to perform these actions on multiple rows at the same time, then the action should be removed and added as an option elsewhere on the page (close to the table). Of course, we’ll need a way to select multiple rows.
Table Actions
Common table actions include:
Printing table data
Allow the user to print only the table and not the surrounding UI. Use print targeted styles to optimise table styling for print. Remove pagination when printing to ensure all table data is printed.
Downloading table data
Almost all power users will want to download the table data in a standard format (CSV, JSON, etc.) to allow for data manipulation in other software. If the file size is likely to be large, consider using a zip archive. If the archive is not instantly available, inform the user and email them when it’s ready to download.
In this example, we’ve used an “actions” drop-down menu above the table to allow for table specific actions
Viewing additional row data
Depending on the use case, a user may need to quickly access additional information about each row while staying in context. This can be accomplished a number of ways.
Modals
Modals allow the user to stay on the same page as the table but give greater focus to the additional information and any actions that may be performed.
Detail panel
Depending on the situation, you may find that a modal might not be the ideal solution if you need to keep the data under the modal visible. A detail panel that slides into the page might be a better solution when keeping in context and needing to keep the data in the table visible.
Closing thoughts
There’s often more to the humble table than meets the eye. Hopefully, some of the points raised above will help you the next time you come to design a table.
The UI’s above were built with the Pulsar design system which delivers the bulk of this functionality to the Jadu Continuum Platform.
Update: Part 2 which looks at modal dialogs is now live!
