Given its low barrier of entry, anyone can build a site using Webflow. That's a great thing and one of the main reasons why Webflow is revolutionizing how we build for the web. But if we're looking to build a career out of it, we must professionalize our Webflow practice.
On this article I'm addressing three core aspects that should be inherent to the Webflow projects we build. In order of less to more complexity, these are Maintainability, Scalability and Transferability. These three concepts solidify upon the following ideas:
Before we start digging into thee there core aspects, let me introduce them with simple definitions.
Maintainability of a Webflow project: The ability to update the content of a Webflow site by someone with little to no Webflow knowledge.
This is foundational to the platform and what made Vlad, Bryant and Sergei start the Webflow adventure. Our duty is to not hinder and, more importantly, embrace Webflow edition capabilities through the Editor and the editor role in the Designer.
Scalability of a Webflow project: The ability to publish new content in a Webflow site respecting and consolidating its content structure and logic by someone who might have little to no Webflow knowledge.
Our clients might not want to scale their site immediately after launch but its our duty to make our best effort in preparing this scenario for the future.
Transferability of a Webflow project: The ability of a Webflow project to be understood by a seasoned Webflow professional in less than 15 minutes, giving the capacity to create new components, sections and pages respecting the site's structure and class creation system.
These concepts are not binary. Meaning, it's not about a Webflow project being maintainable or not, is about asking the question, ¿how can we make this project easier to maintain? On other words, maintainability, scalability and transferability are qualities that can always be improved. And improving these qualities will depend on the project and client.
The maintainability of a Webflow project resides on the ability of updating its content by someone with little to no Webflow knowledge.
This ability is something Webflow provides as default so it's our duty not to hinder it.
An important note to add here. I'm a firmly believer that the Editor as we know it today will be deprecated sooner or later. With the new editor role in the Designer and new roles coming, I see all the edition work happening within the Designer. The points below are mainly focus on the current Editor but most of them also translate to the editor role in the Designer.
Sometimes in our pursue to create amazing things we forget that content, to be editable through the Editor, must be clickable. This means that the editable div is not overlayed by any other element, preventing the person who is editing to access to its content. A nice workaround suggested by Vincentis to create that content difficult to access a symbol and then have a hidden page where this symbol is easily editable.
The native block link Webflow provides is not editable through the Editor, this means that either we are totally sure that the link configuration won't be updated through the Editor or that we need a different approach. Fear not because the amazing Finsweet team has a solution for editing block links in the Editor
Many times, certain parts of the designs have a single paragraph and thus, we add a single paragraph element in our build. But the client asks the ability to add more than a single paragraph. On those cases, is a very good idea to add a rich text element instead of the static paragraph element. This gives the ability to add as many paragraphs as needed. It also serves well when the number of items within a list are variable. If you are afraid that the user will start adding H2, images, etc. You can always set these to display:none with the child selector functionality for that specific rich text element.
When presented with a section where the desktop and mobile versions are very different from each other, some people choose to create two versions of the same section, one visible on desktop and the other one on mobile. This means the content updates made on desktop will translate into in mobile. Also denotes lack of experience with the tool as almost every layout can be turned into its mobile friendly counterpart with the correct styling. If you feel this paragraph speaks to you, is time to up your game on making a site responsive.
This is a small hack. The HTML tag when on the Editor has the class w-editor. This means we can target specific elements with custom CSS on this view. Some examples would be: show elements that are hidden by default, update z-index to make an element, etc.
The scalability of a Webflow project is the ability to grow the site as new contents need to be published.
Use CMS-powered content as much as possible. Yes. It requires more planning and configuration but it will make your client's life easier, thus, yours too. Plus, your work will be much more valuable.
Imagine coming back to a project with several pages duplicated by your client because there wasn't a content structure that would allowed them to use a template. You're asked to do "some" design updates and changes. No fun.
On this point, I suggest looking into advanced and smart ways of using the CMS. We all know how to create a CMS-powered blog but, what about creating a system for publishing landing pages? There's a lot of magic that can be created with the power of Webflow CMS.
As to create a scalable Webflow site, you should build a component system your clients can use to build unique pages that don't make the case for a template.
Nailing a component system in Webflow is tricky for two main reasons. The first is because requires more knowledge transfer between you and the client. The second is that you need to define how granular you want to get with the component system. The more granular, more flexibility to build new components and sections but also the more complex to use. And this could be a problem for Webflow newcomers.
Before developing a component system I suggest sitting with your client to uncover the applications the system will have and find the right balance between flexibility and easiness to use.
As an example you can build a component system for your client that's purely based on entire sections. On this scenario, the only thing that the client needs to build a new page, is pull the needed sections into that new page.But, what happens if the client wants the ability to add a button where there wasn't? Or add a gallery instead of a single image? Or convert a two-column layout into a tree-column one? Here is where that previous planning comes into place before building a component system that is usable.
Transferability is about systematizing, creating a certain logic on the decisions toward repeating patterns. There are always multiple ways of doing things, but when it comes to create a logic build, once you decide your way of doing something, you need to stick to it every time you are presented with the same scenario.
The first and key factor to make your project transferable is to have a system in place. This can be your own or someone else's.
Next is to build on top of this system to create the logic and rules that represent the designs you are working from. By this I mean that a system is a great place to start but, is just the frame for your project. You still need to tailor it to the specific project you are working on. And while tailoring it there are decisions to be made that can then be systematized, therefore, facilitating the task of understanding your build by a Webflow professional who just landed in your project months later.
Define what and how divs will work together to create pages, sections and components.
What I mean here is that once you define what is the given structure for sections in your project, reuse that for every section and do not create a unique combination of divs every time you are presented with a new section.
The same goes for components. Once you decide you are building your cards on a certain way, follow the same logic when creating a new component that is also a card. For example, if you decided that the shadow of the card is applied in the card wrapper, keep that logic the same when creating a new card that also has a shadow.
And page structure is much of the same: keep always the same div combination and nesting relation across all of your pages.
This idea of repeating div structures gives an empowering sense of owning the Webflow projects instead of banging your head trying to understand "why in hell did you add that div over there".
Detect patterns such as shadows, image aspect ratio, border-radius, a specific grid behavior, everything that is repeated across multiple elements, sections and/or pages. And find smart ways of making reusable patterns out of them.
Let's say we have a design where different measurements for border-radius are used across the project. ¿Should we make this measurements accesible from anywhere with a set of utility classes? ¿Or should we treat them at the component level where the border-radius is applied to a specific component class ? There is no right or wrong but a decision to be made. And once is made we need to stick to it.
A good point to highlight here is the need of tablet and mobile mock-ups. Given that this pattern-recognition process in most cases is responsive-sensitive, is important to take into account how a specific pattern updates in the different viewports. Having the designer visions on the three breakpoints upfront will help us systematize the build.
Given that interactions are almost always left to the end of every Webflow process, we sometimes underperform on this part of the builds. Here are some tips when working with interactions that also breath systematization.
That's it, comment all your custom code unless is self-explanatory, which almost 100% of time is not.
The last but not least item is to document your builds.
For every project, create a document where you explain non-intuitive approaches to specific scenarios presented through your process and build. This could be third party solutions, specific JS functionality, CMS structure, interactions, you name it.
This will not only help a future Webflow professional who is navigating through your build to understand it. It will also help your future self to update a project that has remained untouched for 4 months.
As said in the beginning, the ability of creating a maintainable, scalable and transferable Webflow project is not a matter of checking a list of boxes. There are some general rules as we highlighted in the article but this qualities are highly dependable on the design we are handed. The maintainability, scalability and transferability of a Webflow project is not a list of best practices but something where is always room for improvement.