Behavioral product strategist and gamification designer. This is my public hypertext notebook, sharing my thinking in motion at various stages of development.

Home

Why isn't FigJam on the same canvas type as Figma Prime?

If I were Figma, I would have designed FigJam as an on-ramp to Figma. I like to Provide a smooth learning curve from new user to power userProvide a smooth learning curve from new user to power user
Apps built for power usage are capable of so many things that they can't be learned in a day. This points towards the necessity of Continuous onboarding - if we tried to shove all of that information down the user's throat too early, they would just get intimidated and quit.

Given that I'm working on the onboarding for GuidedTrack, I'll talk about how we're creating a smooth learning curve. If a goal is Removing GUI elements as the user's skill level increases to allow the user to interact m...
through Continuous onboardingContinuous onboarding
Horizontal products like Notion, Airtable, Excel, and Obsidian are all powerful/flexible and require learning and expansion of use cases over time to wrap your head around them. Given that, why do they only teach people how to use the app for the first few minutes?

It's not just horizontal products though. Continuous Onboarding applies to most apps that aren't just "open, press a button, and close." Are you continuing to add features over time that would benefit users that are more than a mo...
(rather than attempting to frontload all of the education on a Horizontal productHorizontal product
Definition: Horizontal products can be used by all sorts of people for many different purposes. A vertical product, by comparison, is meant for a specific set of use cases. Most horizontal products are just fancy data structures.

For more details, see Joel Spolsky, the founder of Trello discussing horizontal products.

Another concept that I want to point to here is just the idea of horizontal products having a low floor, wide walls, and a high ceiling. The basic idea is that it should be ea...
). I probably would have compromised just a bit on ease of initial use to ensure that using FigJam would help instill some of the basic mental models for Figma. New users get started with FigJam to have a faster whiteboarding experience, but User skill level increases over timeUser skill level increases over time
Imagine that you have just started to use Excel or Photoshop. Both of those apps have an insane amount of functionality, and it would be unreasonable to expect the user to understand what is possible and how to do it immediately. Over time, with continued User Involvement, they will simply grow more comfortable with the app.

The most successful app adoptions come from a project, because they give the user a reason to increase their skills. As they work on their projects, they'll bump up agai...
. Through progressive disclosure, we expose new users to advanced functionality as they demonstrate their readiness. Alternatively, I would have provided an escape hatch to full Figma functionality within FigJam boards. This would allow FigJam to be a separate safe space for people who would be intimidated by Figma's full features, but still enable people to ramp up when they hit the ceiling of what FigJam can do.

However, I am not them, and I did not participate in any of their product research. I thought it would be a good exercise to think through why they might have made this decision.

Maybe they view the role of the whiteboard as different. The whiteboard isn't for creating stuff or fiddling with the details. Having access to full Figma functionality would promote an antipattern of user behavior. Teams should just throw stuff on it to discuss.

The fact is, some of the things that we see FigJam doing conflict with Figma's design. In Figma, things are generally manual, which makes sense for design professionals who want control over their output. If I were to make a "sticky note," I would make a frame, add some text in with auto-layout, and turn it into a component. In FigJam, that's all automatic. Shapes with text and dynamic arrows makes sense for a tool built for people who don't want to learn how a tool works.

It could be the case that new users (particularly non-designers) are intimidated by all of the powerful features and heavy graphical user interface of Figma. Any exposure to Figma functionality would stop FigJam users in their tracks.

Since drafting this note, a couple people from the team have responded to my questions. Sho Kuwamoto mentioned to me in the chat during ConFig:

We wanted to make sure we really treated FigJam as a separate tool for a separate audience. Now that its personality is starting to shape up, we will think about how to best merge those experiences together in an appropriate way.

This seems logical. I mentioned earlier that I probably would have made design decisions such that FigJam imparts the basic mental models of Figma onto its users. It sounds like the people working on FigJam didn't want to be tied to Figma's decisions given that the user base will include even more non-designers. It seems like they were trying to solve a few problems: meetings, brainstorming, and receiving design feedback from people who aren't familiar with design tools.

Emily Lin mentioned to me on ProductHunt:

One of our top priorities was to make FigJam a really easy tool for anyone, not just people who are familiar with design tools, to use, since ideation and brainstorming happens with entire teams. This led us to a separate and simplified space that puts the focus on the content and ideas. That being said, we believe there’s a lot more we can do to take advantage of the Figma<>FigJam relationship and are thinking a ton about this. Let me know if you have any specific thoughts! :)

Here are my early thoughts :-)

I will just add that the decision made by the team will actually make it a really solid workshop facilitation tool. Before I would just make a bunch of components in Figma (sticky notes, hacked together with frames and text with auto-layout), tell people to use those, and give them five minutes of instruction to teach them about the functionality needed to participate. With FigJam, I can cut that down to two minutes.

I suppose that's part of why I would be willing to compromise just a bit on immediate intuitiveness to build general Figma mental models - if I'm already making components ahead of time, the difference in what non-designer participants need to learn isn't that high anyway. However, if they just upgraded Figma and made FigJam type functionality the initial experience for many users, then everybody would be better off from a quicker way to get material onto the whiteboard and interact with each other in real time.

I'll also add that someone discovered that you can copy-paste connector lines from FigJam to Figma (something I was previously using Autoflow for but that was brittle), so perhaps the interoperability between the two runs deeper than I thought.

At the end of the day, I get their decision and think it's reasonable, but still disagree.