Question of the Week!

[Laura_McCarthy]

Hope everyone had a fantastic weekend!

We're launching our first ever Question of the Week. To kick off, we'd love to hear what is one thing you wish you knew when you started using Airtable? Please share in the thread below. Look forward to reading through your responses. 

Let us know, and have a great week!

Airtable Community

[Ben_Young1]

Okay, I'll bite.
The one thing I wish I knew when I first started using Airtable is how to think about and approach data design.

In my time working with Airtable, I've laid eyes on an immense number of bases. Along with those bases has come a scary amount of data. After spending so much time looking at data, thinking about data objects and the relationships they share between one another has become second nature.

First... Some Context

Airtable is really easy to get started with. When you're first starting to engage and work with data in Airtable, it's a fairly pleasant user experience. We can attribute that to the visual friendliness of the Grid View, one of Airtable's strongest opening appeals.
But when it comes to users just getting started, the Grid View is also one of Airtable's harshest weaknesses and is probably one of the biggest inhibitors to the average user sophistication score of Airtable's users, and that's including enterprise users.
The Grid View encourages a curious user to apply spreadsheet thinking to databases. Here's something I see a lot...

Over the past two quarters, an exciting and young startup has seen an explosive amount of growth in their business.
The team was just getting by on spreadsheets and maybe relying on other collaborative platforms to just keep track of things as they happened.
Now that their growth and capacity has become stable again, they're realized that spreadsheets are now holding them back. It's impossible to properly onboard new team members and all that data tossed into the countless spreadsheets, documents, and decks might be used during daily operations or in other business critical functions.
In an effort to adopt a more data driven approach, their leadership team has started to apply pressure on the company to create a reporting mechanisms to enable KPI analysis and pipeline visibility.

In a fit of desperation and sleeplessness, one of the team members finds Airtable. This person usually goes on to become the Airtable champion within the team.
Soon, they're moving everything into Airtable. Not only are they excited, but the company is becoming excited about Airtable as well.

The Aftermath of Poor Design

Let's jump to three months after adopting Airtable. They're frustrated.
Maybe there's too many bases. Maybe too many tables. More than 70% of the fields on any given table are being left blank. They have countless automations that they've put together but none are working as intended. Most aren't even working at all.

Those aren't even the causes of the true frustration. The biggest pain for this company is that they know that all the things they want to do with Airtable are possible. They've seen the videos, guides, examples, and even walked away feeling more confident than before after seeing what an SE was able to demo to them.
Every time I've seen this scenario play out, I always notice the same glaring indicators that they didn't analyze, optimize, and clean their data before attempting to transition it into Airtable.

My favorite indicator is that their tables look like this: 

Don't get me started on when I see a table named "Master Tracker" or "MASTER SALES TRACKER" or a base named "Master Tracker Base".
If they've tried establishing relationships between tables, it gets even worse.

At a glance, your data should tell a story and it should be semantically friendly.
I take that sentiment literally. In fact, whenever I'm about to build something within Airtable, my first step is to close Airtable and open up a diagramming tool.

Look at the last diagram. Despite having seen this type of schema in countless bases, I will never be able to understand what any of the data is unless someone walks me through what we're looking at. This is a problem. You should be able to look at the diagram and get a holistic, complete look at the "story" of the data. Where it flows, how it relates, and what each thing (object) actually is.

The most common response I receive to this goal is "Our data is just so complex and interwoven. I don't think that's possible to do with our data."
I'd be willing to guarantee that the primary issue isn't the data. It's more than likely that you and your organization do not actually understand the relevant processes and workflows. The Airtable peeps' (dearly missed) ex, @Aron put out a really solid piece on this very concept. It's a quick read and worth contemplating if you or your team are struggling with this.

Okay. Cool.
So What Does Optimization Look Like?

Think about your workflow and your data. Now think about each thing or entity that exists in your data.
The results of that exercise will bring you the answer on what your tables are. Remember that previous diagram? Here's what it would generally look like:

Pick an object (table) and then pick a connector. No matter where you start from, the story always flows. Not only does the data make sense, but it falls along the same lines as each of your team member's workflows.
Here's an example: a team member can be assigned to many tasks.
A task might be any sort of sale activity. Maybe you need to send a follow-up email to one or more contacts, or maybe you need to finish qualifying an account lead. You could have a task related to more than one object. You might have a task to finish an estimate report for a sale that will go to a specific contact.
A sale is related to an account, which might have one or more contacts related to it, etc.

Remember all that reporting that the leadership team wanted? With a few well placed rollups and formulas, you have what you need to generate automated reports or visually engaging, data-rich Interfaces.
Every field has a purpose. Not only that, but each table only contains data that is relevant to a given record. There's no bloat.

I commonly observe people feeling uncomfortable with having multiple tables and establishing relationships between them. For example, it feels weird to a lot of people to commit to a table to contain team members. They usually gravitate towards a single-select or multi-select field instead. Sure, it works in isolated instances, but what happens if you now need to store that team member's email address for an automation? What if you need another single/multi-select in another table?
Now you're forced to either double down on your tech debt or write a strange and impressively long SWITCH() function that nobody except the person that wrote it can update.

Don't be afraid of creating tables.
If five tables makes you uncomfortable, take a peek at some examples of scaled enterprise-grade relational databases. You'll be horrified to find table counts ranging into the hundreds (if not more.)

Destigmatize Complexity

Your work, your company, your workflows, and your life are complex.
Therefore, your data is complex. It will always be complex.
Do not try to force simplicity onto that complexity. Aim instead for organization and structure.

Airtable Interfaces become absolute beasts when you've respected the complexity and focused on structure over form. I'm at the point where I am always striving to push my builds and deliverables with the goal of facilitating an Interface-exclusive user experience.
Don't get me wrong. There's a remarkable amount of nonexistent features and a gross lack of customizability.
Despite those deficiencies, you can build some dazzling frontend experiences for your users (or yourself) with some creativity.

[Laura_McCarthy]

Hi @Ben_Young1 ! 

Thank you so much for taking the time to write such a thoughtful response and mapping all of this out. Above and beyond our expectations for Airtable’s inaugural Question of the Week! Check your DM for swag. Much deserved 😊

To your point on data setup, we love the way you're thinking about optimization and how teams should map out and visualize how their data works together to help them build correctly from the jump.

We also think you are spot on about facilitating interface-exclusive experiences for your team members who don't need to be in the complex data.

Lastly, we shared your post with a few different teams in Airtable as inspiration for future content, education, and even product build ideas for them to noodle on.

Hope you enjoy the rest of your week! Thank you again 🙂

Laura