Beginner's guide to Webflow organization

Creating your first Webflow design project? Use these simple tips, prevent roadblocks and ship your products with confidence

If you’re new to web development or specifically to Webflow, you probably don’t have experience in project organization and best practices that you need to follow to successfully complete the project and optimize the time and resources used. Additionally, if you’re a business owner or project manager and dealing with Webflow for the first time, you can use these tips to keep the project on the right track and launch with all parties satisfied.

Webflow vs standard front end project organization

In essence, building websites with Webflow can, and often does, result in the same code as it would if you build it by hand. But the process of building is vastly different, as Webflow itself is a visual development software, and thus more popular with designers that need a live visual representation of any given modification. In this blog post, we’ll cover both overall development to-dos that go hand in hand with Webflow, as well as some specifics that are created by the introduction of the visual building interface.

Sections, containers, and other layout and functional elements

When possible, it’s advised to use default Webflow layout elements that you can find in the Elements panel. You can achieve the same by using div blocks instead, but by choosing a section element you get a different visual representation in Webflow Navigator which helps with organization, especially as pages grow. With other elements such as Dropdown or Navbar, rebuilding them from scratch would take a lot more time and is not viable from that perspective, unless the client demands some custom functionality that is not possible with those elements.

sections-containers-blog

Containers

From our experience, the only default Webflow element that we at Lumen avoid using is Container. It works great for simple websites and is easy to use, but we prefer styling div block instead to achieve ultimate adaptability.

Below is an example of a container made from div block, that we use most often and consists of these three properties:

  • max-width: 1200px; which is the standard desktop grid width
  • width: 90%; which makes sure there’s always 5% of padding on both ends (or more on desktop depending on the width over 1200px)
  • margin: 0 auto; making the object inside container sit centrally (0 means top & bottom, and auto means left & right)

This makes it perfectly responsive without having to modify the container whatsoever on lower breakpoints. For sections, where you want to have a custom container width (for example blog post, or centrally positioned form with 700px of width), you would simply create a combo class, and only change the max-width property and everything is set up perfectly for your content.

Styleguides

Ideally, especially for bigger projects, you would create a design in software like https://figma.com prior to Webflow development in order to optimize the development process. Part of that design should be a Styleguide page, which should consist of information on how various elements will look and behave. It should at least include colors, headings, buttons, and text styles so you can reference them later and make sure every element looks exactly like it’s supposed to. Especially for headings, it’s important to make the style guide responsive by defining heading font sizes for all breakpoints. Once the design phase is finished and you’re ready to move to Webflow, make sure to start with a style guide page, which for a start doesn’t need to look fancy.

Default styling tags

For elements such as headings, paragraphs, links (and body as well, which is not an element), it’s important to apply styling that affects all related elements without the need to update each one individually.

Click on a heading (H1 for example), and navigate to the Style manager panel. Before entering the element-specific name, click into the selector panel, and select ‘All H1 Headings’. Now, any changes that you do will affect each and every H1 heading on your website. The same goes for all headings, paragraphs, links (and body as well). The body is especially important, to avoid creating a new class for each text element you use. But note, that by setting default style for certain elements, it doesn’t mean you can’t style them individually as well - simply add a class to H1 heading element, and style it accordingly with your preferences, and it will only affect the specific class.

default-tags-blog
Default tags for static and dinamic pages

Color Swatches

Another important organization step, that you need to do right at the start is creating color swatches for text (headings, paragraphs, text), buttons, backgrounds, and supporting colors and accents. Usually, there are just a few (5-10) different colors used across the website, but it’s advised to make separate swatches even for the same color when, for example, you want two very different elements with the same color. This is especially important for text vs other elements. Sometimes, for various reasons, you’ll want to change element color across the whole website, and by following these principles, you’ll be able to do that with a few simple clicks. You don’t want to risk unintentionally changing some other elements’ color alongside.

Naming convention

A naming convention is one of those things that will expose your lack of organization right away and turn on some red flags. We’ve all been there - sometimes, there’s simply not enough time to name classes along the way, and in some very rare instances, that’s even acceptable, but more times than not, you’re creating technical debt that you’ll likely regret sometime in the future, and it will come back to haunt you. Many times, the ROI (return on investment) of naming classes as we go along has shown on the first day of the development process, and sometimes you only realize the mess once you’re handing off the project to another developer, that spends valuable time just trying to get through with the mess than has been created.

There are two popular naming conventions being used on Webflow (and front end development) projects:

Descriptive Convention

With this naming convention, that is most used in Webflow development, easiest to navigate and we most commonly use, you always use descriptive language for classes and interactions.

Classes should be Title Case, and not abbreviated, without the use of dashes or other traditional CSS conventions such as camelCase. A good example of a class is ‘Share Button’, instead of something like ‘share’ or ‘share-btn’. We like to follow the guidelines that Webflow put together for the template submission guidelines, which make naming easy to understand to less tech-savvy people and doesn’t limit ourselves in any way.

descriptive-classes-blog

BEM

BEM stands for “block, element, modifier), and it divides interface into small components. It’s very granular and can be quite complex for beginners, that are just starting out in web development. We only use this convention for a few client projects, when that is a specific demand and code is later going to be exported from Webflow and coded into a full-fledged web application. But other than that, we prefer the classic, descriptive one.

Delete unused properties, classes and interactions

Sometimes, especially if you’re started the project without taking the organization into consideration, you’ve probably added properties to classes, that could be added on a higher level via default styling tags and described above. This can be very well explained in the example of the body. On the vast majority of the projects, body properties are not dependant on the page but are site-wide and because of that, it makes no sense to create its own class. Simply delete the class and style ‘Body(All Pages)’ tag. Once the class is deleted, go to Style Manager and click on Clean Up to delete all unused classes. The same can be done for interactions under the Interactions tab.

Sometimes, especially when working on responsiveness, you might create a custom class property for two different breakpoints, both with the same value. Try to avoid doing that, and only use it once, on the highest level breakpoint, which will make it cascade down/up depending on the location.

Uploaded assets

Webflow has the ability to sort your assets into subfolders, and while this isn’t an important feature for small projects, it can get very messy once the project grows. Be very careful and upload new assets directly into folders with intention, and managing them will stay easy even with huge projects and multiple people on board. As a side tip, always optimize and rename images before uploading them to Webflow - there’s a big chance you’ll forget to do that before launching your website and it will take you a lot more time than it could.

Hopefully, these tips will help you be productive, stay organized and be able to identify problems sooner and make changes accordingly to keep you on the right track and keep your project easy to modify no matter who’s behind the computer.

assets-blog

Create Reusable Symbols

For sections that you plan to reuse on different pages across your website, create symbols so you don’t need to manually update each individual page. This is especially helpful for elements such as Navbar or sections such as Footers, Call to Actions, or even some custom embeds that need to be included on every single page. Creating and inserting symbols on two pages is easier than modifying anything on two or more pages, so this is an absolute must not only to keep your project organized, but also to not losing valuable time.