No-code visual development platforms like Webflow (as opposed to low-code or full-code platforms) offer the ability to build out projects more quickly and easily than ever by providing a simple, straightforward interface. But without a carefully considered approach to development, that ease and access might not stay intact through the client handoff.

The degree to which the client is able to maintain the project is largely dictated by the developer and the development process, and whether the developer is making choices that favor short term expediency or long term maintainability. At Edgar Allan, we think backwards from the client handoff when making development decisions, and have developed a few principles of no-code stewardship that empower our clients to control their own destiny.

‍
Avoiding a Code Marriage

Launching a project can oftentimes feel like a marriage, and is usually followed by a short honeymoon period. Web projects are, by nature, living projects that are rarely perfect at launch, and there is normally a shared desire to optimize after launch, which is a good thing. In a healthy developer-client relationship, both parties should be striving to build the best product possible. But in a low-code or full-code environment, the client is forced to return to the developer for every minor design tweak. That means in some cases the client may forego needed adjustments because of the effort or cost of implementation, and in others the client may provide a never-ending list of tweaks that should've been caught in the design stage. Whether the developer gets burned out on small changes or simply needs to focus more time on the next project, the honeymoon period is guaranteed to end at some point.

The Joy of Accommodating Small Changes

‍

Fortunately, a no-code handoff can be a far more casual affair. If a project is built with client maintenance in mind, they can often go beyond editing text and images in the Webflow editor into adjusting and even re-sequencing content in the designer. In a best case scenario, this allows a client to try multiple small tweaks, rather than making an educated guess and putting a quarter into the Developer Machine, and it minimizes interactions with the developer to larger design changes.

This ideal scenario, however, doesn't come naturally. It's tempting, with the tools afforded by no-code development environments, to focus on what's quick and easy for the developer in the short term. But being a good steward of no-code development means making sure that the powerful tools that no-code environments offer don't get lost in the development process.

‍

‍

What Does Bad No-Code Stewardship look Like?

Dragging and dropping divs, swapping colors or defining font styles can all seem deceptively easy in a visual coding environment. But, without a little foresight, things can turn sideways pretty quickly. With great power, in other words, comes great responsibility. It's a little like cutting hair... you can always even things out by taking a little more off the other side (or by nesting another div or stacking on another subclass, in our case), but if you keep returning to that strategy you're gonna end up with a big mess that you can't back out of. Going about it too quickly or carelessly is guaranteed to yield problems, and a client who receives a build with unclear interdependencies, confusingly nested components, or subclasses galore may feel like they're stuck with a bad haircut they can't style themselves.

We've all seen messy builds, and we've all waded into this territory once or twice...

• Unnamed divs with unclear purposes: Div 134, Div 199, Div 226, Div 394

• Divs originally named after their content: Cat Photo Wrapper div contains photo of dog

• Confusing div hierarchy: Elements nested 10^156 divs deep

• Ambiguous component start and end points: No sections?>???

However, it doesn't have to be this way.

‍

Six Principles of Good No-Code Stewardship

A good steward of no-code development is always thinking backward from project the handoff. The work has to look good in the browser, but the client's experience in maintaining the project long-term needs to be equally considered.

Simplicity

Wherever possible, think from broad to specific. Cascade styles whenever you can, beginning with global elements and using classes to define exceptions. The fewer style declarations are made, the easier it will be for the client to find the one they need to edit. Strive to achieve your look and feel by declaring as few styles as possible.

Self-evidence

Strive to make your build as self-evident as possible, which might mean avoiding unnecessarily complex nestings or obscure, shorthand naming conventions. The simplest, clearest way to solve a problem is nearly always the best way, even if that requires a little more thought or effort.

This is especially important when naming elements. Creating a clear, predictable system can save development time in the long run, and will help the client wrap his or her head around what's what.

Modularity

So much time can be saved and simplicity achieved by thinking modularly. This works on several levels. It may mean thinking about class naming modularly: stringing together utility classes to create commonly used looks or behaviors. It may mean thinking about sections modularly: grouping components by section so that they can be freely re-ordered. Or it may mean thinking about interactions modularly: decoupling interaction classes from style classes, so that an interaction can be used repeatedly throughout the site and freely attached to different elements.

Intuition

Where possible, use pseudo-classes and selectors in HTML embeds to automatically style elements such as CTAs or bulleted lists, making them behave as intuitively as possible. For instance, hard-coding styles as a ul > li:last-child will remove the need for the client to manually add a "Last" class to the final list item.

This might also mean, instead of appending an arrow icon to a CTA with a span, building it out as an After pseudo element, like .CTA::after. This way, the client doesn't need to think about adding it, and won't be able to accidentally delete it.

Wherever a manual process can be automated with a quick CSS snippet, this is going to make the experience more intuitive for the client.

Note: Custom CSS placed in the page-level or global "Custom Code" section will not be reflected in the Webflow designer, but custom CSS in an HTML embed will be reflected.

Systems

The integrity of a design system can mean the difference between a quality look and feel that survives long-term maintenance and one that doesn't. And each deviation from the design system means a possible style fork when new pages or elements are created. For instance, if a headline style works in nine places, but doesn't work in one, the ideal solution is to edit the content by rewriting the headline to be a few words shorter, rather than to compromise the design system by introducing an exception or by changing the size of all headlines, which may have been originally sized relative to other elements.

Polish

In the heat of the moment, the best way to figure out how to build a complex component might be to experiment with a bunch of unnamed divs in order to find the best approach. (This is a general description of development for most of us.) But after the component is built, it’s important to simplify and rename. The effort it takes to refactor in the near term will be earned back over time when you can build it correctly from the beginning next time, and the client will have fewer issues updating the component in the future.

‍

The Take Away

No-code development has to mean more than simply allowing designers to create quick and dirty builds. Thinking past quick / easy can mean empower our clients to control their own destiny.

‍