Google's own UX research team measured how long it takes a visitor to form a first impression of a website's design: 17 to 50 milliseconds, faster than a single blink, and well before anyone has read a headline or clicked a link. That number matters for a very practical reason — it means a maintenance fix to the copy, the content, or the page speed cannot repair a first impression that the layout and visual style already ruined. Knowing which problem you actually have, a maintenance problem or a design problem, is the real decision most businesses struggle with before they ever talk about redesigning anything.
Why we treat the two as different kinds of request
Every change that comes through our client portal gets logged, scoped, and quoted if it falls outside the plan — that process works well for a maintenance request because the request is bounded: fix this form, update that price list, add a new section to an existing page. A redesign doesn't fit that shape. It touches navigation, templates, and the structural decisions that every other page depends on, which means the amount of judgment and rework involved is closer to a new project than a ticket. We scope and quote it separately for the same reason a contractor quotes an extension separately from a repair — not because one is more important, but because lumping them together under-scopes the bigger one and over-complicates the smaller one.
The signal that actually matters isn't how it looks
Taste is the wrong test, because taste changes and a site that looks slightly dated can still convert fine. The real signal is whether maintenance requests have started working around the design instead of improving it — a new service added as an awkward extra line in a menu that was never built to hold it, a mobile layout that needs a special-case fix every time something else changes, a template old enough that adding what the business actually sells now means fighting the structure rather than using it. That pattern, not a visual preference, is what turns a conversation from "what should we fix this month" into "this needs to be rebuilt." Our guide on update cadence covers the technical side of that clock — patches monthly, content every one to three months, a rebuild roughly every two to three years as framework support runs out — but a redesign is usually triggered earlier than that clock, by the business itself outgrowing what the site was built to do.
Frequently asked questions
How fast do visitors actually judge a website's design?
Google's own UX research team (Bargas-Avila, 2012) measured first aesthetic impressions forming in 17 to 50 milliseconds — faster than a single eye blink, and long before anyone has read a word of copy or clicked anything. A maintenance fix to broken copy or a slow page cannot change that first judgment if the layout and visual style it's attached to are the thing being judged.
What's the practical difference between a maintenance request and a redesign?
In how we scope it: a maintenance request is a bounded change to something that already exists — fix this, update that, add a section — and it moves through a care plan as a tracked ticket. A redesign changes what the site structurally is: new navigation, new templates, a new way of presenting the business. It gets scoped and quoted as its own project, not folded into a monthly plan, because the amount of decision-making and rework involved doesn't fit a ticket.
Is a slow website a maintenance problem or a redesign problem?
It depends on the cause, not the symptom. A slow page from an unoptimised image or a bloated plugin is a maintenance fix — find the one thing dragging it down and fix that thing. A slow page because the whole template is built on a stack nobody can update without breaking something else is a structural problem maintenance can only patch around, and that pattern is the actual redesign signal, not the slowness itself.
How often should a business expect to redesign, versus just maintain?
Our own guide on update cadence sets out monthly patches, content refreshes every one to three months, and a full rebuild roughly every two to three years as the framework-support clock runs out. Redesign timing follows a different, less predictable clock: it's triggered by the business changing (new offering, new audience, outgrown template) or by maintenance requests starting to look like workarounds for something the design itself can't do, not by a fixed calendar date.
Can a redesign happen gradually instead of all at once?
Sometimes, if the underlying template can actually support the change — a new homepage section or a visual refresh on existing pages can go through as maintenance. What can't happen gradually is a change to the site's structure or platform itself (new navigation model, new CMS, new way the business is presented); that always needs to be scoped as one project, because half-migrated is a worse state than either the old or new version on its own.