What I learned founding a Figma design community in LATAM

How building a 500+ designer community across Latin America on Discord taught me about open collaboration, shared knowledge, and the compounding value of giving freely.

communityLATAMFigmaopen sourcedesign leadership

When the pandemic hit in 2020, most of us went remote overnight. For designers in Latin America, that shift exposed something that had been true for a while but easy to ignore: there wasn’t an active community for the kind of designer I was—product designers, design engineers, people working at the intersection of design and technology in startups and product companies. The communities that existed were either too broad, too passive, or focused on topics that didn’t match what I wanted to discuss. I didn’t want another portfolio-review group. I wanted a place where designers could talk about the real problems: shipping product in fast-moving teams, navigating ambiguity, working with engineers, building systems that scale. So I started one. What followed taught me more about leadership, community, and open collaboration than any professional role I’d held up to that point.

Why the LATAM design community had a gap worth filling

The Latin American design ecosystem in 2020 was more mature than most outside observers assumed. Significant design talent existed across the region—strong visual designers, emerging product designers, and a growing cohort of designers working in startup and tech company contexts. But the community infrastructure that would let that talent connect, share knowledge, and support each other was fragmented.

Most design communities in the region were national, not regional: designers in Mexico knew the local scene, designers in Argentina knew theirs. Cross-country visibility was low. A designer in Guatemala working on a hard product problem didn’t have an easy way to find peers in Colombia or Brazil who’d solved similar problems. Language wasn’t usually the barrier—most product designers in the region work in English, and most of the regional discussions happened in Spanish, which is a shared language for most LATAM countries. The barrier was structural: no shared space.

There was also a specific gap for the design-engineering hybrid profile I was building. The communities that existed skewed toward visual design, portfolio work, and junior-to-mid career practitioners. There was almost no community for senior product designers and design directors who wanted to discuss engineering collaboration, design systems at scale, AI workflows, and infrastructure. I was the target audience of a community that didn’t exist.

How I set up the community: Discord, live events, and the structure that worked

The setup was deliberately simple. Discord as the platform—active, familiar to the tech community, and with enough modular channel structure to organize different types of conversations. Friends of Figma as the organizational umbrella, which gave the community instant credibility and a ready-made framework for live events.

The channel structure I set up:

  • #introductions — required for all new members to introduce themselves: current role, what they’re working on, what they want to get from the community
  • #jobs — job postings and opportunities, both LATAM-based and remote US roles
  • #design-critique — work-in-progress sharing for feedback
  • #tools-and-workflows — tooling discussions, Figma tips, AI tools, process questions
  • #engineering-collab — design-engineering collaboration, git, code, technical topics
  • #community-events — event announcements and recordings
  • #general — everything else

The introductions channel was one of the best decisions. Having a structured introduction moment for each new member created a consistent onboarding experience and made the community feel like a place where people knew each other, not an anonymous forum.

The live events were the heartbeat of the community. Bi-monthly sessions on Discord or video, open to all members. The format: a 20-minute presentation or walkthrough of a design problem or project, then 40 minutes of open Q&A and discussion. The rules were minimal: all questions were welcome, anyone could answer, and the only expectation was showing up ready to help each other. No gatekeeping of “is this the right question for this space.” If someone needs to ask it, it’s the right question.

What running the community taught me about open knowledge

The most surprising thing about running the community was what happened to the knowledge flows. When you create a space where sharing is the default norm, and where there’s no competitive incentive to hoard knowledge, people share remarkable things freely.

Senior designers shared their actual design processes—not polished case studies, but the messy reality of how they work. People shared job leads with competitors. Experienced designers spent hours helping junior members work through problems they’d solved years ago, with no compensation and no agenda. Companies that were technically competing for the same clients shared knowledge about tools, workflows, and processes.

This dynamic has a name in economics: the knowledge commons. Knowledge is non-rivalrous—sharing it doesn’t diminish it, it multiplies it. The people who understand this and build communities around it end up with far more knowledge than those who hoard it, because knowledge flows back to those who generate and share the most. In a well-functioning community, sharing is the highest-return strategy.

Running the community internalized this principle for me in a way that reading about it never could. It directly shaped how I approach knowledge sharing in professional contexts: writing and publishing about things I’ve figured out, sharing templates and resources openly, building in public. The instinct to share is a compounding strategy, not a giveaway.

What makes a design community actually self-sustaining?

Growing the community was the first challenge. Sustaining it was harder and more interesting.

A community that depends on its founder for energy and direction isn’t a community—it’s a newsletter with a comment section. The milestone I was watching for was the first time something valuable happened in the community without my involvement: a conversation that I didn’t start, a member who helped another member without me asking anyone to help, a subgroup that formed around a shared interest and ran its own activity. When I saw this happening regularly—around six months in—I knew the community had become self-sustaining.

The specific conditions that enabled self-sufficiency:

Norm setting from the start. The values of the community—generosity, technical rigor, peer-to-peer help without hierarchy—were set explicitly in the onboarding experience and modeled in every event. When the norms are clear and consistently demonstrated, members internalize them and carry them forward without prompting.

Distributed moderation. I brought in co-moderators early: designers who were active in the community and had shown they understood the culture. Distributed moderation means the community doesn’t stall when the founder is unavailable, and it prevents the “parasocial dependency on the founder” dynamic that kills many communities.

Member-generated events. After the first few months, I opened event hosting to community members. Designers who had solved interesting problems could propose and run their own sessions. This shifted the energy source from “founder provides content” to “community generates content.” The sessions run by members were often the best ones—they came from genuine excitement about a problem, not from a sense of obligation.

Low-cost contribution pathways. Not everyone can run an event or answer questions in depth. Making it easy to contribute small things—sharing a job lead, upvoting a helpful answer, welcoming a new member in introductions—created a gradient of participation that let everyone feel ownership without a high barrier to entry.

The connections the community created that lasted

The most lasting outputs of the community aren’t the events or the content—they’re the relationships. Designers who met in the community went on to hire each other, collaborate on client projects, refer each other to opportunities, and build genuine professional friendships across country borders. A community that creates durable connections between its members has produced something that outlives any individual event or conversation.

I’ve maintained relationships from the community that have influenced my professional trajectory in direct ways: introductions that led to roles, collaborators on projects I couldn’t have found any other way, peers who challenged and developed my thinking about design leadership, engineering collaboration, and community itself. The compounding value of these relationships is incalculable, and it came from a simple decision: start a space, set good norms, and be generous with what I know.

The community is still running on its own now, which is the best possible outcome. It doesn’t need me anymore—and that’s exactly what a healthy community looks like.

For how the open-knowledge instinct from the community work eventually connected to open-source contribution and the hybrid design engineering practice, the design engineer: code, 3D printing, and hybrid design practice covers how these threads came together.

For how design leadership works in the LATAM ecosystem more broadly—including what makes nearshore design leaders effective in US startup contexts—nearshore design leadership: why US companies hire in LATAM covers the structural and cultural context in depth.

Key Takeaways

  • The LATAM design community had a structural gap in 2020: cross-country connection and a space for senior product designers working at the design-engineering intersection were both missing
  • Discord’s channel structure, mandatory introductions, and bi-monthly live events with an open Q&A format were the specific structural choices that made the community feel like a place where people knew each other
  • Knowledge is non-rivalrous: sharing it multiplies rather than diminishes it. Running the community internalized this as a compounding strategy, not a giveaway
  • A community becomes self-sustaining when it has clear norms from the start, distributed moderation, member-generated events, and low-barrier contribution pathways
  • The most durable outputs of the community are the relationships—cross-country professional connections that led to roles, collaborations, and genuine peer relationships that still compound years later