Background

People build databases within Airtable to manage their workflows. These databases contain many forms of data, within which many of them are connected to each other.

Design Problem

A common themes within Airtable that has been brought up by our researchers was that:

Making changes are scary

Our users are afraid of the repercussions of their field changes, due to (currently) invisible relationships. This becomes a time suck where they need to chase down what broke (formulas, look up fields, automations, among others) elsewhere after a change.

How might we design a solution that helps enterprise users make confident changes at scale while optimizing the management of their workflows?

Business Impact

Many Enterprise customers choose Airtable because of their capability to provide a powerful visual database that connects complex data and workflows. However, an important aspect of creating and maintaining complex workflows is the ability to understand and manage (at scale) the impact of your changes.

Airtable’s product needed to be optimized to provide increased visibility into these relationships, especially in more complex databases.

The Solution

I led and designed the Airtable’s new base management surface called Field Manager which gave users:

• More functionality and control over changes around field schema

• The ability to view field details and relevant relationships on this surface to make more informed decisions

Project Definition

Bases, tables, fields, view configurations, interface elements, automations, the list goes on. My main goal when I started this project was to understand how the Airtable anatomy relates to each other. Some high level questions I had were:

• If you change or edit one thing, what are the cascading effects?

• How in-depth do our users need to understand these cascading effects?

• Why would this be important information to show

• When would we show this guardrail to users?

Before diving into explorations, I needed to understand the problem space. I did an internal audit and mapped out the relationships of how “A affects B”. I discovered that there was different layers of dependencies with this diagram and pushed for raising awareness for the second layer of dependencies since those would be “break” or not.

This project was broken down into several design problems. Below are some high level problems that I came across during this project.

Problem 1: What scope do we want users to work in?

Direction #1: I want to view my field configuration at the table level

• Show me all my fields across this entire table

Direction #2: I want to view my field configuration at the view level

• Show me all my fields in this view only

Problem 2: Dependency Slide-out Details

This was the main component that I designed for this feature. In the theme of making dependency relationships clear and educating users “is this safe to delete”, we wanted to surface all related dependencies that are attached to a field whether it the slide-out was accessed on the base or within this new Field Management surface.

The dependency slide-out evolved over time as we had more conversations with the internal teams and with customers.

Highlight: A new surface for managing at scale

Before this feature, bulk actions were limited within the base view. Fields were organized horizontally which made single or bulk select difficult.

With this consolidated vertical table view, users can sort through and have an improved experience single or bulk editing a field.

Highlight: Field relationship details

A high level side panel experience showcasing field details and relevant relationships on this surface.

Impact
This feature was delivered in early 2022 and ever since then, the team has seen:

• Lead to a ~25% improvement in task efficiency when making changes on the new field manager surface

From community wise, we’ve seen customer praise across the Airtable community for this much needed feature.