No one’s ever claimed that the traditional, assembly line workflow — documentation, handoffs, spreadsheet-based feedback, static comps for multiple screen sizes — was an ideal way to work. And yet, for so long it was the only way teams could work. In the past, it was tough to avoid the design and development stages being interrupted by a few days — if not weeks — of thorough redlining. And God forbid a design change was requested after redline completion, causing the team to cycle back through the process all over again. A lot of time and energy was eaten up translating content from one discipline to the next using this method.
Thankfully, many of these steps are made obsolete with a collaborative visual development tool like Webflow. A copywriter can work inside the build, adjusting live text with an Editor login. Designers and developers can work hand-in-hand in the Webflow Designer, eliminating the need for copious amounts of comping and documentation. And most QA can be accomplished by the designers inside the Webflow build. This empowers a team to make a real product much faster. But smooth and efficient, real-time collaboration requires a shared group philosophy, and that begins with a shared understanding of the workflow.
Not all steps that can be thrown out should be thrown out. Just as teams vary in concentrations, experience and personality, a workflow should reflect the individual make-up of the team. Often, the workflow may even reflect the requirements of a specific project. One team may need to spend more time in design software, building out comps, while others may be equipped to jump straight into Webflow after settling on the design language. Some teams may be equipped to build out a site relying on ipsum copy, while others may require a more robust copy deck. Some projects may require heavily annotated wireframes, while others may be much more straightforward. And the ways in which team members work together should evolve over time, accounting for growing familiarity, individual growth or the addition of new team members. A general rule of thumb is that direct collaboration is always quicker than documentation, and that a team member's abilities and confidence shouldn't be boxed in by their role.
The primary advantages of a Webflow-enabled workflow are that collaboration replaces documentation at many different transition points and that production design is folded into the development process, eliminating redundancy that previously couldn't be avoided. This allows a team to stand up a prototype or live project much more quickly.
Collaboration means that team members are empowered to do more than hand off documentation. Designers can build pages. Copywriters can edit the live build. And defects can be addressed on the fly. Designing for tablet and mobile can be done in the browser, removing guesswork about viewport ranges and allowing for the straightest path towards optimization. Production design can be performed directly in the build by duplicating modules and replacing content. And all of this leads to quicker pivots, less room for misinterpretation and more predictable results.
The following are abbreviated descriptions of the process.
It's easy to create a mess in a Webflow project, but strategically minimizing the number of style declarations can go a long way toward keeping your project neat and orderly. Just as an artist begins a painting with broad strokes on the canvas, layering finer details on top as needed, so can we approach style declaration, leveraging body-wide and element-wide styles to drastically reduce the class-count, and keeping our projects manageable longterm.Take me there