Designing a LEGO kit for software
Jul 21, 2021

Designing a LEGO kit for software

An analogy for how Airtable’s design team thinks about our work

Yes fine these are DUPLOs, but the analogy works better with LEGO.

My son turned 2 during quarantine, and entered his LEGO phase. Against the competition of modern sound-and-light-emitting toys, it’s a marvel that LEGOs have remained an enduring fascination for kids. Produced since 1934, these simple shapes provide a timeless canvas for creativity through their universal composability:

Lego bricks from 1958 still interlock with those made in the current time… Six bricks of 2 × 4 studs can be combined in 915,103,765 ways [source]

Kids and adults can be inspired by fully realized creations that others have made, start a new creation from scratch, or mix-and-match pieces from different sets to create something entirely new.

At Airtable, we want software to be as flexible, creative and powerful as LEGO. We think about software as a similar “kit of simple building blocks” which click together to make almost anything imaginable. All the software we use in our lives is a combination of roughly similar components: a way to store data, a website or app to show that data, and some rules for what should happen in the app and when.

But today that ability to build is available only to people who know how to code. Our work at Airtable is to create a simple interface for each “building block” in software engineering, so anyone can create what they want without code.

What kinds of building blocks are we talking about here?

With LEGO, there are different categories of blocks: bricks, plates, trees, dinosaurs, etc. What’s the equivalent for software?

We look to the field of software engineering for some frameworks. Code-based software is typically broken down into three main pillars: model, view and controller:

We make building blocks in each of these categories:

  1. The model — This is the heart of Airtable, the original “database that looks like a spreadsheet.” Each of the key objects in a business (people, projects, assets, etc) get their own table, with fields representing important properties of each object, and linked records defining the relationships.
  2. The view—The interface we present to users. In other software we use, we’re not asked to open a database terminal to make changes; We’re given a custom UI tailored to our needs and abilities. (I’m partial to this one, because it keeps designers employed.) In Airtable land, we call these Views, a page with a dedicated slice of the data and UI paradigm (list, card, form) for a specific type of user to do a specific task.
  3. The controller—The brains of software, or the logic. These are the rules and processes that take all that nicely stored data, make changes that the software needs, then sends it to the right UI at the right time. Our main logic feature today is Automations, for specifying triggers and actions to manipulate data. (More about the controller in a moment.)

This CS101 is a helpful conceptual framework, but it’s not product design. What does our design team actually do?

Airtable is a tool for making tools.

People use the tool of Airtable to make other tools that solve problems in their lives and organizations. While MVC is a useful way of understanding the tool part, it doesn’t have much to say about the problem part. Get too deep in the theory and you lose sight of the purpose, or as they say in business schools: “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.”

So as designers at Airtable, we’re asking ourselves:

  • What are the universal types of problems that people want to solve with software?
  • Why is it difficult to make software that solves those problems today?
  • What types of building blocks does someone need to make software solve these problems?

We use these questions to choose the right building blocks, then design an abstraction and interface to each block make sense and fit together well with other pieces (just like LEGO). Then rinse and repeat for new blocks.

Deep dive on the “logic” layer

I lead our Platform Design Team, where much of our work focuses on the controller layer. We know that software has “logic” and “brains” but — so what? What kinds of real human problems can be solved with this logic?

Below are a few specific examples of the types of problems we are interested in making new blocks for. (And because I wouldn’t be writing a Medium post about work unless I was recruiting: We’re hiring designers to lead each of these areas.)

Workflows

The world’s most impactful projects require people working together, often through an intricate series of work handoffs through time and space. Done well, this adds structure and predictability to the messy process of human collaboration.

But it’s hard to do it well, especially at scale. How do organizations coordinate this work when it gets too complex? In the analogue world, people use flowcharts, which work for a while until you discover that the Pentagon needed this for understanding their procurement process:

Source

This is surely too much complexity to understand, much less make thoughtful optimizations and improvements.

Can we do better with software? We’re asking ourselves:

  • What are the right mental models for specifying a complex collaborative process? How might we visually represent a process, how data moves through it, and how people participate in it? Is the flowchart right, or can we do better?
  • If it was a flowchart… what might an “interactive flowchart” look like, that both defined a process, showed how data was moving through it, and included the people working together on that process?
  • Airtable’s model layer (the database that looks like a spreadsheet) is delightful in part because of its direct manipulation, a feeling that the data is tangible and collaboratively editable in realtime. Can we bring the same feeling to process?

Connectivity

Most interesting insights don’t come from a single data source. For example, if you’re Meow Wolf and you’re building an immersive physical art space, you’re looking at data spanning “exhibitions, characters, scripts, merchandise, and more‚ [and] ‘some way of gauging how they are connected across mediums, divisions, and formats.’” But today the average company uses 1200+ cloud services, so simply finding the right data and making the connections can make you feel like Charlie:

The red lines are SSO authentication

We’ve built some powerful underlying Sync technology to automatically import data from many external services (or other bases in Airtable), apply the structure of a relational database, and make it available for exploration or manipulation. Now we’re thinking ahead to what interfaces can be built on top of this technology:

  • How might people canonicalize and discover valuable data sets within their organizations? e.g. A single official list of the art installations, and required materials, across a distributed organization.
  • How might people combine data from multiple sources? E.g. Start with my company’s travel plans in 2021, and add a column showing COVID rates in the last 14 days in their destination county. What interfaces are needed for linking complex data?

Formulas

One of the most basic problems people want to solve with computers is “take this data, and transform it into another piece of data.” For decades, software has let people do this with formulas. Formulas are the OG low-code, one of the very first ways that non-developers understood the flexible, manipulable software. It’s like the math you learned in school, only it does more.

Visicalc (1979), MS Excel, Airtable. Notice anything familiar?

Yet despite nearly 40 years of incredible developments in the usability and sophistication of software, formulas work pretty much the same as they did in the Carter administration. Not only that, they aren’t even as popular as you might think: Only 7% of Excel spreadsheets contain formulas.

So we’re starting to ask: What opportunities exist to make step function improvements in the usability and power of formulas? We’re just embarking on this work, but here are some very early ideas we’re pursuing:

  • Is there a better syntax than what exists today? Functions and cell references (i.e. SUM(A2:B4)) were forged in an age before modern web UI’s. Can we provide a more intuitive and delightful experience, that uses a larger canvas, more interactivity and direct manipulation rather than typing out a math problem? Alternatively, can we teach people how to use formulas through better UI/UX?
  • Right now all formulas are universal (everyone wants the same answer from SUM), but could there be user- or organization-specific formulas? E.g. a project manager planning deadlines might say isThisDateACompanyHoliday()?
  • There are countless APIs across the web, providing realtime information in many domains. Yet accessing them today requires a fair amount of technical understanding. Could formulas bridge that gap, by bringing data directly into a database? A film crew planning a shoot could say chanceOfRainTodayAtLocation(), or a financial planner might ask hasBitcoinCrossed40k()?

Similar posts you might like