Digital Agency for Tonbridge Businesses

From Approved Design to Working Site

A design file is a picture of a website at particular widths. A website is something that has to behave sensibly at every width, on every device, for every visitor, with real content of unpredictable length.

The gap between those two things is where build quality is decided. Handled well, the result is recognisably the design, working properly. Handled poorly, it is an approximation that breaks in ways nobody anticipated — and the designer, who was not consulted, sees it first when it goes live.

Most of that gap is closed by asking the right questions before building rather than making assumptions during it.

Reading a Design File Properly

Interpreting a design is not simply reproducing what is visible.

It means identifying which elements are the same component appearing repeatedly, and which are genuinely one-off. Establishing whether spacing follows a system or was set by eye. Working out which measurements are deliberate and which are incidental.

Where a file is well constructed — consistent styles, sensible naming, components used properly — much of this is explicit. Where it is not, the build involves inference, and it is worth confirming rather than guessing. A short conversation about which decisions were intentional saves considerable back-and-forth later.

The Widths Nobody Designed

Most designs are produced at two or three widths. Websites are viewed at hundreds.

What happens between the designed breakpoints is a build decision by default, and it is where things most often look wrong. A three-column layout has to become two and then one — in what order, and which element leads? A heading sized for desktop needs a scale that holds down to a small phone. A navigation designed horizontally needs a mobile equivalent that was probably never drawn.

These are answerable questions and they are cheaper to raise before building. Left to be resolved silently during development, the result may work while not being what anyone intended.

Content That Is Not the Length in the Design

Design files contain content of convenient length. Real sites do not.

A heading designed as four words receives eleven. A card designed with three lines of description gets one on some items and seven on others. A testimonial gets a name considerably longer than the placeholder.

Building for that means components that behave sensibly across a range rather than at one length — which is a construction decision, and much easier to make deliberately than to retrofit once real content arrives and something breaks.

Building It From Reusable Pieces

A site assembled from proper components is more consistent to build and considerably easier to change afterwards.

Where a card, a button, a section or a navigation exists once in Webflow and is placed wherever needed, a later change happens in one place. Where each instance was built individually, the same change is a hunt through the site.

The same applies to CMS structure. Anything that repeats — services, projects, team, articles — belongs in a collection with one template rather than as individual pages. That is a decision taken during the build, and reversing it later is disproportionately awkward.

Motion and Interaction as Specified

Design files show states; they rarely show transitions between them.

How long a menu takes to open, whether a hover is instant or eased, what happens as something enters the viewport — these are usually undefined and end up decided by whoever is building. Consistency then depends on one person's instincts.

Agreeing a small set of conventions — standard durations, standard easing, what animates and what does not — keeps interaction coherent across a site. It is also worth checking that motion does not delay content appearing, since an effect that looks considered in isolation can be irritating when someone is scrolling to find something.

Where the Design Needs Adapting

Occasionally something drawn does not translate well, and the honest response is to raise it rather than build it badly.

Text over a busy image that becomes unreadable at some widths. A colour pairing with insufficient contrast for body text. An interaction that assumes a mouse and has no touch equivalent. A layout requiring content of an exact length nobody can guarantee.

These are not design errors so much as things that surface at build stage. Raised as questions with a suggested resolution, they get fixed quickly. Built as drawn and discovered later, they become a defect somebody has to unpick.

Restraint With Custom Code

Most requirements can be handled natively. Some genuinely cannot.

The judgement matters because custom code is a long-term commitment — it needs maintaining, it can break when something else changes, and it is often understood by one person. Reaching for it to avoid rethinking a small detail trades a minor compromise for a permanent dependency.

Where it is genuinely required, it should be deliberate, documented and contained. Where the platform can do the job cleanly, that is almost always the better answer.

Checking It Actually Works

Build quality shows in testing rather than in the finished screenshot.

Worth checking before anything goes live: real devices rather than a resized browser; the awkward widths between breakpoints; long and short content in every component; keyboard navigation reaching everything with a visible focus state; forms submitting and confirming; and behaviour across the browsers your visitors actually use.

None of this is glamorous, and it is the difference between a build that holds up and one that starts generating small corrections a fortnight after launch.

Working With a Kent-Based Digital Agency

Maidstone Digital is based in Maidstone and works with businesses in Tonbridge, elsewhere in Kent and further afield. We do not have premises in Tonbridge. Most work is carried out remotely and reviewed through shared files and regular calls, though we are happy to meet where useful.

This page covers building designs into working websites. If your interest is specifically organic search — particularly planning search considerations before a rebuild — our SEO services for Tonbridge businesses page covers that.

Tonbridge Digital Agency FAQs

Can you build from our designer's Figma file?

Yes, and it is a common arrangement. A well-structured file with consistent styles and proper components makes the build faster and more accurate. Where a file is less structured, we would ask a few questions about which decisions were deliberate rather than inferring — that conversation is quicker than correcting assumptions afterwards.

What if the design only covers desktop?

We would raise how it should behave at other widths before building rather than deciding silently. Sometimes the designer wants to produce those views; sometimes they are happy for us to propose an approach and review it. What causes problems is nobody deciding, which leaves the mobile experience to be resolved by default.

Will the build match the design exactly?

Very closely, and occasionally something needs adapting — contrast that does not hold up for body text, an interaction with no touch equivalent, or a layout depending on content of an exact length. We would raise those with a suggested resolution rather than either building something that does not work or changing it without asking.

Do you use custom code?

Where a requirement genuinely needs it. Most things can be handled natively, and that is usually preferable — custom code has to be maintained and can break when something else changes. Where it is genuinely necessary we keep it contained and documented rather than scattered through the build.