Archive · Chapter 9 · The Webflow years4 min read

Designing in the browser

Chapter nine of the archive: how designing in the browser reshaped the work, from class naming systems to style guides and component thinking.

From the Nerd News Archive: our road retold in the voice of the moment. A story written today.

For years the design lived in one place and the website lived in another. You mocked something up in a design tool, got it approved, then rebuilt it inside a page builder and watched it drift from the mockup one compromise at a time. Designing in the browser collapsed those two worlds into one, and it has quietly rewired how I think about this job.

In Webflow, the thing I am designing is the thing that ships. There is real HTML and CSS under the canvas. When I adjust a margin I am writing a rule, not drawing a picture of a rule. That sounds academic until the first time a client resizes their window and the layout just holds, because the layout was never a picture.

Name your classes like you will live with them

The page builder years let me be sloppy about names. Divi never asked what anything was called; it buried the structure under modules and let me get away with never thinking about it. Webflow puts the class name in my face on every element I touch, and every lazy name becomes a small debt that collects interest.

My earliest Webflow projects are full of classes like div-block-47 and heading-copy-copy-2. Opening one of those projects a month later is archaeology. I dig through the style panel trying to reconstruct what past me was thinking, and past me was not thinking. So I adopted a rule that has since spread into everything I do: name every class as if a stranger inherits the project tomorrow, because the stranger is usually me.

I am not alone in this, and that is the encouraging part. The community has grown real methodologies around naming. BEM thinking crossed over from the hand-coded CSS world, and newer systems like Client-first exist specifically to make Webflow projects legible to whoever opens them next. The details differ from system to system. The spirit is identical: structure is communication, and a class name is a sentence you write to the future.

The style guide is the first deliverable

I no longer start a build with the homepage. I start with a style guide page: every heading level, both body sizes, the full color palette, every button and its hover state, the link style, the spacing scale. It is the most boring page in the project and the most important one.

The style guide forces decisions to happen once, early, and on purpose. Without it, an h2 gets styled slightly differently on five pages by five versions of me in five different moods, and the site slowly develops that homemade wobble everyone can feel and nobody can name. With it, the h2 is decided one time and every page inherits the decision.

  • Every heading level and paragraph size, styled once on a base class or the tag itself
  • The real color palette, with the accidental almost-grays hunted down and deleted
  • Every button state designed up front, so hover is a decision instead of an improvisation
  • A spacing scale I actually committed to, instead of margins eyeballed one section at a time

Components before pages

The other habit the browser taught me is building parts before wholes. The navbar and footer live as symbols, built once and reused everywhere, so a change in one place is a change in every place. Cards, feature sections, testimonial rows: each gets designed as a component with its own rules, and pages become arrangements of decided things rather than fresh inventions.

This changed my client conversations more than I expected. We used to review pages, which meant every review reopened every decision. Now we approve a card once, and the card is approved everywhere it appears. Feedback gets sharper because the question is smaller. Nobody debates the whole homepage when the actual issue is one component's padding.

It also changed my estimates. A site is no longer twelve pages of unknown effort; it is one style guide, a dozen components, and then assembly. The scary part of the project moves to the front, where it belongs.

The discipline outlives the tool

Here is the part I keep chewing on. None of this is really about Webflow. Naming things carefully, deciding styles once, building parts before wholes: that is simply how good front-end work has always been done, and hand-coders have known it for decades. The browser canvas did not invent the discipline. It just refused to let me skip it.

So I treat these habits as mine now, not the tool's. Whatever I build next, on whatever platform exists by then, inherits the naming rule, the style guide, and the component thinking. Tools come and go. The discipline is the career.

archivewebflowcssdesign systems

Let's talk

Got something worth building?

Whether it's a brand-new site, a rebuild, or a product you can't find off the shelf — let's make it.

Or email hello@spiderdigitalgroup.com · reply within one business day · no pushy sales

Trusted by teams who ship

Belzona Baton RougeAmerica PremierAdvanced Applications SpecialistsPrime CoatSalyers ConstructionPolymer Nation