Design as the creative hub: where every team does their best work

There’s a pattern I’ve seen in every product company I’ve worked with over the past 15 years: when teams need to think through something hard—a new feature, a GTM strategy, a technical architecture decision—they end up in design’s space. Not because design owns those decisions, but because design has the tools, the rituals, and the mindset that make creative thinking visible and collaborative. Design became the hub not by claiming territory, but by building a space where anyone can contribute, where ideas are tangible from minute one, and where the messy middle of problem-solving is welcome instead of hidden. That shift—from design as a service to design as the creative operating system for the company—changed how I lead teams and how I think about the discipline itself.

The whiteboard moved to the cloud, and design was already there

Before remote work became the default, the best cross-functional thinking happened in front of a whiteboard. Engineers would sketch system diagrams, product managers would map user flows, marketers would storyboard campaign ideas—all in the same physical room, all using the same basic tools: markers, sticky notes, and a shared wall. When the pandemic forced everyone remote, most teams lost that space entirely. They replaced whiteboards with slide decks and meetings with more meetings. The energy of collaborative thinking evaporated into a grid of Zoom thumbnails.

Design teams didn’t lose that space because we had already digitized it. Tools like FigJam, Miro, and Figma itself were our daily environment. We were already working spatially—laying out ideas on infinite canvases, clustering concepts, mapping relationships visually. When the rest of the company needed to collaborate remotely, the design team’s workspace was the only one that actually replicated the feeling of standing in front of a whiteboard together. So people showed up. Product managers started running their planning sessions in FigJam. Engineers started sketching architecture decisions in shared boards. Marketing started brainstorming campaigns with sticky notes and voting dots. Design didn’t take over those processes—we just opened the door and said, “The tools are here, the space is ready, come build with us.”

FigJam changed the game, but the mindset matters more than the tool

I’m a FigJam evangelist, but I want to be honest about why: it’s not because FigJam is magic. It’s because FigJam lowers the barrier to participation so dramatically that non-designers actually use it. That’s the real breakthrough. Figma’s design files are powerful but intimidating—ask a backend engineer to drop feedback on a Figma comp and you’ll see hesitation, even if they have strong opinions. FigJam strips away that intimidation. Sticky notes, stamps, drawing tools, timers, voting—it’s a toolkit designed for thinking together, not for pixel-perfect output. And because it lives inside the Figma ecosystem, the bridge between “rough thinking” and “designed solution” is seamless. A brainstorming session in FigJam can feed directly into a design file, which feeds into a prototype, which feeds into an engineering spec. The entire arc from idea to implementation stays in one connected space.

But here’s the thing: you can have FigJam in every team’s toolkit and still not get real collaboration. The tool only works if the culture supports it. I’ve seen teams where product managers treat FigJam sessions as presentations—they show up with a finished board and ask for reactions instead of contributions. That’s not collaboration, that’s a slide deck on a canvas. Real collaboration in these tools requires a design-thinking mindset: start with the problem, not the solution. Make space for divergent thinking before converging. Let people put bad ideas on the board without judgment, because bad ideas are the compost that good ideas grow from. That mindset is something designers practice every day. It’s the foundation of our discipline. And when we bring non-designers into our space, we’re not just sharing a tool—we’re sharing a way of thinking.

Design thinking isn’t a workshop—it’s an operating mode

I have a complicated relationship with the phrase “design thinking.” It’s been commodified into two-day corporate workshops with Post-it notes and empathy maps that lead nowhere. But the core principles—empathize, define, ideate, prototype, test—are genuinely powerful when they’re practiced as a daily habit instead of a quarterly event. In every team I’ve led, I embed design thinking into the regular cadence of work, not as a special process but as the default mode of cross-functional collaboration.

Here’s what that looks like in practice. When a new initiative kicks off—say, a new feature that involves product, engineering, and marketing—we don’t start with a requirements doc or a Jira epic. We start with a FigJam session where everyone maps what they know about the problem. Product brings user research and business context. Engineering brings technical constraints and system knowledge. Marketing brings market positioning and competitive intel. Design facilitates the session and synthesizes what emerges into a shared problem statement. That problem statement becomes the anchor for everything that follows. It’s not a design artifact—it’s a team artifact, created collaboratively, owned collectively. When debates arise later about scope or direction, we go back to that board and ask: does this serve the problem we agreed on?

The prototyping phase is where design’s tools become the team’s tools. Instead of writing long specs that get misinterpreted, we build low-fidelity prototypes in Figma that everyone can click through, react to, and annotate. Engineers flag technical risks early by interacting with the prototype, not by reading about the feature in a document. Marketers validate messaging by seeing it in context, inside a realistic flow, not in a Google Doc. The prototype becomes the single source of truth—a living artifact that evolves with the team’s understanding, not a static deliverable that gets handed off and forgotten.

The creative space is a leadership strategy

Opening design’s space to the entire company isn’t just about better collaboration—it’s a leadership strategy. When engineering, product, and marketing regularly work inside design’s tools and rituals, they develop a visceral understanding of what design contributes and why it matters. They see the thinking behind the pixels. They experience the iterative process firsthand. That visibility builds trust and political capital in ways that presentations and case studies never can. A VP of Engineering who has brainstormed in FigJam alongside designers understands the discipline differently than one who only sees final mockups in a review meeting.

It also changes the dynamic around ownership and accountability. When a feature is conceived collaboratively in a shared FigJam board, with sticky notes from every function, the outcome belongs to the team—not to design, not to product, not to engineering. That shared ownership reduces the finger-pointing that plagues cross-functional work. Nobody can say “design got it wrong” when they were in the room co-creating the direction. Nobody can say “engineering didn’t understand the intent” when they were clicking through the prototype and flagging issues in real time. The creative hub model distributes both the credit and the responsibility, which is exactly what healthy product teams need.

This is directly connected to how design leadership earns influence in engineering-led cultures. For the concrete day-to-day practices, how I embed in engineering teams as a design director covers the sprint rituals and collaboration patterns that make this cross-functional trust durable.

Remote-first rituals that actually work

Running this model remotely requires intentional rituals. Here’s what I’ve found works, refined across multiple startups and distributed teams:

Weekly design jams (30 minutes, open to anyone). A standing FigJam session where the design team works through a current problem in the open. Product managers, engineers, marketers—anyone can drop in, observe, or contribute. It’s not a meeting; it’s a working session with an audience. The transparency alone changes how design is perceived: people see that design is problem-solving, not decoration.

Async critique boards. A shared Figma file where work-in-progress is posted with context and questions. Anyone in the company can leave comments. This replaces the traditional design review with something more inclusive and less performative. Engineers often catch interaction issues that designers miss. Marketers flag messaging inconsistencies. The quality of the work improves because the feedback surface area is wider.

Problem-framing kickoffs in FigJam. Every new initiative starts with a 60-minute collaborative session in FigJam. The facilitator (usually a designer, but not always) runs a structured exercise: problem mapping, stakeholder needs, “How Might We” questions, and dot-voting on priorities. The output is a shared board that becomes the project’s north star. No slides, no pre-baked solutions—just collective sense-making.

Show-and-tell Fridays. A 20-minute end-of-week session where anyone—designer, engineer, PM, marketer—shows something they made or learned that week. It could be a prototype, a code snippet, a campaign result, a FigJam template. The point is to celebrate making and learning across disciplines. It keeps the creative energy alive and reinforces that the hub belongs to everyone.

How do you sustain the creative hub culture as the company scales?

This is the hardest question. The creative hub model works naturally in small teams (under 20 people) where everyone is close enough to the work that participation feels relevant. At scale, the challenge is keeping cross-functional collaboration from devolving into siloed process.

The answer is structural: the rituals need to be maintained deliberately as the company grows. The weekly design jam doesn’t stop when the team gets to 50 people—it might need a more defined structure, or it might branch into domain-specific sessions, but the principle of open working sessions stays. The problem-framing kickoff doesn’t get replaced by a requirements doc when the product organization formalizes—it gets formalized itself, as the kickoff ritual for every major initiative.

The design team’s responsibility is to steward these practices proactively. Not to impose them on the organization, but to keep offering the space, demonstrating the value, and inviting people in. The companies where design maintains strategic influence at scale are the ones where the design team never stopped opening the door.

For teams operating in distributed setups across time zones, how I structure remote design teams for US startups covers the structural conditions that keep this kind of culture functional across geographic distance.

The tools are just the beginning

FigJam, Figma, Miro, Whimsical, Loom, Notion—the specific tools matter less than the principle they enable: make thinking visible, make collaboration spatial, and make the creative process accessible to non-designers. I happen to live in the Figma ecosystem because it connects ideation (FigJam) to design (Figma) to development (Dev Mode) in a way that no other toolchain does. But the real insight isn’t about Figma. It’s about what happens when design stops being a downstream function that receives requirements and starts being the upstream space where requirements are shaped. When engineering thinks in your space, they build better. When marketing thinks in your space, they position better. When product thinks in your space, they prioritize better. Design as a creative hub isn’t about design owning more—it’s about design enabling more. And in a remote-first world where the physical whiteboard is gone, the team that builds the best digital creative space wins. That team is usually design. Not because we’re more creative, but because we’ve been practicing this longer than anyone else.

Key Takeaways

• Design became the default creative hub not by claiming territory but by building tools and rituals that make collaborative thinking accessible to non-designers
• FigJam’s value is that it lowers the participation barrier enough that engineers, PMs, and marketers actually use it—the tool is only as good as the culture that supports it
• Embedding design thinking into regular work cadence (problem-framing kickoffs, async critique boards, weekly design jams) is more powerful than periodic design thinking workshops
• Shared ownership from collaborative creation eliminates the finger-pointing that plagues cross-functional work—credit and accountability distribute together
• At scale, sustain the creative hub by maintaining the rituals deliberately: the open working sessions and kickoff structures need to be protected as the organization formalizes