Logikcull Design System - Tables

PRODUCT DESIGN

Keywords: LegalTech, eDiscovery, Design System

GOAL

To establish a single source of truth for design components, build consistent patterns of usage, and streamline the process for design and collaboration.

TEAM
Logikcull’s XD Team

MY ROLE
︎ Research
︎ Synthesis
︎ Ownership of the Table Component
︎ Mockup: Billing Table

PROBLEMS

Inconsistencies and Lack of Definition

Logikcull’s UI has been evolving with the product, and design elements were built along with new features. There is a lack of standardization which complicated the workflow for both designers and developers.

In response to this problem, we are building a design system - Case, to define and standardize various design components, create a cohesive user experience in the product, and improve efficiencies for individual and collaborative workflows

How might we design components in design system for an enterprise product to create a consistent user experience and efficient workflow?

Our team followed the process of Audit ︎ Research ︎ Correct when creating a component. This ensures consistency and validity in each component designed, and that every design decision is carefully considered and justified.

AUDIT

Finding Tables in the Product

I evaluated the product and found 6 locations where tables exist. I examined each table and labeled distinct elements in each table like “Header”, “Tooltip”, “Icon”, “Drop-down menu”, etc.

The most complex table is on the main Search screen, where users can toggle between list (default) and table view to sort through fils from search and take further actions like culling. There are also other simpler tables on other screens, such as Billing, Notice Template, and Saved Searches, where the table simply displays information and has one or two CTA buttons.

I tallied the number of appearances of each element on different screens and printed them out to pin on a board. I then put post-it notes on the board for:

Inconsistent use/behavior of elements
- e.g.︎ icon for sorting on screen A, but ︎ icon on screen B
UI bugs
- e.g. Inconsistent use of colors, font style, etc.
Redundant use of an element for an action/purpose fulfilled by another element
- e.g. A tooltip for the download button saying “Download”
Any other questions I have about the usage of an element

This helped me visualize inconsistencies among different tables across the product, and allowed me to contemplate the purpose of using a Table component on each screen holistically.

RESEARCH

User Research to Understand Table Users

To better understand what goal does the user want to achieve from using a table, I turned to user research.

Prior to my work on the Table component, Anahid, a senior product designer on the team, had done some surveys on Tables and compiled user data from our analytics platform regarding usage of tables in the product.

I looked through these data and learned important insights about users’ priority over parts of the search table: e.g. users prioritize action buttons over other elements in a table, and they also care a lot about the File Paths and Tags.

What I found is that the Search Result table view seems rarely used based on the clicks on the toggle, because there were a lot of 1-time users who click on it once, and the number of users dropped drastically with the number of clicks.

Assumption:

Most users clicked on the toggle button out of curiosity, and those who clicked on it at least 3 times in a single session are those who actually use the table view.

To validate this assumption, I played around in the analytics platform to learn about different action sequences of the table view users and found that some of the most common sequences seem to agree with that assumption.

I also reached out to a product manager to get in touch with some of the superusers (those who click on the table view for >5 times in a session) of the table view. I planned to conduct short interviews with them to get qualitative insights into how they use tables; unfortunately, with a small pool of table users, I did not get to interview them.

Secondary Research to Understand Tables

Along with user research, I also conducted secondary research on the undernet to understand how tables are used and defined by others. Some of the most helpful ones are design systems for other products: VMWare’s Clarity Design’s Datagrid, Google’s Material Design’s Data tables, Shopify’s Polaris’ Data table, Quickbook’s Design System’s Tables, IBM’s Carbon Design’s Data table.

I compiled them together, and extracted key elements of a Table component (a.k.a. Data Table) to form the following guidelines for usage of Table components in our design system:

Use a table to display a large amount of content in a structured manner, using mainly text, numbers, and icons, with minimal visual assets.

The rule of thumb is whether this information can be easily grouped into rows and columns so that each row represents an object that has similar attributes to the other objects displayed. The goal of using a table is to allow users to quickly scan and digest the information in each cell, and compare across rows and columns.

DESIGN

Explore Table Features and Behaviors

After extensive research on what Tables are, I incorporated my findings into the current usage of tables in the product and explored various features and behaviors in mockups. Here is a closer look at some of them:

Default Style

Drop-down combo button for users to take batch actions on mass selection.

Row-specific actions are collapsed under a “kebab” menu, which will be visible upon hover.

Scrolling

When the table contains a large volume of complex data, it can be scrolled horizontally, vertically, or both at the same time.

The first row is fixed when scrolling vertically, and the first column is also fixed when scrolling horizontally.

Divider

For complex tables, there are vertical dividers in the header row to indicate customizable width for the table.

Expandable Rows

For a clean view of tables with a lot of textual information, I explored the options of expandable rows.

Upon clicking the small triangle on the left of the checkbox for each row, the user can view/hide more information about the item displayed in the row.

Default / With Divider

Other Features

Pagination vs. Load More, Customization options as buttons above the table vs. in the header, and Display Density.

Mockups incorporating New Style

Our team also started a redesign project for the product’s UI. I incorporated the theme “Focus” into the Table component and came up with a color palette corresponding to a mood board we created.

Then, I designed mockups for the Billing page in the product, which contains a simple Billing table with dark/light navigation bar with some of the features I’ve mentioned above.

Dark Nav Bar

Light Nav Bar

maggie chen

Works Graphics Info