Raising the (table) stakes on tables in FigJam

Today we're introducing tables in FigJam to help you roadmap, plan, and organize information more effectively. Here, we sit down with the Figma product team to learn how they arrived on an approach, tackled multiplayer bugs, and finessed design details to come up with a feature that feels uniquely FigJam.

The first time people designed a grid to contain and understand information, they were drawing on walls and clay tablets in Mesopotamia. Tables like these were used for purposes as complex as inventorying property, navigating across oceans, and charting celestial events for thousands of years before software was even a twinkle in Bill Gates’s eye. From Excel’s debut in 1985, to the launch of Google Sheets in 2006, tables have proliferated in tools like Dropbox Paper, Airtable, and Notion in recent years, but haven’t changed much in all that time. It still comes down to columns, headers, and alignment to highlight relationships between text or numbers; the building blocks continue to be robust and effective for our categorization-loving human brains.

The Figma product team knew the moment had come for a table feature in FigJam when they saw their own internal teams regularly hacking them together with stickies or shapes in the quest to plan, roadmap, and even run meetings more effectively. So why did the product team seemingly… table it… for so long? It may look like a straightforward series of boxes and lines, but making a multiplayer table is actually pretty complex. The team wanted to support the simplicity and user expectations of the humble table, understanding that many prospective table users in FigJam will not be a designer or engineer.

Table settings

What should tables actually solve for?

When it came to scoping the feature, there were so many possible directions (and levels of complexity) to choose from. Should there be functionality to manipulate data, or should tables stay true to their simplest form? What would it mean to prioritize equally the experience for both the table “creator” (the person populating the table) and “user” (the person consuming information)? And how would support for different zoom levels factor in, along with multiplayer editing from an engineering perspective?

“Part of the joy of FigJam is that it’s fairly simple, especially compared to Figma,” says Jessie Alvarez, the lead engineer on tables. For PM Conor Woods, it all comes down to how people use FigJam. “FigJam isn't the tool that people go to for complex data manipulation,” Woods says. “It's more about visually presenting information in a way that's super digestible and easy to change over time as a project evolves.”

Visually presenting information is core to many of the cross-functional table use cases the team sees on a daily basis: PMs lay out feature requirements and their respective priority in a PRD; project owners track progress on plans; product marketers write up messaging hierarchies for feature launches; designers collect feedback in crits; brainstorm facilitators enumerate ideas and tally votes.

The team knew that building tables natively would be a huge improvement to the ad hoc solutions they were seeing in files—and performance would be better, too—but, with those use cases in mind, they didn’t want to over complicate FigJam’s table feature. The user needs were pretty straightforward: make it clear, make it easy, make it editable by everyone.

Both sides of the table

The table “creator” and “user” are equally important

PMs, PMMs, designers, and just about anyone else can use tables, but there are only two ways to interact with them: Create a table or edit an existing one. When it came to architecting tables, these two behaviors were given equal weight. For table creation, designer Jakub Swiadek leveraged a flow that already works well for other features in FigJam: One click in the toolbar creates a pre-styled new element. That way, creators don’t need to spend time worrying about tweaking colors, fonts, or spacing. They can always switch up the colors, but there’s a limited palette to choose from and the whole table gets styled together to make sure its contents are clean and legible. “When you add a new row or column, we derive the styling from the previous row or column,” says Swiadek, and if you change the color of the table, the text inside automatically adjusts for maximum legibility.

Supporting only native styles meant that Swiadek could get really picky about the UI that separates and highlights cells and headers, too. He explored tons of design approaches for the lines between cells, trying to get them to delineate space without adding visual noise. He decided to have the table programmatically draw strokes on some edges and not on others so the lines end up looking uniform, even if they’re inconsistent.

Roundtable discussions

Design and engineering decisions required tons of iteration and testing

Tables can have nearly limitless cells, all of which can be touched by a different user at a different zoom level, all at the same time. That makes it pretty different from other parts of FigJam. “Usually if two changes to the same element happen at the same time, whichever one hits the server second wins,” explains Alvarez. “But for a table, it's hard because we need to actually merge some of those changes together.”

For instance, imagine a collaborative retrospective session with everyone throwing ideas into the table—if one person starts typing in a cell and two more add their own edits, the final text that shows up should incorporate all those contributions. Alvarez and the team spent months working through bugs and edge cases so that tables could support the multiplayer editing that’s so core to Figma and FigJam—multiplayer accounted for at least half of engineering time on the project.

FigJam’s multiplayer functionality also brought challenges to the design side of the table. Swiadek needed to revisit the FigJam standard pattern for editing, for example. With other FigJam elements like shapes or text, editing UI appears when a user selects the element. That works great for elements where only one user can edit at a time. But what happens if multiple users select multiple table cells on multiple tables at the same time? Swiadek and the team tried lots of different interaction patterns. (Alvarez even created a script to write “FigJam” over and over to simulate a second “player” for testing.)

For internal testers, on-click editing UI like those used for other FigJam elements felt seriously overwhelming when more than one person was editing. Who was working on what and which elements were “active?” It was too hard to tell visually—especially at distant zoom levels.

The team decided to diverge from FigJam standard element behavior in two ways. First, the table editing UI appears on-hover only, following the user’s cursor. If the user mouses over the table, one large primary button appears to add a full new column or row. Second, the table interactivity changes according to a user’s zoom level. That way, only the necessary functionality is visible and the UI doesn’t end up cluttering the screen. “If you're zoomed far away, you can move the table around and rearrange it in relation to the other things on your FigJam board,” explains PM Woods. “As you zoom in, you'll find that you can do more with the table itself: resize it or add rows or columns.” The goal was to meet the user where they are and make creating and editing a table simple in the tool—even if the process for getting to the solution was a windy road of prototypes, tests, and bug bashes.

Pull up a chair

What’s next?

The team is keen on upping the ante on tables. Now that the feature is available in FigJam, table content beyond text is on designer Swiadek’s mind. “We want to give a lot of attention to what we call parenting—placing other FigJam elements inside of a table,” he says. That would mean that a sticker or stamp could fill a cell of a table in the future. For now, users can still place non-text objects inside a cell, but they just won’t scale or move when the table does.

The great and enduring thing about tables, says Swiadek, is “they're not meant to be those revolutionary paradigm-shifting experiences. They're supposed to behave the way you expect them to”—whether that’s roadmapping, connecting as a team, planning and tracking progress, or just having some fun.

It shouldn’t be that complicated, even many millennia later and despite some very different tools—and tons of behind the scenes work. Visually laying out ideas with other people should still feel as simple as drawing a few lines in wet clay.