Can You Spread it on Toast?: Thoughts on FigJam

Recently, a friend told me about a coworker of his who got fired because they didn’t know how to use Figma. They were a senior designer at a B2B SaaS company (lol) for several years. I’m doubtful that this is just a bit of office drama. An incident like this reveals something fundamental about what happens when mastery of a tool becomes inseparable from mastery of a craft. When a tool becomes so dominant that not knowing how to use it can be grounds for termination, it might be a productive time to discuss function and fluency.

What makes a creative tool truly essential? It's not just about market dominance or feature sets. There’s something about empowering a user to achieve fluency with a tool and also leverage it for collaboration that makes it really impactful. This is true of tools ranging from software to cookware to musical instruments.

As a PM who lives primarily in docs and spreadsheets, I find myself in a more distant position from this tool-craft conflict. I'm expected to collaborate in Figma daily, though I feel more like a tourist than a resident. The way I typically use Figma is by commenting on designs and requesting pans and edits during Zoom screen-shares. I can't quite make the tool sing. The question I have isn’t whether I should become a PM who’s better at using Figma – it's whether the tool should adapt to different forms of creative expression.

Figma seems to understand this tension. FigJam, with its role-based templates, hints at a future where different types of creators can coexist. But templates alone aren't enough. What we need is something more fundamental: a recognition that different roles have different forms of mastery.

Different functions need different things:

• Designers need precise control over visual details

• PMs need fluid ways to organize and communicate requirements (and ideally ways to export these into PM-specific software)

• User researchers need tools to capture and analyze patterns

• Engineers need clear specs and component relationships

Each role has its own form of mastery and its own way of thinking visually. The challenge isn't making everyone a designer; rather, each role ought to achieve fluency in its own domain while working in the same space as the next.

Beyond Accessibility

The risk, as with any dominant tool, is that Figma could become like Confluence – too essential to lose but too frustrating to enjoy. When tools become standards, they often sacrifice depth for accessibility. But there's another path.

Instead of flattening the learning curve, Figma could:

1. Enable Role-Specific Mastery

• Different interfaces for different needs

• Tools that match each role's mental models

• Progressive complexity that grows with expertise

2. Create New Standards of Fluency

• What does PM mastery in Figma look like?

• How can researchers express insights visually? (This is something I struggled with constantly as a user researcher)

• What interfaces would let developers bridge design and implementation?

3. Allow for Evolution

• Tools that learn from how they're actually used (AI applications)

• Interfaces that adapt to different workflows

• Features that emerge from behavior rather than prescription

The Future of Creative Work

We're at an interesting moment in how teams create together. The distinction between "design tools" and "collaboration tools" is blurring. Each role in product development needs its own form of expression and its own path to mastery.

The goal isn't to make Figma simpler – it's to make it more richly complex in ways that matter to each user. Different roles should be able to achieve virtuosity in their own domains while working in a shared space.

Until then, I'll be here, trying to figure out auto-layout.