We’ve distilled our approach into a number of principles that drive our development department. We then created our course Webflow for Teams and the corresponding Standard No-code Class Library. We are launching this into the world to talk about more than just what we are building and start to get into the how and why we build things. If you have other ideas or feedback you can can find us on Twitter.
Cascade wherever possible, beginning with global elements and using classes to define exceptions. Avoid redundant style declarations. Finding where a style is inheriting from should follow a clear hierarchy.
Strive to make your build as self evident as possible, which might mean avoiding unnecessarily complex nestings or obscure naming conventions. The simplest way to solve a problem is nearly always the best way, even if that requires a little more thought or effort.
So much time can be saved and simplicity achieved by thinking modularly. This may mean stringing together Utility Classes to create commonly used looks or behaviors, or decoupling interaction classes from style classes. A class like “Sales Page Intro Copy Wrapper,” for instance, which might only serve to center the copy, could easily be named “Center” and reused across the site. And an interaction, such as a Parallax effect, can be applied to unstyled classes like “Parallax - Layer 1” and “Parallax - Layer 2”, which can be appended over and over to any element that needs the effect.
Hiding pseudo-classes in HTML Embed elements can oftentimes make things far more straightforward for the client, rather than having them navigate a maze of exception classes like “First” and “Last.”
If a headline style works across nine pages but wraps funny in one instance, it might make more sense to edit the headline than to create a new headline style as an exception. The integrity of the design system should oftentimes trump a specific piece of content.
Moving quickly is part of the benefits of Webflow of course, but the greater potential lies in empowering our clients to control their own destiny, and the degree to which that’s achieved is up to us. So it’s incumbent upon us, as designers, to be mindful of the client (a real end user) while developing, and to use principles that empower you, rather than focusing on what might be quickest or easiest in the near term.
We hope you find these helpful, and as always, feedback welcome. You can find us on Twitter.