Embracing Webflow’s Future: Is Finsweet Client-First Right for You?

We’re always on the lookout for new tools and strategies to streamline our workflows and deliver the best possible products for our clients. One such strategy that’s been making waves in the Webflow community is Finsweet’s Client-First approach. This innovative set of guidelines aims to help Webflow developers create more organised, efficient, and easy-to-maintain websites.

The title may have been a bit dramatic, with the Future of Webflow Development, but hey, you gotta have a good title. A possible better future might be multilingual support, much bigger CMS limits, advanced membership site functionality and logic that does more than wait for a form submission to add user to Mailchimp. But don’t fret, we love Webflow, we won’t move, and those things will arrive eventually, so enough waffling…

Is Client-First the right choice for every Webflow designer or developer? We’re going to explore some of the fundamentals of Client-First, its pros and cons, and whether or not it’s the right fit for you and how we’ve been using it, our journey with Client-First and the reason we’ve decided to do things we way we do. So, buckle up, and let’s dive into the world of Finsweet’s Client-First!

What is Client-First?

Client-First is a philosophy and set of best practices designed to help Webflow developers create organised, scalable, and maintainable websites. The approach revolves around a series of principles and strategies that prioritise ease of use, both for the developer and the client. By embracing Client-First, Webflow developers can:

1. Save time and resources by streamlining their development process.
2. Ensure that their projects are easy to understand and maintain for other team members and clients.
3. Deliver better, more consistent results across all projects.

We’ll let Joe from Finsweet tell you more if you don’t know already.

The Pros of Adopting Client-First

1. Streamlined Workflow: By following Client-First’s best practices, developers can eliminate unnecessary steps and create a more efficient, organised development process. This means faster project completion times and fewer headaches along the way. This one is heavily touted by Finsweet and while the speed of development might differ in the real-world Client-first shines when it comes to the speed of making global changes.
2. Easy Collaboration: With Client-First, your projects are structured in a way that’s easy for other team members and even more importantly outside Webflow developers to understand and work with. This makes collaboration a breeze, even when working with new team members or handing off a project to a client.
3. Improved Maintainability: One of the core tenets of Client-First is designing websites with future maintenance in mind. This means your clients will have an easier time updating and managing their websites, resulting in a more satisfying overall experience.
4. Greater Consistency: Client-First provides a clear set of guidelines that help ensure all your Webflow projects adhere to a consistent structure and design. This is especially important for agencies and larger teams, where consistency is key to a strong brand identity.
5. Accessibility: This is a biggie, and while accessibility involves much more than we can cover in this post, the fact that Client-First relies almost entirely on REM instead of Pixels means that the relative sizes of everything will grow and shrink as text size in enlarged or shrunk in the browser.

The Cons of Adopting Client-First

1. Learning Curve: Like any new methodology, Client-First comes with a learning curve. Developers will need to spend time familiarising themselves with the approach to structure, naming and just wrapping your head around all the documentation, which may slow down their initial progress.
2. Not Ideal for Every Project: Client-First is designed for Webflow developers who prioritise organisation and maintainability. While this is beneficial for most projects, some smaller or simpler websites may not require the level of structure provided by Client-First.
3. A Shift in Mindset: Adopting Client-First means letting go of some old habits and embracing a new way of thinking about Webflow development. This can be a challenge for some developers who are used to a more freeform approach. Definitely something we struggled with at first. It’s not something you need to overcome though, you just need to learn when things need to be ‘custom’ for want of a better word or when to just use what Client-First offer out the box.

Should You Use Client-First?

The decision to adopt Client-First ultimately comes down to your personal preferences and the specific needs of your projects. If you value organisation, efficiency, and long-term maintainability, Client-First could be a game-changer for your Webflow development process.

However, if you’re working on smaller projects or have a well-established workflow that already meets your needs, adopting Client-First might not be as beneficial. In either case, we recommend exploring the methodology and considering how its principles might enhance your current approach and have a look at how we’ve started integrating it into our workflow.

Finsweet’s Client-First is an innovative approach to Webflow development that aims to enhance organisation, efficiency, and maintainability across your projects. By following its guidelines and best practices, you can streamline your workflow, improve collaboration, and deliver a better overall experience for your clients.

However, it’s essential to remember that no single methodology is perfect for every developer or project. We encourage you to explore Client-First and consider how its principles might integrate with your current practices. You might find that it’s the missing piece you’ve been searching for, or you may realise that a hybrid approach works best for your specific needs. In essence, Client-First is a hybrid approach, you are encouraged to use the elements and structure that are there and to customise them, but to also add what you need when it would mean stacking too many styles.

At the end of the day, the most important thing is to continually evaluate and refine your development process to ensure you’re delivering the best possible work for your clients. Whether you choose to fully embrace Client-First, adopt certain elements of it, or stick with your current approach, never stop looking for ways to optimise your Webflow development experience.

What is Milk Moon Studio doing?

Client first launched just as we were starting to make much more of an effort to be more inclusive, embrace accessibility, and make our own work easier to understand for other Webflow developers.

As Webflow designers and developers we’ve always tried to embrace the Webflow community, whether that sometime entails asking a lot of questions on the forum or providing answers and helping others where we can. Over the years we’ve also tried to blog actively about Webflow, to provide help to others by showing them how we figured out how to do something, doing random things with custom code in Webflow or because of my own background an lot of analytics related Webflow content. Underscoring all this is the belief that we want our work to be accessible, not only to users who visit the sites we build, but also to other Webflow developers.

We never want to hold our clients hostage. In an ideal world, we want a client to be able to fire us in the middle of a project, take the work we’ve done for them and hand it over to another developer and have them continue what we started without skipping a beat.

From the very start, and this is a few years ago now, we tried to at least achieve that by giving descriptive class names, grouping them by section, similar to Finsweet’s component and folder structure, so that when anyone opened up the project they would know what was going on and what they were currently modifying, reusing or whatever. We also wanted to make sure that not only would a Webflow developer or Webflow designer understand it, but our clients would to. We definitely achieved that to some degree, it’s always hard to say exactly how affective you are, but I’d say it was fairly good.

The next phase for us a Webflow Studio in terms of internal growth, when it came to our skillset, was becoming better at making our sites more assessable for the user, out there in the wild, and this really involves everything from aria labels to colour contrast, text size, HTML tags and way too much to cover here. But the one big thing which we had not done right from the start was moving away from the pixel. So as we were moving to REMs Client First just launched, and it’s focus on accessibility, not only for the user looking at your site on the web, but also for another developer looking at your work and making to accessible to them immediately aligned perfectly with our values.

So we decided to try it on a small project. And after the first day we gave up and just did what we were used to, naming things as we used to, being as inclusive as possible and by then we’d already switched to using mainly REM anyway. It was just faster, with less elements on the page, and we were used to it, so it was safe.

And then later we tried again, and these were more hybrid approaches. Anyhow, skip to today. Client-First is a beast, there’s a lot of documentation, it takes a lot of time to get used to. Our process is different from a lot of people. We design every last detail in Figma first and prototype it for clients, we build in Webflow, when that is done, reviewed, and approved. We build from scratch, to match exactly what we have in Figma, we build bespoke websites.

But, we have started to use Client-First, on all project now. It’s not easier, I’d say it’s still harder. We don’t think of Client-First when we design, we give our clients beautiful sites, we give them what they want, and then when we start a new project, we clone Client-First and we have to spend a lot of time getting everything to look and work exactly like our design. Personally, it’s still faster for me to build the way I used to, I have to remember so much building a site using Client-First. It didn’t used to be that way, I just inspected what we did in Figma and styled accordingly. One element on the page could what 5 do in Client-First, to some extent anyway. Now I have to remember what I used on a section on some other page for padding-top, or I have to go and look.

So why do it, if it’s faster, and less hassle to not do it. Well, they spent a lot of time and though on best practices, standardising things, naming, folders, component and page structure, accessibility, and their Chrome extension. It’s fast in terms of page speed, fewer DOMs, works perfectly with Finsweet Attributes to do all the things Webflow doesn’t do out of the box, all kinds of things really, but when it comes down to brass tax, the reason we spend more time… it’s the adoption of what they’ve created.

To this day I’ll probably say that if I built a site today, the way I did before Client-First, my client, some person in his office that knows nothing of CSS, Flexbox or Grid, would understand what was going on better than if I did it with Client-First, and a developer would certainly know of he read through all the class names. But, and this is where the adoption of Client-First comes into play, very very few of our clients will ever try doing something in the designer, they’ll come back to us, at Milk Moon Studio, or go to some other Webflow Expert or Webflow Partner or Webflow Designer or just some dude that knows some Webflow, and they’ll open our project, and if we used Client-First they’ll know what’s going on, instantly, if they’ve ever used it, and so many have, because it has become so popular. All of Relume’s components are Client-First, same goes for many other libraries etc.

And if they don’t, well, the naming’s standardised and descriptive, they’ll figure it out very quickly. So yeah, we’ve made the switch, it took some brain power, I don’t necessarily believe it’s faster to build, but site-wide changes definitely are faster, it’s accessible for other developers when they open die Webflow Designer and if you do all the other stuff you should be doing it’s very accessible for end-users out there on the web, especially when things like visual impairment comes into play.

So, is it worth it? For us, yes, because it helps us with our values of being accessible for our clients, the users of the sites we build and other Webflow developers. The choice is yours, and we can’t wait to see the amazing projects you create as you continue to push the boundaries of what’s possible with Webflow. Happy designing

Originally published at https://www.milkmoonstudio.com.