Remote's global HR platform handles payroll, tax, benefits, and compliance data. Tables served as the primary way customers and internal operations interacted with data on the platform. The table-based experience decline as Remote experienced growth. As tables needed to support more use cases, and new features were built without consideration of the entire table experience.

Discovery and Research

Leading product was Patricia, leading engineering was Antonio, and leading design was myself. Others joined when needed, depending on their skills, knowledge, and the specific challenges we tackled along the way.

The project began with an extensive documentation of the platform's 60+ tables and an audit of the table-based experience. This revealed key issues and led to the creation of four guiding principles to lead the design.

• Consistency. Remote’s platform needed a consistent table experience. To meet user expectations, reduce learning, and eliminate confusion.
• Scalability. The solution needed to anticipate and support future functionality.
• Responsiveness. The solution must adjust smoothly to different screen sizes.
• Supporting documentation. Designers, Engineers, and Product Managers need the tools and knowledge to build great, consistent tables.

The guiding principles helped to get early buy in from key stakeholders, and set the tone of the project.

The aim was to leverage users' familiarity with tables. By creating an experience that built upon their existing understanding of how a table works, rather than reinventing the wheel. Other products such as Airtable, Notion, and Stripe, were referenced for familiar patterns and best practises. One Nielson Norman article in particular accelerated our learning and helped categorise user’s tasks into four key areas: finding specific records, data comparison, viewing, editing or adding records, and taking action on a record. These categories helped to create a shared language, group related tasks and functionality, and ultimately to help us move quicker.

Creating and Refining the Solution

Following the audit and research phases, I dived into low-fidelity designs. Allowing me to quickly explore solutions and patterns, focusing purely on utility and usability, instead of aesthetics. The product lead supported this phase with customer insights and stakeholder management. While the engineering lead provided guidance on technical limitations and achievable solutions.

Iterating in low-fidelity resulted in a opinionated solution which was presented to product, design, and engineering teams. We presented it as our best solution but urged everyone to critique and share their unique insights. Within a one week timeframe, 40 people reviewed the solution. Designers shared insights on how the solution would work in the areas of the product they were most familiar with, while others questioned specific patterns. Product managers and engineers highlighted new use cases emerging in their teams. The presentation helped us refined the solution, deepened our understanding of crucial use cases, and gained support across the company.

The Solution

This was a big project. Decisions were interconnected and context-specific. There's a lot to cover, and I can't do it all. Instead I'll share a few highlights.

Consistent Action Row

We needed one table for everyone using the platform - employers, employees, contractors, and internal operations. Functionality to search and filter the data is positioned on the left. Functionality to action a selected record, add a record, and view secondary actions on the right. This solution was tested with different data sets and in different uses cases, and performed the best.

Filtering

We faced a dilemma, should the filter button label display the specific filtered value (eg. 98,000, Australia) or the title of the column being filtered (eg. Salary, Country). Displaying the value caused confusion when similar types of data were being filtered simultaneously. For example, the label would display ‘Filtered by below 98,000, between 100,000 and 120,000’ or ‘Filtered by Australia, Australia’. Displaying the column title was less descriptive, but proved to be the more scalable solution and also eliminate negative experiences.

Taking Action on a Record

Selecting a row opens the table record, where users can take action. However, this workflow is inefficient for completing multiple tasks in quick succession or taking bulk action on multiple records. To improve this, users can take action on a record without leaving the table from the secondary actions menu. Users can also select multiple records to take bulk action, a consistent feature across all tables.

Scalability

The solution needed to anticipate and support future functionality. The table and table record's secondary actions menu supports future features and use cases the tables needed to support. Guidelines for introducing new functionality were included in the documentation. So other teams could build new functionality while ensuring a consistent tables experience.

Responsiveness

Vertical and horizontal scrolling were supported, empowering users to interact with large datasets regardless of page size. When vertical scrolling is enabled the table’s pagination row remains fixed to the bottom of the page. When horizontal scrolling is enabled, the first column and secondary actions column remain fixed.

In the previous solution, the actions row couldn’t handle different page widths. In the new solution, the actions row adapts seamlessly as the page width increases and decreases.

Page Layout Guidelines

Tables relationship with other components was considered. When the table was positioned below tabs, page layout guidelines were created to ensure that all table-related functionality remained inside the tab. In other instances the ‘Add Record’ button needed to be louder and more prominent on the page. Guidelines were created to empower teams to achieve this without compromising the consistency of the tables experience.

Interaction of Colour

Colours were considered systematically and were chosen intentionally. Components were paired and their different states were tested. To ensure changes in an interactive components state appeared smooth, consistent, and didn’t cause friction.

Table Cell Variations

Compact tables were built specifically for Remote’s internal operation team, who typically interacted with larger payroll and tax datasets.

Tables cells with avatars, country flags, and secondary information gave employers, employees, and contractors a more consumer-like experience.

Collaborating with the Design Team

Others joined when needed, depending on their skills, knowledge, and the specific challenges we tackled along the way.

Andre, another product designer, jumped in at the end to work on table pagination, and served as my springboard for discussing design decisions.

John, a UX copywriter, joined the project to ensure the solution matched our copy guidelines and to identify any gaps in our guidelines. Together we tackled trickier problems such as how we communicate sorting options - for example should we say ‘Alphabetical A-Z’ or simply ‘A - Z’ - and to create consistent language for taking action on a record. Guidelines were also set for created for blank states - for instances were no table records existed, or searching and filtering produced no records.

As the project neared completion, Rebecca, a UX researcher conducted a heuristic evaluation of the final solution. The results were positive, however the Search experience scored the lowest. This was anticipated, as this part of the solution had to work around tech limitations the most.

Challenges

We ran into many tech limitations, two in particular were for search and pagination functionality. Searching was limited to the first column instead of all columns. This restricted the customers ability to reorder columns, as the first column remained fixed. Pagination discussions seemed to go in circles, debating if pagination was an acceptable solution or if it was worth the engineering effort to build infinite scrolling. We needed to be pragmatic, the tables project was large enough without infinite scrolling, and we decided on pagination.

The product lead, engineering lead, and myself were working on this project part time. While also supporting other teams. This stretched the timeline and caused progress to start-and-stop. The difficulty with a longer timeline was more tables were being built after our initial audit of the tables experience. Some backtracking happened during the design phase to ensure we considered new use cases the tables needed to support.

Remote's fast-paced growth led to teams using tables for use cases they shouldn't. Not out of laziness to build new solutions. But for speed and lack of clear guidelines informing teams when and how to use tables in the platform. A few times I asked teams why they built a table, tell them the new tables solution won't support this use case, and guide them on better options.