There are a number of ways to peel an orange. A quick YouTube search will reveal a scalping method involving a spoon, a roll-out method that resembles a dissection, and, for traditionalists, the old peeling knife approach. If you want to keep your fingers from getting all sticky, you can order a fruit peeling machine from Amazon that doesn’t not look like a medieval torture device. And, of course, there are also electric-powered options for the futurists among us. Indeed, the imagination may be your only limitation when it comes to accessing the juicy flesh of Florida’s state fruit.
Just the same, there are many ways to build a website. Choices abound, in fact. Some are purely opinion, like naming conventions (Do I camelCase or do I snake_case?). Others are a matter of philosophy, like when to use pixel units versus percentage units. Still others may be determined by browser compatibility or other technical limitations. Choices might boil down to most-best or least-worst considerations, or even be driven completely by personal taste. But there are always choices, and deciding what to do can sometimes be as much work as the actual doing.
Even with a visual development tool like Webflow, which streamlines the development process considerably, each project can still be approached a number of different ways, and individual designers’ own idiosyncratic approaches can be as unique as fingerprints. One project, approached different ways by different designers, can yield indistinguishable results. And yet, in a team environment, these personal idiosyncrasies often create conflicts that reduce the quality and long-term manageability of a product. For this reason, a shared group philosophy is essential for successful teamwork.
In our years using Webflow, we’ve run into many if not most of these conflicts. Two designers might create duplicate classes, so a style update may not cascade across all visually identical elements. They might approach a translation to smaller viewports differently, creating inconsistencies in the visual design language. Or they might use different measurement units for positioning, compromising the modularity of the product. And anyone who’s done it knows there’s nothing worse than working on a hacked together Webflow project where components are nested inside “fixer” wrappers, elements are tagged haphazardly with overruling subclasses and class naming follows no obvious conventions. But it doesn’t have to be this way.
The trick to teamwork in Webflow is having the team members buy into a shared development philosophy, and to diligently apply it. This philosophy may be just as unique as any team, and one philosophy might have no obvious advantages over another. The important thing is that the team members are all on the same page. When a designer needs a class, they should know what to look for before creating a new one. When they work on translating a design to smaller viewports, they should follow shared conventions. And when they position elements, they should all have a similar approach from which to work.
Over the length of this course we'll discover how to create a system that addresses these pain points and others, creating a faster, less frustrating process that creates better, more manageable products.
Note: This course is specifically geared towards team strategies and is not intended to be a replacement for Webflow's own Webflow University tutorials.
Gone are the days of assembly line workflows and documentation as opposed to collaboration. With a Webflow workflow, you’ll replace a number of time-consuming steps found in most traditional web build workflows with real-time collaboration.Take me there