hey guys, I'm trying to find the best way to build a scalable component library for a startup. Since there are so many different options of combining variables, slots, components, variants, instances etc. it would be incredibly helpful for me to look into a successful webflow project which was build for marketers using the relume library.
Do we have any case studies, ressources or read-only links from big projects where young designers like me could find inspiration to scale up their relume builds? Big thanks in advance if anyone can help me out 🙏
@Alexander Richter this is such a great question and one that I would love to get an answer to. I’ve tagged some community members who may have some insights if they feel so inclined to share here or in DM. If we don’t get any insights this way, I’ll keep trying other avenues.
@Jon Saxton @Isabel Edwards @Christian Schmitt @Chris
I don't have an example at the ready, but I'll drop this awesome post from Caleb Raney that mirrors a lot of how I'm thinking of a scalable component system! https://www.calebraney.com/post/component-first-development-in-webflow
Thanks for the input! This article is really interesting. Would be still nice to see it in a live-project but this is already quite helpful 🙏
Yeah, I'm still figuring out my way through all the conundrums Caleb mentioned - modular vs fixed, how much to rely on nested components, etc. But it's at least nice to know a few other folks are figuring it all out too
From our experience I think it really depends on the end user.
We’re currently working on a large-scale, component-driven design system that includes over 400 static pages and thousands of CMS items. One of the most important considerations has been understanding the end user’s technical knowledge and their publishing workflow.
For example, we initially explored building a single, flexible header component with six layout variations. While this would have been efficient from a development standpoint, we quickly realised that the marketing team wouldn’t have the clarity needed to confidently choose the right layout or understand which content goes where.
So instead of relying heavily on slots or overly complex variations, we opted for a simpler, more intuitive approach. Developing six header components clearly named, each with limited and purposeful variables — like background colour or element visibility — to give the team just enough flexibility without overwhelming them.
Not sure if that helps!
Agree that you have to walk a line between ultra-flexible do-anything components filled with slots and overrides, vs narrowly scoped, single(ish) purpose layouts. Working on one where I think I over-indexed on the flexibility side at the expense of a bit of usability, caused some rework to simplify things for the end user. Knowing the aptitude - or interest - of the folks using the system is important!
Spot on @Jon Saxton. I think we'll be building it into our workshop process getting client sign off on the level of flexibility needed.
