Menu
Why we built Client-First: The story
Processes are efficient until they aren't. It's intriguing how a process can function flawlessly, but a small change in the number of people involved can disrupt it. Processes can become ineffective with the addition of people.
As our team has grown from 1 to 5, then 10, 20, 30, and now 50 employees, we've experienced this many times through many parts of the business. With each growth milestone, things broke. Processes that were seamlessly golden for a smaller team quickly ‘go bad’ as the team expands.
Website build strategy and naming convention was one of the processes that faced changes.
Initially, many of our Webflow developers followed a similar approach when building websites. While not the same, the project builds were close enough that anyone could jump into another build and make changes.
This worked well for years. With just a few people and minor differences to the projects, it was manageable. Keeping track of each person's site build style was not an issue. However, as our team grew, this approach became less effective.
As we grew the amount of Webflow developers at Finsweet (maybe 8-10?), this process was no longer efficient. The variations across builds became too complex, leading to increased learning curves and decreased project sharability among the team. Working on a team member's project became increasingly challenging, leading to difficulties in collaboration.
We needed a formal system that unified all of our build strategies into one approach. We were on a mission to create a common rule book for Webflow projects that the entire team could agree on.
This is why Client-First was built.
What is Client-First?
Client-First is a style system, build strategy, and naming convention for building Webflow websites.
We won’t explain the entire system in this article, but we will cover the most important highlights.
Read the full documentation here: https://finsweet.com/client-first
Goals and benefits of using Client-First
- Establishing an organized system for managing our projects effectively.
- Improving speed and flexibility when using Webflow Designer for website development.
- Defining a clear strategy for class usage in the project to ensure consistency.
- Standardizing a core structure that is shared across all pages.
- Creating a scalable and easily manageable Webflow build to accommodate future scaling.
- Creating a manageable project for developers, clients, and other stakeholders.
Naming convention
Client-First places a strong emphasis on clear and descriptive class naming throughout the project.
Regardless of whether a person has prior experience with Client-First, a Webflow developer, client, or anyone else should be able to understand the purpose of a class based solely on its name.
The goals of the Client-First naming convention are:
- Empower non-technical individuals to manage our website effectively.
- Ensure clarity, informativeness, and descriptiveness in our class naming.
- Provide readers with sufficient context about the purpose of each class.
- Enable easy understanding of a class's purpose just by reading its name.
- Avoid abbreviations, shorthand, or confusion in class naming.
- Provide context about the relationship of each class with the website.
- Utilize prefix and keyword organization techniques to create meaningful names.
- Visualize the purpose of a class based on its name for easier comprehension.
Webflow focused build strategies
- Classes strategy
- Core structure strategy
- Typography strategy
- Spacing strategy
- Folders strategy
Tools included in Client-First
At Finsweet we love to make tools. This excitement for tool making naturally extended to Client-First.
We believe in building tools that enhance our productivity and effectiveness. That's why we've developed the "Fluid Responsive Generator" and "Folders" specifically for use with Client-First.
Fluid Responsive Generator
This tool is a CSS snippet generator that integrates with Client-First projects.
Benefits of using the fluid responsive strategy with Client-First include:
- Ability to create websites that scale and adapt to different screen sizes, ensuring a consistent user experience across devices.
- Flexibility to choose whether to add the fluid responsive strategy as an optional add-on to any project, without changing the existing build strategy.
- Capability to add fluid responsiveness at any stage of the project, even after all other development work is completed.
- Normal browser zoom functionality is maintained, allowing users to zoom in or out as needed.
- Respect for browser font size settings modified by end-users, ensuring accessibility and usability for all users.
Folders
Webflow is a powerful tool that allows us to visualize and manage HTML and CSS in our projects. It’s why we all use the tool.
We can visualize how a class, or set of classes, interacts with HTML on the page. However, there is no way to visualize how many, or all, classes in a project work together. For example, seeing the classes and styles for an entire component.
To address this challenge, we developed Folders as a virtual organization tool within Webflow projects.
Folders allow us to group and visually manage classes using a simple naming convention within Webflow Designer through the Finsweet Extension.
By using the underscore character, we can create a virtual folder system within Client-First, which helps us organize Webflow projects of all sizes. This folder system enhances our ability to visually organize and manage classes, making it easier to understand the structure and relationships of classes within our projects.
How we built Client-First as a team
As a team at Finsweet, we built Client-First collaboratively and iteratively. It was not a decision imposed by the company, but rather a collective effort.
It started out with a small task force that created the initial draft documentation. The draft docs were sent to the Finsweet Webflow developers team and they ripped it apart with feedback.
New ideas were introduced. Ideas and strategies were challenged through intense Slack conversations. Anything that didn’t make sense or could be improved was called out.
It was a full QA initiative over months of review and debate. It allowed our entire team of talented devs to contribute to the project.
Once the team felt that Client-First was ready for internal use at Finsweet, it was declared ready for the public Webflow community to benefit from.
Want to learn more about our democratic voting process for Client-First? Check out the emoji vote article.
Impact of Client-First at Finsweet
The impact of Client-First at Finsweet has been significant.
Within just one month of implementing Client-First, the team experienced improved collaboration and communication.
The Webflow developers found it "so cool" that they could easily understand and work with projects created by their colleagues, as the naming style, page structure, and identification of utility classes remained consistent across projects.
That’s the beauty of Client-First and why it works for Finsweet:
When you go into someone else’s Client-First project, it feels like your own project. The naming style is the same. The page structure is the same. Utility classes are easily identified. The learning curve is very low.
Scaling Agency
Client-First has directly helped us scale Finsweet Agency efforts.
As client projects become more complex and larger in size, the ability to have multiple team members working on the same project is crucial.
The consistency and unity brought by Client-First allow multiple Webflow developers to work seamlessly together on a project with the same build strategy. This becomes especially valuable as projects grow more complex, as it ensures that everyone is on the same page, following the same naming conventions, and maintaining a consistent approach to HTML and CSS.
This collaborative environment facilitated by Client-First promotes efficient teamwork, minimizes confusion, and streamlines the development process, ultimately leading to a more successful outcome for the project.
Taking time off of a project
Client-First also proves valuable in situations where a Webflow developer needs to take time off from a project due to expected issues inside or outside of work.
The automatic project knowledge and the ability to hand off projects to co-workers through Client-First facilitate smooth transitions and prevent overwork, allowing the team to support each other effectively.
Hiring made easy
As we continue to grow our team at Finsweet with more Webflow developers, Client-First helps us hire the right people.
The public and live nature of the Client-First docs allows new hires to be “ready to work” immediately. New Webflow developers can start working immediately without training or learning curve.
By evaluating the quality of Client-First builds from candidates, our team can assess their HTML and CSS knowledge and determine if they are a good fit for the team.
Why is it called “Client-First”?
Client-First = We put our clients' interests first in the Webflow build process.
Most clients want us to
- Create a scalable Webflow project
- Create a project quickly, without losing quality
- Create a project that many people within our agency can manage
- Create a project that we can hand off to a different Webflow developer/agency if the client decides to change vendors
- Create a project that a client can manage inside Designer*
Not all clients want to manage their Webflow project. Some do, and most don't. The process for building in Client-First is the same.
Our goal is to deliver all of these benefits with each build we make for our clients.
Client-First Board of Directors
We launched the Board of Directors.
This is a public community-focused group of people to make decisions for all Client-First updates.
Finsweet has released its full ownership of Client-First decisions for the greater good of the community.
Client-First was always made to be democratic. Now we’ve taken that to the next level.
Our goal is to bring a new level of transparency and community direction to product development.
