Every design team has more creative energy than time. The question isn't whether to spend it. It's whether you're spending it on the right things.
Most teams aren't. Not because they lack talent or ambition — but because they're reinventing wheels.
What's a wheel, what's a snowflake
A wheel is a problem that has already been solved well enough that originality adds little value. Think navigation, forms, form validation patterns, filters, data tables, settings, and other routine interactions. Mature design systems, component libraries, and established interaction patterns give teams reliable ways to build them. Users recognize the conventions. Teams understand how to build and maintain them. More of the edge cases are already known. In these moments, familiarity is not a creative failure. It is the advantage.
A snowflake is something worth inventing — but that bar is higher than most teams think. It's not a new interaction pattern because it feels fresh. It's not a redesigned flow because the old one felt boring. It's a deliberate response to a customer need that existing patterns genuinely can't serve, tied to a business outcome that justifies the investment.
- What it is
- An established solution that already serves the need
- A custom solution for a need established patterns cannot serve
- Best for
- Navigation, forms, validation, filters, tables, settings, and other common interaction patterns
- Core product moments and genuinely differentiated interactions
- Optimize for
- Familiarity, accessibility, speed, and reuse
- Customer fit, business advantage, and measurable outcomes
- Decision rule
- Use it by default
- Make it earn the added cost
The mistake isn't designing snowflakes. It's designing snowflakes when you needed a wheel and not noticing the difference.
The hidden cost of wheel reinvention
When a team spends six weeks designing a custom data table, they're not just spending six weeks. They're spending the design time, the engineering time, the QA time, the documentation time, and the ongoing maintenance time — for a component that will be less familiar to users than the standard they replaced.
That's the snowflake tax. You pay it in schedule. You pay it in quality. And you pay it in the creative energy that never made it to the problems that actually needed original thinking.
At GitLab, boring solutions were an explicit operating principle. Not as a compromise. As a strategy. Use the established pattern. Ship the known approach. Then spend what you saved on the work that moves the needle.
Boring solutions are often better solutions
This is the part that surprises people: the wheel usually isn't just faster. It's better.
Established patterns have usually survived more use, more edge cases, and more accessibility scrutiny than a custom alternative. Your users have often seen them before, which means they spend less energy learning the interface and more energy completing the task.
The custom solution you're proud of on launch day is the one you'll be patching for the next two years.
What you get back
When teams get disciplined about distinguishing wheels from snowflakes, something shifts. The creative energy that was diffused across a hundred commodity decisions gets concentrated on the things that actually matter — the experiences that are unique to your product, your users, your market position.
Those are the ideas that were always worth building. They just never got the attention they deserved because the team was busy reinventing the data table.
Embrace the boring solutions. They're not a creative concession. They're what makes the interesting work possible.