Design culture isn't foosball tables. Here's what it actually is.
Culture is what people do when nobody's watching. For design teams, that means what gets celebrated, what gets corrected, and what gets quietly tolerated.
The foosball table version of design culture is easy to identify because it's everywhere: a decorated office, a Spotify playlist for the studio, a monthly design team lunch. These things aren't bad, but they're not culture. They're furniture.
Culture is the collection of defaults your team operates by when no one is explicitly deciding. What gets shipped without review. What kind of critique gets taken seriously. Whether a designer will say "that's going to hurt users" in a meeting where the product manager has already committed to the feature. Whether they'll say it a second time.
Those defaults accumulate from what gets celebrated and what gets corrected, from what's treated as embarrassing and what's treated as fine. You can't declare them. You can only demonstrate them repeatedly until they become what people assume.
What norms actually look like
A norm isn't a value statement. "We care about quality" is a value statement. A norm is what happens when someone ships something that looks off because the deadline was aggressive: whether someone says something, whether that something is said in a way that changes behavior, and whether it changes anything the next time.
The most revealing norms are the ones around disagreement. How does a team handle a situation where design and product want different things? If the answer is always "design defers," that's a norm. If the answer is "it depends on who has the stronger argument and both sides expect to have to make one," that's a different norm. Both produce different work and different designers.
Norms also exist around research. Some teams treat talking to users as optional context, something that informs the work when there's time and gets skipped when there isn't. Other teams treat shipping without research as a failure mode, something that requires a deliberate tradeoff and an acknowledgment. The difference isn't resources. It's what gets treated as normal.
What gets celebrated matters more than what gets said
Design leaders talk a lot about what kind of work they want to see. The talk matters less than what actually gets recognized in reviews, in all-hands presentations, in the projects that get spotlighted. If the work that gets celebrated is always the work that shipped fast, regardless of quality, that's what the team learns to produce. If the work that gets celebrated is the work that caught something early enough to prevent an expensive mistake, that shapes a different team.
This isn't about manufacturing praise. It's about being deliberate with attention. A design critique that spends twenty minutes on visual polish and two minutes on whether the interaction actually works tells designers what the organization thinks design is for. A postmortem that surfaces design decisions as contributing factors, rather than treating design as decoration applied after the real decisions were made, does the same.
Celebrations also carry information about who. If senior designers get visibility and junior designers' work is treated as practice, the team learns that certain voices count more than others. That shapes whether people speak up, which shapes the quality of the work.
What gets corrected is the real signal
A team's culture is most visible in the things that get addressed and the things that get left alone. A designer ships an interaction that doesn't account for keyboard navigation. Whether anyone mentions it, and what happens when they do, is more informative than the team's accessibility documentation.
This is where design culture diverges most sharply from design values. You can post your values on Notion. The correction signal is harder to fake, because it shows up in the actual behavior of actual people under actual pressure. Teams that say they care about accessibility and don't correct accessibility failures don't actually have accessibility as a value. They have it as an aspiration.
The same applies to process. A team can say it values iteration and then ship the first concept every time because iteration wasn't built into the deadline. What gets corrected is what's treated as non-negotiable, and the things treated as non-negotiable are the things the culture actually holds.
Why culture is slow and hard to change
The reason culture is hard to change is that it's mostly implicit. Nobody decided that designs don't need to be reviewed for accessibility before handoff. It just became what people do, because it's what always happened. Changing it requires a sustained pattern of different behavior, not a single policy announcement.
The fastest way to shift a norm is to make the correct behavior visible and routine, and the incorrect behavior visibly costly. Not punitive. Just real. "We shipped this and it broke keyboard nav and we had to go back and fix it. Here's what we'd change in the process." Said once, that's a learning. Said every time, it becomes an expectation.
Building design culture is not a culture deck. It's a year of behaving the same way under different pressures until people stop having to remember to do it.
The teams I've been on with genuinely strong culture all had one thing in common: they were boring in exactly the right ways. The decisions weren't interesting because the defaults were clear, and the defaults were clear because they'd been reinforced until they were automatic. There was no drama about whether to run research on a major flow. It was just what you did.
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.