When collaboration is one of the pillars where the platform is putting its attention and resources, dedicated roles is something to look at right now. This is the start of Webflow efforts on delivering collaborative features.
If you've been in the Webflow ecosystem since the early days, you'll know that the platform's initial target where solo-designers and small teams, highlighting the power to bring our designs to live and removing the hurdles of working with a front-end developer: multiple rounds of feedback, implementations not being accurate, and other pitfalls of the "old" design-dev way of doing this.
Now, as the flagship of the no-code movement, big organizations and enterprises are using Webflow for their top of the funnel marketing layer. With this scenario, multiple agencies have turned to a Webflow-only or Webflow-focused model. Top players here are Edgar Allan, Finsweet, Refokus, Whiteboard, 8020, among other Webflow Enterprise Partners.
For small shops and one-person practices, the "Webflow person" title keeps making sense, but as we transition to bigger agencies with simultaneous projects at any given moment, it is time to define dedicated roles within Webflow. And with the new roles and collaboration features announced during NoCodeConf 2021, the idea of specialized Webflow professionals gets even stronger.
This article is targeted towards Webflow agencies that have three or more Webflow people working solely in Webflow and has at least three simultaneous new builds at any given time (I am not counting any maintenance or low effort project here). Anyone reading this article will benefit from the ideas shared, but these agencies are the ones that will extract the most value of what it is said here.
Before we dive into these ideas, keep in mind that this is not a set-to-stone approach and you shouldn't look at it this way. Instead, you should understand what of the insights shared make a good fit to your team workflow and establish a good way to transition into them.
There are three main phases during the process of any Webflow project that we need to understand before talking about Webflow dedicated roles.
From these three phases we extract the Webflow dedicated roles: the Architect, the Composer and the Publisher. Before going into the details of each of these, let's discuss the benefits of this approach.
Let's say that as an agency owner, tech lead, or similar, you manage a team of Webflow developers. Each of these people are normally tasked with new builds, from zero to launch. They are great professionals and deliver great results in agreed timeframes or sooner. There is nothing wrong with this approach. Projects are being delivered and clients are spreading the good word about us. But there is always room from improvements and with thew soon-to-come Webflow roles, it is time to get better at our Webflow game as a team.
Applying dedicated Webflow roles within your Webflow team, you will transition from professionals working in isolation delivering on a per project basis, to people working collaboratively engaged in a constant delivery cadence.
There is a plethora of tasks when it comes to bringing a website to the public. These tasks can be close in nature or be apart from each other (design system, cms structure, accessibility, client handoff, ...). By unifying similar nature tasks under dedicated roles, Webflow teams can benefit from the following:
***
The main goal of the Architect is to provide a comprehensive components set and rules that will allow the Composer to build every single page in the project.
The person with the Architect role is in charge of the initial phase where the building blocks of the Webflow project are created and systematized.
The work of the Architect does not start in Webflow but with the design files along with the designer. The Architect's first task is to systematize the design into UI units that can be combined into components in Webflow. Experienced web and UI designer understand the nature of the web and provide this systematization work to a given degree.
The Architect starts seeing UI patterns that can be translated into components as soon as she or he has access to the design files. All the questions and recommendations the Architect has, revolve around creating a strong foundation for the project: grid, spacing, typographic scale, unification of design aesthetics (colors, shadows, decorative elements...).
The Architect has the ability to set rules and logic from the patterns she or he extracts from the design. This is where we call the Architect a framework builder. Is not that she or he is going to build a whole framework from scratch for every new project. Yet, the Architect embeds the peculiarities of the project into his or her current Webflow framework and provides rules for the Composer to build each of the pages.
The Architect is in close communication with the Composer. On one side, the Architect needs to contextualize the Composer on the logic and rules followed to build the components. And on the other side the Composer needs to keep the Architect accountable for any missing component or building logic that doesn't makes sense forward in the progress.
The main goal of the composer is to build a fully functional website.
The Composer picks up the baton from the Architect and builds the different pages of the site from a single source of truth: the components library. It might happen that there's the need to create or update a given component. This can be done directly by the Composer or handed off to the Architect in case it requires a deeper dive into the foundational elements. Additionally, this going back to the founding phase can be triggered by a client request. It is likely that during the composing phase, the style guide and/or design systems get updated and the components library extended. That's why the Composer and the Architect work closely together.
The Composer holds a special responsibility: sharing progress with clients. This is a delicate step as the Composer will have to balance between progressing on the build while resolving feedback. The good news is that the Composer is not alone and counts with her or his Webflow colleagues to help on this tasks.
If the Architect's has the ability to see UI patterns as soon as he is faced with the design, the Composer has the same ability with content patterns. The Composer quickly starts to envision how the content can be structured and connected to take full advantage of the Webflow CMS.
As an agency working with enterprises and organizations that have specific requirements for their online presence, integrating custom functionality is bread-and-butter on these projects. Is the Composer's duty to integrate any third-party or custom tool as part of his goal of building a ready-to-publish website. Examples of this third-party tools can be find the Webflow's extensive integration and resources ecosystem.
We haven't heard anything like a Composer role in Webflow yet, but this article might be the prelude of a future role in the Designer that lets you build new pages from pre-built components without having access to updating styles or the per-component DOM structure.
The publisher's main goal is to make the site ready for: the public, search engines and the client's marketing tool stack.
Although it is named the Publisher after being in charge of the final steps before launching the site, a good portion of her/his functions is to oversee the Webflow project. Whilst the Publisher is not actively working in the Webflow tool during the founding and composing phase, she/he is always close to the progress of the project providing support to the team and client, asking for missing materials and making sure everyone gets what they need to keep progress.
The Publisher is the first point of contact between the team and the client. This helps the Architect and the Composer keep focused on their tasks.
One of the main tasks of the Publisher is to make the Webflow site part of the marketing tool orchestra. This is where Webflow communicates with other marketing tools to keep the business operations automated.
Alongside project managing and marketing automations, the Publisher takes care of all the final details that are often overlooked after the bulk work of producing the site's pages: meta tags, audit panel, favicon, sitemaps, redirects... The end goal is not to just make the site look amazing but make it a sharp and smooth marketing tool.
The Publisher makes it a common use case of the recently launched Edit mode within the Webflow Designer.
Under this category I'm adding two extra roles which though not fundamental to every Webflow project, they are needed several times when operating at a certain level of deliverables.
As the name states, this professional is a master with Webflow's interaction panel. It is likely that this role will be assumed by any of the three professionals previously described on the article.
The Coder is a software dev who has turned his interest into Webflow and builds complex custom solutions for clients that have specific use cases for their Webflow site. This person is the lifeboat of the Webflow team when the client comes with crazy dev requests.
There is no doubt that collaboration in Webflow is one of the pillars where the platform is putting its attention and resources. If your are an agency delivering multiple Webflow projects, dedicated roles is something to look at right now. This is the start of Webflow efforts on delivering collaborative features.