The following is what we shared internally with the team BX to get our discussion started to build more effective websites.
TLDR
In an assembly line of a manufacturing company, the best assembly process is to get the best raw material/defect-less parts to begin with. That’s why when they find an issue, they stop an entire assembly line to address the issue. There will be delays initially but once the issue is solved they won’t have any useless inventory, recalls, and class action lawsuits arising from the defective products. In the world of web development, having defect-less parts in the assembly line means having a completed design of an entire website, not a semi-finished design that comes in batches.
Video source: https://www.youtube.com/watch?v=F5vtCRFRAK0
Let’s start cooking when and only when we have all the ingredients ready
I’d like to take this opportunity to align ourselves better going forward with our future projects. Specifically, I'd like to discuss these 3 points.
- Design handoff in Batches vs. Design handoff in Completed Whole
- Separated development of responsive breakpoints vs. Unified development
Design handoff in Batches vs. Design handoff in Completed Whole
I believe we could build faster if we start with a completed design of the entire website even if a dev has to wait longer initially to get the finished design. Let's say we start building with the approved batches of 2-3 pages but when the next batch comes in, they have changes that would affect the first batch because of client feedback, etc. That requires time to go back and change the code as if you are building the two different things twice, instead of building two things at once.
For instance, a first batch could have pages with a white header background. All pages of the first batch will be built with white background as specified. But, the next batch comes with the header section in dark background. It appears as a simple change. “Just change the background to black! What’s the big deal?”, you might think. It turns out the change of the background color can affect other sections that don't need to be affected in the first place. If we knew they'd be two variations, we could've built it without interfering with other sections, but now a dev has to figure out how to 1) introduce a new background color of black, 2) how to keep the first batch background in white, 3) how to maintain background color of other sections globally unaffected. And because the new background color has been introduced, 4) the animation and 5) the background color of the navigation bar has to be changed also.
The example above is an over-simplified one, but that's how web development works in principle. In other words, the developer writes a situation-specific, local code by default. That’s faster if you're building a small site and easier to keep track of any changes. But as websites become bigger, the code is written in a way that is globally optimized because we don't want to write the same code hundreds of times everywhere on the site. It creates more complexity but for the sake of efficiency, it’s a necessary practice to use a global element/class structure. The problem arises when you change the local elements to global elements or vice versa. That increases the risk of bug and design inconsistency throughout the site. Meaning more QA time for the producer and designer later. We may think we are saving time by developing in batches but we could risk more time for QAing down the road.
I don't know about how Shopify and WordPress sites are built but I believe it’s well worth the wait to have the entire site’s design done first, so a developer can figure out when and where to use the local elements and global elements to best structure the entire site, not just a portion of the site and try to patch them up together later.
Separated development of responsive breakpoints vs. Unified development of responsive breakpoints
We should start developing a site when and only when the designs for all breakpoints are ready. As we know, when a Webflow developer builds a desktop design, the dev is already developing for other responsive breakpoints. In other words, the dev is structuring the desktop site in a way that could best adapt to the tablet and mobile views.
For example, it’s common to see a 2 column layout in desktop view changed to a single-column layout with elements stacked vertically in a tablet or narrower viewports. But, if the designer makes a tablet layout that is different from the norm like injecting a new element in between them from a different section right below (or introducing a completely new element for a specific breakpoint), that would require a new code structure from a desktop breakpoint because it wasn’t originally made to house that design unique to tablet breakpoint. We could of course build an entirely new tablet design and hide the original desktop design in the tablet breakpoint but that would mean a client needs to edit the two (or three for mobile!) separate contents when updating.
Suggested options for the designer would be either 1) handoff a desktop design only and let a Webflow developer handle the design and development of other breakpoints, or 2) in case a designer needs to have complete control of the design, the Design team can benefit more by handing off the design to a Webflow developer when the design for ALL breakpoints are ready. Again, that would translate to less QA headache later for all parties involved.
To summarize, I’m a lazy Webflow developer seeking efficiency and effectiveness as a whole project. It may sound counterintuitive to wait until all designs are done. But I believe the simpler approach will result in less QA time, less friction, and better websites for all of us.
Looking forward to hearing your thoughts :)
