Over the past five years of using Webflow in a team environment, we've learned a number of things about what works and a few things about what doesn't.

As our client needs have grown in scope and complexity, we have had to think not only, "How might we build the next best thing?" but, "How do we do that at scale?" and "How can we have more people, across disciplines, contributing to the project in a productive way?" This hasn't always been painless.

One of our initial mistakes was creating class names inconsistently across a build. Class naming may feel secondary during the design process, but returning to a build six months later to make major updates will change your mind. And trying to interpret another designer's idiosyncratic approach to styling can be even worse. Div 273? Header Subpage Alt 2? Forget about it.

Our answer: To create a guide for how we build things. More than just a how-to, though (Webflow University has got that covered), we've started to outline our philosophies on why we approach certain aspects in specific ways.

Basics of our collaboration

We love Webflow because it allows for better collaboration between design, content and development teams.

In the old days, we basically had a series of static documents (Word, Acrobat, Photoshop) describing every element of the design, and it was up to the development team to bring everything together. This approach was great for creating Jira tickets, or design by walkie-talkie, but not so great for creating a collaborative team environment.

Today we create our wireframes and core design system in Figma, then we start constructing pages in Webflow as writers edit content directly in the build.

Who is this for?

For the last year, we have been working on documenting these ideas into a 12-chapter guide. Our first audience has been ourselves; we needed something written and considered so when we bring new people onto projects they can understand the approach. Our second audience was our clients, so that when we hand over a build, they have a training manual to later reference when they create new pages. (We love continuing to work with our clients, but one of the great things about Webflow is that you don’t always *need* to go back to a developer to make updates). And our third audience has been the Webflow community. We are excited about this platform and look forward to both sharing what we know and getting feedback on what we could do better.

In our next post, we'll share a wishlist of basics for how to make Webflow better for collaboration. (Preview: We don’t need a built-in to-do list!)

Until then, check out our Knockout framework. It's part of our strategy to help teams move faster and build more in Webflow. We look forward to hearing what you think!