To grid or not to grid, that is the question.

For more than 10 years, our customers have been requesting data grid interfaces. Anything that has been around for such a long time might need to have its usability questioned. There have to be better ways!

So, that made us think: why would anyone still need a grid? What is the real issue they are trying to resolve? Can we propose a different, better solution, tailored for their specific use cases?

Sometimes we see grids built into web applications where Microsoft Excel was used before — and that is the functionality application users are accustomed to. Anything else might have been beyond the powers of the developers, or an Excel look-and-feel might have been requested by the business, so the users ended up with a grid.

Occasionally, grids are the right solution, but in most cases, they’re not. The all-encompassing, one-size-fits-all solution is a myth: when you build something for everyone, you’re actually building it for no one.

What are grids and why are they used?

Grids are generally defined as “Excel-like” tables, with in-cell editing or actionable capabilities. Grids do not have a (bi)directional defined size. Excel might have killed the perception of any other kind of UX for the older generation, as the idea of a powerful UI became a fully flexible, customizable and editable grid of data. However, this puts the workload on the user side, not on the system. Allowing users to customize everything sends a message that you don’t know what is important — “You choose… because we can’t!”.

One of the major problems of a grid is that it cannot highlight relevant information without looking like a rainbow.

Good UX should be tailored to steer the users to the appropriate content, instead of having them find the way all by themselves. If you use screen real estate properly by displaying the most relevant data in all the right places, you can guide the users to what you want them to see. If information is not provided in the proper sequence, you’re not providing clever help.

Simple guidelines for the usage of grids

You should NOT use grids when:

1. Users already know which field they need to edit or read.
2. Cells have no direct hierarchical relation to each other.
3. Screens need to be customizable for different people, locations or tasks.
4. Users need to “save view”, which means the real functionality they need is configuration, not customization.
5. Users need to access the data in view-only mode to get value from the screen.

You should use grids when:

1. Your data has a strong hierarchical relation and you quickly want to capture a bird’s eye view.
2. You need to enter or edit data in bulk.
3. You have a three-dimensional data model.

So, what’s the alternative?

In many cases, we have found that what the users really need is a “report builder” in a table. The need for complex customization comes from having to make smaller sets of data that contain meaning. The correct data sets may, however, be attained with filters or search capabilities, which can live outside of the table, simplifying the entire user interface.

Sometimes we have even replaced grids completely. In the past, we have managed to implement workflows whereby the users were presented with just the right level of information, tailored to their needs, that enables them to fulfill a task. This approach increased productivity and saved the users a lot of time and effort, all the while reducing employee ramp-up time, errors and maintenance costs.

Furthermore, this understanding of how their business worked, acquired through the UX concept we ran, empowered our customers to optimize their workflow and standardize their practices.

Mostly, it’s not to grid

In general, when considering whether to use data grid interfaces, you should take into account not only the development costs and user needs, but also the business implications. And there needs to be a staunch commitment from IT. Take it as a rule of thumb: if you don’t need multiple rows and columns which are “talking” to each other, you may just not need a grid.

From a UX perspective, if grids are used in the wrong places, it means users can’t fulfill their tasks when using the system. They’ll have to figure it all out by themselves, in the time you are paying them for. So, when you ask yourself “To grid or not to grid?”, you’re more likely to answer “Not to grid”.

This article is an abridged version of the full “Guidelines for the Usage of Data Grid Interfaces” article originally posted on the OutSystems Knowledge Base.

Menno Cramer | UX Expert at OutSystems