Explore

Design and engineer collaboration: Building powerful tools at Coda.
Design and engineer collaboration: Building powerful tools at Coda.

How design and engineering collaborated at Coda to build Packs Tables.

How design and engineering collaborated at Coda to build Packs Tables.

Helena Jaramillo

Here at Coda, we're working on building a new type of document that empowers people to leverage the power of computing.

As part of that goal, I had the pleasure of designing on the team that built

Packs Tables⁠

last year ー a Coda building block that allows you to pull in live data from apps straight into your docs (scroll to the bottom for an example). This feature exemplifies a lot of the most interesting challenges Coda faces. In order to build it right, the whole team had to closely collaborate: engineering, design, and product.

⁠

Recognizing multi-disciplinary challenges

Building a new feature always has its challenges. Usually, the challenges come in one of two forms: engineering challenges and product challenges. Most features are fortunate enough to only be really challenging on one side of the equation. When the challenges are mostly technical, you may hear product people saying things like 'why can't we just make this work?'. On the flip side, you'll often hear engineerings say things like 'Why is this so hard? Can't we just make a decision and move on?'

The real challenge comes when a feature has great complexity on both the product and engineering side—this is where the rubber meets the road for product teams.

Good solutions often come from someone or a group of people working within a set of constraints. For example, an initial brainstorm by engineering may result in three options. Product constraints might actually make all three options unappealing. Once the engineering team internalizes these constraints, a fourth option may emerge that is informed by these constraints.

The problem is, you need to understand all the constraints you're operating under to come up with the right creative solutions. If no one on either side has a good grasp, you may miss the solution that threads the needle, since the right solution may not come out from just the product constraints or just the engineering constraints.

⁠

Technical challenges: Working with APIs

When conceptualizing and then building Packs Tables, the engineering and product challenges were quite clear. The user problem we were trying to solve was:

How can I organize and manipulate my own data from apps all in a doc?

On a systems level, we needed to build something that worked with many APIs ー like those from

Gmail⁠

Spotify⁠

, and

Intercom⁠

. We wanted flexibility in which information was synced, but we also wanted to make syncing fast.

Although APIs are built and designed for developers, we wanted anyone to be comfortable using Packs Tables. We wanted to give the ability to work with APIs — something that is generally limited to engineers — to any maker. To do this, we needed to create a UX over API sync predicates that made sense to non-engineers and articulated the difference between Packs Tables and other tables. And, of course, we also faced the challenge of making Packs Tables fit seamlessly with Coda's existing building blocks.

While some products can be designed without much technical knowledge, the nature of Packs Tables required granular knowledge about APIs. I needed to understand how APIs differed from each other and what a consistent connection to each API might look like for Coda users.

Design challenges: Building building blocks

At Coda we like to say that we "build building blocks," which means that we build composable features and tools that allow makers to use them and combine them in ways that we didn't even expect.

That means that, at Coda, the features we build are often less focused on one specific use case but rather focused on flexibility, composability, and simplicity.

Packs Tables was no exception. For example, the question "How do you easily view you Google Calendar events in a doc?" would have led us to a different solution than "How do you easily pull in data from a variety of apps into your doc?"

We also had to make sure that the Packs Tables were built on top of existing blocks — in this case, they are built on top of normal tables. So for the most part they work like a normal Coda table; you can add columns to the table, filter the table, etc.

One challenge we ran into here was the API predicates, which are the criteria you give to the API so that it knows what information to return. For example, the Google Calendar API requires an "account" as well as "date range" to return Events from that account and time frame. This felt a bit like a "filter" which tables also have, but this was different in that the API was specifying a set of information rather than narrowing down. At the end of this process of discovery, we decided to keep the table filters as they were and build API sync configurations on top of the table itself.

⁠

White-boarding with myself and engineer Gil!

Collaborating to come to a solution

For this project, it wasn't enough for engineering to write up a proposal and send it to product for review, or vice-versa. We needed everyone to have a full understanding of the problem because we knew that the feature required a thoughtful threading-of-the-needle between product wants and technical constraints.

So, how do you build the kind of understanding between product and engineering that results in thoughtful, innovative features? From my experience, you need a small group of people with expertise from both sides to brainstorm in concert until everyone involved has a thorough grasp on the relevant context. Then, and only then, do true creative solutions emerge.

While building Packs Tables we collaborated closely through these methods:

Daily brainstorms between myself, the designer, and Gil, a key engineer on the team. During these brainstorms, we'd each come in with ideas on how to solve the problem at hand that day, and we'd whiteboard those ideas. Together we'd raise questions about each idea and eliminate options based on our knowledge.

Team syncs focused on the most important questions. Once or twice a week, Gil would write up the most fundamental product and engineering questions and bring them to our broader engineering team. For each question we'd have a set of written options and sometimes mocks as well. Using this information we had informed discussions with the team and make key decisions.

Further down the project we also relied on user testing and user interviews to test early prototypes of Packs Tables. For each of these sessions I was always present with Gil or Glenn, the PM. This allowed us to admit when we didn't have an answer, and then seek it out through gathering feedback.

Next time you're working on a multi-disciplinary challenge, we hope these lessons can help you out!

⁠

An example of a Packs Table

This table is pulling in my all time top 5 tracks from Spotify. I connected my Spotify account and set some filters on the table to only pull in my top 5. You can also

copy this template⁠

to try it for yourself.

My all time top 5 tracks

My all time top 5 tracks

Not synced yet

Album Image

Artist

Track

Album

The Walkmen

We've Been Had

Everyone Who Pretended To Like Me Is Gone

Alex G

Proud

Rocket

Rilo Kiley

A Better Son/Daughter

The Execution Of All Things

Department Of Eagles

Too Little Too Late

No One Does It Like You

Frank OceanJAY-ZTyler, The Creator

Biking

No results from filter

⁠

This was co-written by

Helena Jaramillo⁠

and

Gil Goldshlager⁠

Cover Photo by

Paweł Czerwiński⁠

Unsplash⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.

Design and engineer collaboration: Building powerful tools at Coda.Design and engineer collaboration: Building powerful tools at Coda.