Logikcull Design System - Tables

product design

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

The Product
Logikcull is instant discovery for modern legal teams, and it’s a cloud-based solution for the expensive, complex, and risky challenges associated with eDiscovery, internal investigations, and open records response.

Logikcull’s XD Team, PMs

My Role
︎ Research
︎ Synthesis
︎ Wireframe: Table Component
︎ Mockup: Billing Table

Legaltech, eDiscovery, Design System

During my time at Logikcull as a Product Design Intern, I worked on Case, which is a design system for the product, under the guidance of Michelle (VP of Design) and Melinda (Product Designer).

When I joined the team, the Case system was set up with a basic structure and populated with design components at varying stages of completion. I compiled and standardized different element into a single project on Figma and created a template for each component.

My contribution is mainly focused on building the Table component. I went through the complete process to research, defined its principles and behaviors, and designed mockups incorporating new styles from a visual redesign of the entire product.


Inconsistencies and Lack of Definition

Logikcull’s UI has been evolving with the product, and design elements were built along with new features. While the over UX is largely coherent, there were minor inconsistencies across the product, and the lack of standardization also complicated the workflow for both designers and developers.

In response to this problem, Logikcull’s experience design (XD) team is 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.

I also created a template for each component on Figma based on existing components built for proper documentation. It also helps designers understand when and where to use different components in the future.


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.

The next step is to boil it down and understand what goals would the user like to achieve in a Table component.


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.

My assumption is that 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 sources I found the most helpful were Design Systems of other products and design articles on Medium, for example:

VMWare’s  Clarity Design: Datagrid
Google’s Material Design: Data tables
Shopify’s Polaris: Data tables
Quickbook’s Design System: Tables
IBM’s Carbon Design: Data tables

Design better data tables - UX Collective
11 data table design guidelines - UX Collective
The Ultimate Guide to Designing Data Tables

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.

Columns in a table provide a certain degree of freedom for users to customize and add new columns, with the ability to also quickly sort and filter. Contents are organized in a grid-like system in rows and columns, so it’s easier for users to make mass selections and take batch actions.


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 mockupsHere is a closer look at some of them:

Default Style

Drop-down combo button on the top of the table so that users can easily take batch actions on mass-selection.

Soft drop shadows around the border of the table to indicate the boundaries of the table.

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


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

The header, which is the first row, is fixed when scrolling vertically, for easy view of the names of each column when scrolling.

The first column is also fixed when scrolling horizontally, so the user can refer to the name of the item displayed in the row when scrolling.


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 explore options of collapsible/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.

I created mockups for the default view and the view with dividers;
 I also explored two types of display of information for the expanded row: showing more information for each cell vs. for the entire row.
Default / With Divider

I also explored other features including Pagination vs. Load More, Customization options as buttons above the table vs. in the header, and Display Density.

Mockups incorporating New Styles from Visual Redesign

Towards the end of my internship, our team started a redesign project for the product’s UI. We brainstormed with different departments in the company about the emotions we’d like to convey to our users, and our team developed new themes with mood boards for the look and feel of the product.

I incorporated the theme “Focus” into the Table component and came up with a color palette according to its corresponding mood board.

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


© 2020 Copyright. Created by maggie