Skip to main content

Guidelines for the Usage of Data Grid Interfaces

A study of UX based use cases

Although OutSystems customers consistently request data grid interfaces, there are actually better alternatives we encourage you to consider. Grid interfaces are useful in some instances, but in most cases, they aren't necessary.

Grids are often built into web applications that are designed to mimic Microsoft Excel. Application users are accustomed to this format and that's how it's sold: "Use a familiar interface". However, grid interfaces are just a generic solution for something that has always been done a certain way.

Occasionally, grids are the right solution, but in most cases, they're not. A one-size-fits-all solution is not a real solution. When you build something for everyone, you're not building it for anyone.

The major problem with a data grid interface is that it cannot highlight relevant information without looking like a rainbow. It becomes virtually impossible to find a use case where 10 different data fields share the same relevance, at the same time.

When you're asked for a data grid interface, before you start, you should consider the answers to the following questions:

Start by posing the following questions:

What are grids and why are they used?

When considering grids, it's important to know the difference between bidimensional reports and dynamic tables. A table is a defined two-dimensional organization of data. A grid, which is also a bidimensional organization of data, has a flexible size (no bidirectional definition) and you can change the relationship between content fields by editing their hierarchical relationships.

Grids are generally defined as "Excel-like" tables, with in-cell editing or actionable capabilities. Excel changed the perception of what a powerful UI is; as a result, users are now accustomed to fully flexible, customizable and editable grids of data. However, this puts the bulk of the workload on the user, not on the system.

When you design an interface that asks users to customize everything, you're telling them that you don't know what's important. You make them choose, because you can't.

Why do customers need a grid?

Grids have been used for many different use cases. Some of the cases we’ve seen are bulk data entry, reporting capabilities with sorting, filtering and data editing, and computational activities. Customers are likely to need a grid when their data has a strong hierarchical relation and they quickly want to capture a bird's eye view or they have a three-dimensional data model.

When are grids used when they don't need to be?

A popular use of a grid is as a view creator or selector. This reporting function is necessary, but a grid adds full-blown editing, sorting and saving capabilities, none of which are necessary for a "view-only" use case. We can safely say that grids should not be used when the primary usage is the access to data.

Many users ask for a grid interface, because they are used to Excel or VB interfaces, with functionality that was there for business reasons and not user needs. Optimized processes rather than grid interfaces enable better training for new users, facilitate business changes and maintain quality throughout the work.

What are the alternatives we can provide?

Good UX steers 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 users to what you want them to see. If information is not provided in the right sequence, you are not helping them.

In many cases, we have found that all 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 with meaning. The correct data sets may, however, be attained with filters or search capabilities, which can live outside of the table, simplifying the user interface.

Sometimes we've been able to replace grids completely. We implemented workflows whereby the users were presented with just the right level of information, tailored to their needs, 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 the business works, acquired through the UX concept we ran, empowered customers to optimize their workflows and standardize their practices.

The OutSystems way

In Platform 8, we introduced the editable table, which you could expand and was enabled with fields you could access, edit and save. We thought that would solve and address everyone’s specific needs. But, even though this takes care of most of the data entry use cases, we still got requests for more complex capabilities, such as multiple sorting and filtering.

The rules laid out in this article are essential guidelines for when someone wishes to use grids. The perception of need could be based on something that has always been done that way, but has never been questioned before.

The business may not be able - or willing - to pinpoint the correct user needs. They need to be aware that data grid interfaces are complex, difficult and expensive to maintain. As development is facing implementation complications with grid integration, we need to encourage clients, partners and developers to question its usage and provide suitable alternatives.

Simple guidelines for the usage of grids

You should not use a grid when:
  • Users already know which field they need to edit or read.
  • Users only need to access 1 column, not several at the same time.
  • Users do not need to see all fields; an Excel sheet is only the accelerator by the absence of filters.
  • The real value of the behavior comes from “viewing” the data, which creates the requirement to “save a view”, a configurable functionality, not customization.
  • The vertical vs horizontal hierarchy is merely used as “storage space”.
  • Cells have no direct hierarchical relation to each other.
  • The reason for the grid functionality lies in between use cases, personas or locations.
  • A customizable table is all that's really needed.
  • Users need to “save view”, which means the real functionality they need is configuration, not customization.
  • A vertical scroll is required to view the grid contents, which implies that the information needs to be displayed in a step-by-step form that loads if and when it's needed.
  • A mobile layout is being deployed; a bigger grid format will be more difficult to manage, particularly in smartphones.
  • Multiple scrolls are the way to find the relevant data points; users tend to forget the intent behind each column, thus quickly lose context.
You should use grids when:
  • Your data has a strong hierarchical relation and you quickly want to capture a bird's eye view.
  • You're showing the result of a precedent search based on user criteria.
  • You're applying formulas to a data set that you don't want to lose sight from.
  • You need to edit or access ANY cell, but not sequentially.
  • Users needs to see “all” fields to determine which one to edit/access.
  • You need to enter or edit data in bulk.
  • You need to format and build relations and conditions (basic computations).
  • You need easy, changeable visualizations (different graphs, formulas).
  • Data changes have hierarchical implications; a change on one level of data has implications on other levels of data.


All in all, a grid is extremely powerful and complex functionality that should be applied carefully. When considering whether to use grids, take into account not only the development costs and user needs, but also the business implications. IT needs to be committed to the change. 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.

If you do decide you need a grid, you need to evaluate:

  • The cost of implementation: Grids are harder and take longer to implement.
  • The cost of maintenance: When you change anything on the grid, you must retest each functionality before deployment to determine if anything broke, because that adds costs.
  • The steeper learning curve: Users and employees will need more in-depth training on how to use the functionality
  • The loss of control of the user's workflows: The load of customization is put on the user.

From a UX perspective, if grids are used in the wrong places, it means the system will not enable the users to fulfill their tasks: the users will have to figure it all out by themselves.

  • Was this article helpful?