Edgar Allan has been building the course as a standards guide to supplement the amazing Webflow University over the past year.
The idea was to outline how they approach things like class naming, padding units and working with primitive elements, and they have learned a ton while putting this together and are excited to start the conversation on how to build beautiful experiences quickly at scale!
Building for Scale and Stability in Webflow
Over the past five years of using Webflow in a team environment, Edgar Allan learned a number of things about what works and a few things about what doesn’t.
As their client needs grown in scope and complexity, they have to think not only, “How might we build the next best thing?” but also, “How do we do that at scale?”, and then there’s “How can we have more people, across disciplines, contributing to the project in a productive way?” This hasn’t always been painless.
One of the initial mistakes was creating class names inconsistently across a build. Class naming may feel secondary during the design process, but returning to a build six months later to make major updates will change your mind. And trying to interpret another designer’s idiosyncratic approach to styling can be even worse. Div 273? Header Subpage Alt 2? Forget about it.
The answer is to create a guide for how they build things. More than just a how-to, though (Webflow University has got that covered), they’ve started to outline the philosophies on why they approach certain aspects in specific ways.
Basics of collaboration
Webflow is easy to use because it allows for better collaboration between design, content and development teams. In the old days, the agency basically have had a series of static documents (Word, Acrobat, Photoshop) describing every element of the design, and it was up to the development team to bring everything together. This approach was great for creating Jira tickets, or design by walkie-talkie, but not so great for creating a collaborative team environment.
Creating the wireframes and core design system in Figma, then starting to construct pages in Webflow as writers edit content directly in the build.
Who is this for?
For the last year, Edgar Allan has been working on documenting these ideas into a 12-chapter guide. Their first audience have been themselves; they needed something written and considered so when they bring new people onto projects they can understand the approach. The second audience was their clients, so that when they hand over a build, they have a training manual to later reference when they create new pages.
Edgar Allan loves continuing to work with their clients, but one of the great things about Webflow is that you don’t always *need* to go back to a developer to make updates. And the third audience has been the Webflow community. So, they are excited about this platform and look forward to both sharing what they know and getting feedback on what they could do better.
Here, you can find Edgar Allan’s guide on Webflow for Teams.