How to build a design culture in a company that doesn't have one
The instinct to start with process and tooling is understandable and usually wrong. Culture changes when behavior changes, not when policies are announced.
Starting a design culture from scratch is an odd position to be in. You've been hired specifically because design hasn't been valued here, and you're now expected to make people value it. The tools available to you are: words, behavior, and time. The amount of time required is always longer than the org agreed to give you.
The first instinct is usually to build infrastructure. A design system. A shared Figma library. A weekly design review. A critique format. These are not wrong. They're useful artifacts of a design culture. But they're not culture, and building them first gets the order backwards. Culture that doesn't yet exist won't maintain infrastructure. The process document nobody reads isn't a foundation. It's evidence that the culture isn't there yet.
The thing that actually changes culture
Behavior changes before culture does. Culture is what solidifies after behavior has been consistent long enough that people start assuming it's normal.
So the practical answer to building design culture is: do the things you want normalized, visibly and repeatedly, until people stop noticing them because they're expected. Run research before major features even when the schedule is tight, and make sure people see that it changed the design. Push back on a bad decision in a meeting where the right people are watching, and do it in a way that's credible and specific rather than abstract. Ship something that holds up to scrutiny and articulate publicly what made it good.
This is slower than writing a process document and approximately five times more effective.
Who you need on your side
Design culture doesn't get built by designers alone. It gets built by designers plus the people in adjacent roles who decide whether design's contributions matter. A product manager who consistently brings design in early and treats design input as affecting decisions is worth more than a Notion page about your design principles. A single engineer who codes with care and treats a pixel-off implementation as something worth fixing models something that a design review process can't.
The early work in an organization without design culture is finding these people and making them visible examples of what the collaboration should look like. Not manipulating them, not lobbying them. Just working well with them and making the outcomes of that collaboration visible. If the product that was built with genuine design partnership looks noticeably different from the product that wasn't, the case makes itself.
What to do when those people don't exist yet: make the implicit cost of not having them legible. A feature that shipped without research and then needed to be reworked is a data point. A design that was overridden for reasons unrelated to the user and then performed badly is a data point. You're not building a case against individuals. You're building a pattern of evidence that design investment has downstream consequences.
The critique problem
One of the clearest signals of an existing design culture is how critique works. In organizations without it, design critique is either absent (no formal review before things ship) or performative (everyone says "looks great" because being critical feels impolite).
Building a critique practice from zero in an environment where neither is the norm is one of the harder parts of this work. People aren't used to giving substantive design feedback and aren't practiced at receiving it without defensiveness. The instinct is to institute a critique format and hope people adapt to it.
What works better is running critique informally before you run it formally. Show your own work in progress. Ask for reactions in a setting that doesn't feel like a performance. When someone gives feedback that's substantive and accurate, name it as useful: "That's exactly the kind of thing I wanted to surface early." Gradually, what useful critique looks and sounds like becomes concrete rather than abstract.
The formal process can come later, once there's a shared vocabulary for what critique is supposed to accomplish.
What you can't control
Some organizations will not build design culture regardless of how well you do this work. The constraint is either structural (design doesn't report to anyone with enough authority to protect the investment) or it's a product market where design genuinely doesn't differentiate outcomes, and no amount of culture change will shift that.
Recognizing this is important and undervalued in the "how to build design culture" conversation. Spending two years trying to shift a culture that isn't going to shift is a bad use of two years. The signals that suggest you're in this situation: leadership consistently deprioritizes design when under pressure, design is downstream of every significant decision and there's no path to change that, the product's success metrics don't include anything design can influence.
None of these is definitive alone. Together, they suggest that the problem isn't how you're doing the culture work, but whether the organization is capable of it right now. That's a different problem with a different answer.
The long game
The actual timeline for building design culture in an organization that doesn't have one is two to four years, assuming reasonable conditions. The first year is mostly behavior and no infrastructure. The second year is the point where infrastructure starts to make sense because the culture can sustain it. The third year is when you can start to see whether the changes are becoming self-sustaining.
Self-sustaining is the goal. Culture that requires you to actively maintain it hasn't actually formed yet. When the designer who joined a year ago is modeling the behavior you were modeling when you arrived, something real has happened. That's the signal.
Be the first to rate this article.
Let's work together.
Open to select projects and collaborations — design systems, accessibility, and AI-native product work.