Building a Design Driven Culture

In the spirit of sharing what I learn to everyone, here is another blog. I try my best to share as much as I can. Once a week or two, I share threads which are summaries on white papers written by entities such as OpenAI and Claude.

This blog is a summary of a paper I read from Figma and the Office Hours I also attended of theirs, namely Building a Design Driven Culture. Some of this may not be completely design focused, but the lessons are applicable in other avenues too. If you wish to have a summary of the main points, please click here.

In today's tech world, technology is no longer a differentiator. Infrastructure, tools, and features are widely available. True loyalty comes from how a product is designed—how it feels, how transparent the team is, and how deeply collaboration and inclusion are embedded.

Transparency

It all starts from transparency. This means that everyone is able to access everything from the design aspect. You are designing a new feature, get everyone involved. You are designing a new event, get all stakeholders involved. A new architectural change? Give access to everyone to the designs. By default, access should be open. This means that one should eliminate silos and permission barriers. If you are an organization striving towards a common agenda, why hide things? Openness is important. Plus, that specific feature is what the rest of the business will function around: sales will sell that, marketing will market that, engineering will build it, and so forth.

To do this properly, implement a centralized system: one door where everyone can find what they need without asking. Moreover, resources should be easily searchable, browsable, and intuitive. This is the crux of it. You want to be truly transparent, not half-hearted. Users should be able to find what they need with minimal friction. This means using shared language and a consistent structure for files and rituals. People can’t contribute if they don’t understand the system.

The other tenet of transparency is establishing a work-in-progress culture. This means normalizing sharing drafts and incomplete work and inviting contribution early in the process and not just on the final outputs. To do this correctly, a culture of collaboration and niceness has to be established. Individuals who insult should be removed. Encourage showing messy work, especially in experimental contexts like artificial intelligence. With AI, no one knows how to really plan. The best one can do is work on the limits of AI and scale from there. Planning is still important. The final plan may not be, but the exercise of planning is necessary.

Collaboration

Let me explain this clearly because this word is thrown around far too casually. Collaboration is not just slapping a Google Doc with “thoughts?” written on it. It is not tagging someone in Figma and assuming you included them. Collaboration, real collaboration, is when you make room for other people’s brains and hearts to exist in the same space as yours. You do not just allow comments—you make space for contributions to shape the direction of what is being built.

And here’s the trick: if you want real collaboration, you have to design for it.

Start with Silent Critique. This means everyone gives feedback quietly before any discussion begins. You post a design, or an idea, or a rough draft—anything—and people leave comments and thoughts independently. Only after that does the conversation start. Why is this so important? Because loud voices dominate. Groupthink kicks in. People with power sway the tone. Silent critique neutralizes this. Everyone contributes on their own terms. Then we talk. Then we decide. Then we build.

Rituals matter. What do I mean by rituals? I mean set practices that the team follows religiously. Every Tuesday morning, you know feedback will be given. Every Friday, there's a show and tell. You know what kind of critique is welcome and what is out of bounds. You do not surprise people with last-minute feedback and you do not make it personal. You build predictability. And with predictability comes safety. Psychological safety to share, to experiment, to fail, and to rebuild.

Inclusion

Inclusion isn’t about putting a diversity quote in your values slide. It is not about inviting someone once and then forgetting about them. Inclusion means every single person on the team knows how to enter a project and participate. It means the door is not just open—it is marked, it is lit, and it says “you belong here.”

That’s where clear entry points and process clarity matter. You need to document how your design process works. What tools are used, what steps are taken, who owns what, and where decisions get made. If someone new joins your team, or even someone from another department wants to contribute, they should not need to ask ten people. It should be obvious.

It’s not about outcomes. It’s about energy. No one is asking for a polished prototype. The goal is not to ship. The goal is to discover. Maybe an idea turns into something big. Maybe it doesn’t. That’s not the point. The point is to loosen the grip of deadlines and roadmaps and just let people build what they’re curious about.

And here’s what makes Maker Week actually powerful: it is open to everyone. Not just designers. Not just engineers. Anyone on the team can jump in. Someone from marketing might have a wild product idea. A customer support rep might sketch a better onboarding flow. That openness is what makes this more than just play—it makes it real collaboration.

But for Maker Week to work, it has to be set up right.

First, let people work on anything. No constraints. If someone wants to build an AI joke generator or reimagine the signup form or create something totally unrelated to the current roadmap—that’s fine. The only rule is that it should be something they want to build.

Gmail was a side project. It wasn’t assigned. It wasn’t in a sprint. It happened because an engineer at Google had 20 percent time—time to work on anything they found valuable. They saw email as broken. So they started fixing it. That spark became one of the most used tools in the world. It didn’t begin in a strategy meeting. It began in freedom.

Second, make it easy for people to connect. This part is underrated. Not everyone wants to work alone. So create a simple space—maybe a shared doc or a Slack thread or a Notice Board—where people can post what they’re exploring or what they want help with. Let others join in. That’s how side projects become group projects.

Third, choose a time when the office is actually free. Not during a launch. Not in the middle of sprint deadlines. Pick a week that feels breathable. A time when people are not buried in tasks and fighting fires. If you schedule Maker Week when no one has capacity, it becomes just another thing people have to survive. The whole point is to give space—real space. So plan around it. Protect it. Make it something people can actually lean into, not something they’re trying to squeeze between back-to-back meetings.

Design Literacy and Education

Let’s not pretend everyone knows how to design. But everyone should understand the basics. Offer regular workshops. Build guides. Share resources. This isn’t about turning everyone into a UI expert. It’s about helping your team speak the same visual language. When you say "make it more breathable," they should know you mean space. When you say "this feels heavy," they should know it’s a matter of contrast or density. You build this shared vocabulary by teaching. By investing in design education, you reduce misalignment and multiply collaboration.

Repeatable Workflows

This is the boring stuff that makes magic repeatable. If your process lives only in your head, it will never scale. Write it down. Define the phases: discovery, ideation, prototyping, validation, delivery. What happens in each phase? What tools are used? Who gives feedback? When is it final? What gets handed off?

Use standard tools. Build consistent feedback loops. Ritualize them. When someone wants to start a new feature or product, they should not have to figure it out from scratch. They follow the flow. That is how you scale design maturity.

Cross Functional Teams

Design is not the job of just the design team. It is a way of thinking and working that involves everyone. While designers should lead the design process and make the final decisions, that process becomes infinitely stronger when it is shaped by diverse perspectives.

Work closely with engineers, product managers, marketers, and even customer support. Each one brings insights that designers may miss. A marketer understands how it will land in public. A developer knows what is realistic. A support rep hears what users are actually confused by.

This is what cross functional truly means—not everyone doing the same thing, but everyone being heard. The designer still owns the design, but the work is informed by real conversations with the people building, selling, and supporting the product. That is what creates thoughtful, practical, and impactful design.

Design Critiques

Design critiques are sacred. They are not random comments thrown in Slack. They are structured forums where the goal is to learn and improve. You schedule them. You set a tone. You bring people from outside the design team. Yes, non-designers too. Because users are not just designers. The more perspectives you get, the stronger your final outcome will be. Design critiques should never be about proving your worth. They should be about making the work better.

Documentation

If you do not document, you are starting from zero every single time. Every decision, every piece of feedback, every lesson learned just evaporates. That means every new team member asks the same questions. Every sprint brings the same mistakes. Every meeting turns into rework. That is not just inefficient—it is exhausting.

Documentation is not just about saving files. It is about building continuity. Record workflows. Capture design decisions. Store feedback. Write down outcomes of user tests. Archive Figma flows. Link your Notion threads. Save Looms. Whatever tool you use, just do it. Documentation is what keeps the design brain of your company alive and evolving, rather than constantly resetting.

But it goes beyond storing decisions. You should also write down how people are expected to work together. Create guides that explain behaviors during critiques, brainstorming sessions, and project kickoffs. What does good feedback look like? What is off-limits? How do you challenge something without shutting someone down? What does it mean to come prepared to a design session?

Documenting standards of conduct, tone, and collaboration etiquette sets the baseline for a respectful and productive design culture. These little things matter. They protect team health. They reduce anxiety. And they raise the quality of the work.

Clear standards and documentation do not slow you down. They speed everything up—because people know what to expect, how to contribute, and how to move forward.

Design Systems and Components

You cannot scale design without a design system. Period. Use scalable, modular elements. Define your typography. Build your buttons. Create your form components. Standardize everything that repeats. This does two things. It creates consistency across your product. And it makes your team faster. Instead of designing the same thing again and again, they focus on solving real problems.

The same goes for other avenues, be it Mechanical Engineering, events, architecture, or more. Have design systems in place.

Commitments to Design Culture

To build a strong design culture, you need to commit to a few core ideas.

First, empower people. Make it easy for anyone—not just designers—to contribute meaningfully. That means open files, context that’s accessible, and permission to speak up. When people feel trusted, they bring better ideas to the table.

Second, systematize innovation. Do not wait for inspiration to strike. Build structures that allow it to happen regularly. Maybe it's a monthly maker week or just shared boards where anyone can drop rough ideas. The point is to invite creativity into the process—not treat it like a side bonus.

Third, drive alignment. Everyone should know what is being built, why it matters, and what good looks like. This avoids miscommunication and makes collaboration faster and smoother. Clear goals and shared direction are the backbone of a strong creative culture.

Fourth, make space for exploration. The best ideas come from curiosity, not just pressure. Protect time to try things, to test weird concepts, and to play. It keeps the work fresh and the team energized.

But here’s the key—do not overdo it.

Design culture is not about forcing every person into every conversation. People have roles. Deadlines. Priorities. Sales needs to close. Developers need to ship. Not everyone can or should be involved in every step. The goal is not to overwhelm. The goal is to build a shared rhythm that supports great work—not one that gets in the way of it.

Good design culture runs quietly in the background. It shapes how decisions are made, how people think, and how feedback flows—without becoming a distraction.

Build the system. Protect the space. And then let people do their jobs. That’s how real culture grows.

Hope this helped!

Next pieces will hopefully be on various fun ways to get teams together and solve problems and a video blog on vibe coding websites!

Saad.