Data Tables

Data tables are one of the most important elements of the UI at Oracle, providing enterprise and customer users not only a wealth of critical business information, but also a set of tools for manipulating, analyzing, and reporting that data and the insights it can surface. As the first step in a broader redesign of our UI, we decided that improving data tables would not only provide a substantial improvement to the UX, but the lessons learned and solutions designed would serve our larger goal by providing solid design direction.

Existing data tables were plagued with a host of issues that our redesign would hone in on, from complicated filtering and unintuitive row actions to inconsistent use of icons and awkward row selection. The use of both server-side and client-side table data led to design compromises in an effort to be on par performance-wise, and each table had its own collection of uniquely labeled buttons, resulting in an incoherent design that reduced the overall UX. 

The first step in our work was, of course, a review of our tables, how they were used, and what outstanding requirements and needs were not yet met, or met sufficiently. Along with this review, we began to deconstruct our data tables, making sense of the multitude of controls and features that we utilized so that we could more easily address them. As expected, this review began to immediately have benefits that went beyond our tables, for many of the elements we looked at with a critical eye had use elsewhere in the UI, especially the more atomic components, like buttons, icons, and so on.

A review of data tables designed by others, their guiding principles, and some truly innovative and helpful work by great designers across the globe, was also very helpful. Andrew Coyle's "Design better data tables" was particularly valuable, as it is essentially an inventory of all the possible features a data table may have, presented in an incredibly simple and beautiful way. This provided us lots of ideas as we set out to begin exploring solutions.

We had just adopted Sketch as our team's primary design tool, and this project was the perfect way to become proficient in the new app. I began to pump out designs that pushed the possibilities of what we could do, while also starting to build up some significant Sketch libraries populated with every kind of atomic element, from form controls and buttons to colors and text styles. Our team -- five designers and a manager, spread across the globe -- met each week over the next few months for a full review and discussion, carefully dissecting each new solution and offering alternatives when valuable. 

When we felt that we were about halfway to our final design, we began user testing using an online static prototype. I built out the various screens, documented the questions we sought answers to, and provided necessary assets to our UX researcher who would be conducting the sessions. Testing took a few weeks and provided us with an incredible wealth of information. Some, we expected, but as is almost always the case with good testing, we discovered things we never considered. For example, we found that in what we believed was a very standard pagination control, the text "1 /200" was not clear to users as a page indicator. In fact, a number believed it was a count of all table records. To solve this, we simply added the word "pages" to the end of the string. As Luke Wrobleski says, "Obvious always wins."