Looking for ways to optimize your workflow and deliver outstanding products to your clients? You might want to consider Finsweet's Client-First approach. This innovative set of guidelines has been causing a buzz in the Webflow community, aiming to aid Webflow developers in crafting more organized, efficient, and maintainable websites.
The term 'The Future of Webflow Development' might be a tad over-dramatic, but who doesn't love a catchy title? True, we could dream about more advanced functionalities, like multilingual support, expanded CMS limits, or advanced membership site features. Yet, we're staunch supporters of Webflow, confident that these developments will arrive in due course. So, let's get back on track… and focus on the available tools that could make our Webflow journey smoother.
The question is: Is Client-First the right choice for all Webflow designers or developers? We're here to delve into the basics of Client-First, weigh its advantages and disadvantages, and help you decide if it's the perfect fit for you. Let's journey through the realm of Finsweet's 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:
- Save time and resources by streamlining the development process.
- Ensure their projects are easy to comprehend and maintain for team members and clients.
- Ensure their projects are easy to comprehend and maintain for team members and clients.
For a more in-depth introduction, you might want to check Joe from Finsweet's explanation:
Advantages of Adopting Client-First
- Streamlined Workflow: Following Client-First's best practices can eliminate unnecessary steps and foster a more efficient, organized development process. Faster project completion and fewer roadblocks are just some of the perks.
- Effortless Collaboration: With Client-First, projects are structured in a manner that's easy to understand and work with, making collaboration simple, even with new team members or clients.
- Improved Maintainability: A key principle of Client-First is designing websites with future maintenance in mind. This results in clients having an easier time managing their websites, enhancing their overall experience.
- Consistency: Client-First provides clear guidelines that ensure all your Webflow projects adhere to a consistent structure and design, a vital aspect for agencies and larger teams.
- Accessibility: One of the significant focuses of Client-First is accessibility. The methodology primarily uses REM instead of Pixels, allowing everything to grow and shrink with the text size in the browser.
Drawbacks of Adopting Client-First
- Learning Curve: Like any new methodology, Client-First comes with a learning curve. Developers need to invest time to familiarize themselves with the approach, which may initially slow down their progress.
- Not Ideal for Every Project: Client-First is designed for Webflow developers who prioritize organization and maintainability. However, smaller or simpler websites might not require this level of structure.
- Mindset Shift: Adopting Client-First requires discarding old habits and embracing a new perspective on Webflow development. This shift can be challenging for developers accustomed to a more freeform approach.
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 projects 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 thought 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. Yes, we've made the switch to Client-First. Although it required substantial effort and may not be the fastest build method, it's very accessible for other developers when they open the Webflow Designer. Plus, it is more accessible to end-users on the web, particularly those with visual impairments.
So, is it worth it? For us, yes. It aligns with our values of accessibility for our clients, end-users, and other Webflow developers. Whether you decide to fully embrace Client-First, adopt elements of it, or stick with your current approach, remember to continually seek ways to optimize your Webflow development process. Happy designing!