<p>Open an inherited Webflow project and you can usually date it. There is a class called <code>blue-heading</code> that is no longer blue, another called <code>section-2</code> sitting in section five, and eleven variations of a button that differ by a pixel.</p><p>None of this happens because the original builder was careless. It happens because Webflow makes it trivially easy to create a class and slightly awkward to reuse one, and that difference compounds over a couple of years.</p><h2>Name things after what they are</h2><p>The single rule that prevents most of the damage: a class describes the role of an element, never its appearance. <code>card-title</code> survives a rebrand. <code>blue-heading</code> becomes a lie the first time someone changes the palette.</p><p>This sounds obvious written down. It is still the convention most often broken, usually at four in the afternoon when someone needs one heading to be slightly larger.</p><h2>Three tiers, and nothing else</h2><p>We allow exactly three kinds of class in a project.</p><p><strong>Layout classes</strong> handle structure: containers, grids, section padding. There are perhaps a dozen and they are set once at the start of the project.</p><p><strong>Component classes</strong> describe a thing on the page: <code>card</code>, <code>card-media</code>, <code>card-title</code>. They are built once and reused everywhere.</p><p><strong>Utility classes</strong> cover the small adjustments: spacing steps, text alignment, colour tokens. They are drawn from a fixed scale, and the scale is the point. If a utility does not exist for the value you want, the correct move is almost always to use the nearest one that does.</p><h2>The type and spacing scale is not negotiable</h2><p>We define a type scale and a spacing scale in the first week and treat them as fixed. Every margin in the project is one of eight values. Every text size is one of seven.</p><p>The constraint does two things. It makes the site look composed rather than assembled, because relationships repeat. And it makes the project maintainable, because a new person can only make choices that were already sanctioned.</p><h2>Combo classes, sparingly</h2><p>Webflow combo classes are useful and dangerous in equal measure. Our rule: a combo class may modify a component, never define one. <code>card is-featured</code> is fine. <code>card is-featured is-large is-dark blue</code> is a class system that has given up.</p><p>If you need more than one modifier, you probably need a second component, and that is a cheaper conversation to have at build time than eighteen months later.</p><h2>Write the convention down</h2><p>The system only survives if the next person can find out what it was. Every project we hand over includes a page inside the site itself, unlisted, showing every component and every utility with its class name next to it.</p><p>It takes a day to build. We have never regretted it, and clients who came to us from another studio always say the same thing: it is the first time they have been able to see what they own.</p>

The Webflow class system we use on every build

<p>There is a predictable moment in a redesign where somebody says they love the new direction, and what they mean is that they love the photograph in the hero. Nothing about the structure has been agreed. The project proceeds anyway, and the structural problems surface in build, where they are expensive.</p><h2>Colour is a very effective anaesthetic</h2><p>A polished visual makes a bad hierarchy feel resolved. Reviewers stop asking whether the second section should exist and start discussing whether the accent is too warm. Both conversations are worth having, but only one of them is load bearing, and it has to come first.</p><p>Greyscale removes the anaesthetic. When a wireframe is grey boxes and real sentences, the only thing left to react to is the argument the page is making.</p><h2>Real copy, not placeholder text</h2><p>Wireframing in grey only works if the words are real. Latin filler hides the two problems you most need to find: that the headline does not fit in two lines, and that nobody knows what the third section is for.</p><p>We write the actual copy at wireframe stage, or as close to actual as we can get. It is slower for a week and considerably faster afterwards.</p><h2>What we are looking for</h2><p>Three questions, in order. Does the page answer the question the visitor arrived with, in the first screen? Is there exactly one obvious next action? Could a section be deleted without the page losing anything?</p><p>That last one is the useful one. A wireframe review that does not remove something has usually not been a review.</p><h2>Then the visual stage is quick</h2><p>Once structure is settled, surface design moves fast, because every decision has a reason to point at. The hierarchy already exists; type, colour and imagery are making it visible rather than inventing it.</p><p>Clients occasionally find the grey stage frustrating, and we understand why. It is worth saying at the outset that it is deliberate, and that the pretty version arrives sooner because of it.</p>

Why we wireframe in grey

<p>Ask a marketing team where their brand guidelines are. The answer is usually a pause, then a search of a shared drive, then a file named something like <em>Brand_Guidelines_FINAL_v4_updated.pdf</em>, last opened eight months ago.</p><p>The document is not the problem. The format is.</p><h2>Guidelines get consulted under pressure</h2><p>Nobody reads guidelines for pleasure. They are opened by someone building a slide at half past five who needs to know whether the logo can sit on a photograph. That person has about ninety seconds of patience.</p><p>A hundred-page PDF fails that moment completely. The answer is in there somewhere, on page forty-three, in a section called Visual Territory.</p><h2>Publish it as a web page</h2><p>Every set of guidelines we produce is a live page on the client site. It is searchable, it has an address people can bookmark, and when something changes it changes everywhere at once rather than forking into four versions.</p><p>Assets download directly from it. If getting the correct logo requires emailing a designer, people will use the wrong logo, and they will be right to.</p><h2>Show what is wrong</h2><p>Most guidelines only demonstrate correct use. That teaches far less than it seems to, because the reader has to infer the rule from the example.</p><p>Showing misuse next to correct use is faster and stickier. The stretched logo, the accent used as a background for body text, the wordmark on a busy photograph. People remember the wrong one and avoid making it.</p><h2>Shorter than you think</h2><p>Our guidelines usually run to one long page. Logo and clear space, type scale, colour with contrast pairings, photography direction, tone of voice with three before-and-after sentences, and a download panel.</p><p>Everything that does not change behaviour is cut. A page on the philosophical meaning of the palette changes nobody behaviour, and its presence makes the rules that matter harder to find.</p><h2>Give it an owner</h2><p>Finally, one named person keeps it current, and the page says who that is. Guidelines without an owner are a snapshot of what the brand was on the day the project ended.</p>

Nobody reads your brand guidelines

<p>Launch problems are rarely dramatic. The site goes live, it looks right, and then over the following fortnight you discover that the contact form has been posting into nothing and that half your search traffic is landing on a 404.</p><p>Here is what we work through in the final week, in the order we do it.</p><h2>Redirects, mapped one by one</h2><p>Export every URL from the old site. Every one gets a destination on the new site or a deliberate decision that it should not have one. Automated rules cover the bulk of it, but the pages with the most inbound links are the ones the rules get wrong, so those get checked by hand.</p><p>This is the single most expensive thing to get wrong and the easiest to fix in advance.</p><h2>Metadata, page by page</h2><p>Every page needs its own title and description. Two pages sharing a description is a defect. We read the list as a spreadsheet rather than page by page in a browser, because duplicates are obvious in a column and invisible in a tab.</p><p>Open Graph images get checked by actually pasting links into a chat app. Preview tools lie; group chats do not.</p><h2>Forms, tested with real submissions</h2><p>Submit every form on the site as a real user would, with real values, from a phone as well as a laptop. Confirm the notification arrives in the inbox somebody actually reads, not a shared address that forwards to a person who left.</p><p>Test the failure path too. Submit with a missing required field and an invalid email, and check that the error is announced to a screen reader rather than only turning a border red.</p><h2>Analytics that fire</h2><p>Confirm the tag is on every page, including the ones outside the main template like the 404 and the thank-you page. Fire each conversion event once and watch it arrive in real time.</p><h2>Accessibility, keyboard first</h2><p>Tab through every page from the top. You are looking for three things: that focus is always visible, that the order makes sense, and that you never get trapped. Then check contrast on anything that changed late, because late changes are where contrast goes to die.</p><h2>Performance on a real device</h2><p>Test on a mid-range Android over a throttled connection, not a laptop on office wifi. Check the largest image on every template, and look for the third-party script that somebody added in week six and nobody remembers approving.</p><h2>The boring infrastructure</h2><p>Certificate valid and auto-renewing. One canonical hostname, with the other redirecting to it. Robots file allowing crawling and pointing at a sitemap that lists only pages that exist. Favicon present at every size.</p><h2>Launch on a Tuesday morning</h2><p>Not Friday afternoon. Whatever you missed will surface within about four hours, and you want the people who can fix it awake, at their desks, and not already at the pub.</p>

What we check in the week before a site goes live

<p>A recurring conversation: enquiries are down, the leadership team have decided the website looks dated, and there is budget approved for a redesign. Could we start in March.</p><p>Sometimes the site really is the problem. Often it is the most visible thing that can be changed with an approved budget, which is not the same as being the cause.</p><h2>Find out where it broke</h2><p>Before quoting, we ask for analytics access and look at one thing: when the decline started, and which channel it started in.</p><p>If organic search fell off a cliff in a single week, that is an algorithm update or a technical fault, and a redesign will not touch it. If paid traffic held steady while conversion fell, something changed in the offer or the market. If every channel drifted down slowly over two years, the content stopped being maintained.</p><p>Each of those has a different fix, and only one of them is a new website.</p><h2>The most common actual cause</h2><p>In our experience it is neglect rather than design. Pages that were accurate three years ago, pricing that no longer matches, case studies from clients who have since churned, a blog whose last post is dated.</p><p>Visitors read staleness as risk. A beautifully redesigned site with the same out-of-date content converts about as well as the old one, and costs considerably more.</p><h2>What we suggest instead</h2><p>Often a fraction of the redesign budget spent on rewriting the twenty pages that receive traffic, fixing the technical faults, and putting someone in charge of keeping it current.</p><p>Then, if the numbers still say the site is the constraint, redesign with much better information about what it needs to do.</p><h2>Why we tell people this</h2><p>Partly because taking money for the wrong project ends badly for everyone about four months in. Mostly because the clients we like working with are the ones who wanted to be told.</p><p>If the honest answer is that you do not need us this year, we would rather say so and be the studio you call when you do.</p>

A redesign will not fix your traffic problem

We work as one team across strategy, design and build, so nothing gets thrown over a wall halfway through.

Notes on Webflow, interfaces and handover.

The Webflow class system we use on every build

Archive

Why we wireframe in grey

Nobody reads your brand guidelines

What we check in the week before a site goes live

A redesign will not fix your traffic problem