Browse help articles by category
Answers to the questions people ask us about website redesigns, design systems, and the principles behind them.
34 articles
Website redesign
– What a redesign involves, what it costs, how long it takes, and how to tell whether your site needs one.
- What running the site in several languages adds to a redesignIf the second language is in the brief, multiple languages add close to nothing to the design cost and a few days of build work for language switching, URLs and locale-aware formats. If it arrives after sign-off, expect a partial redesign.
- How long should we wait after launch before judging whether the redesign worked?Wait four weeks for a first honest read and eight to twelve weeks before calling the redesign a success or a failure, with a full quarter compared against the same quarter last year for search and revenue.
- How do we write a redesign brief so the proposals we get back are comparable?Proposals come back incomparable because the brief let each studio choose the scope, so specify the six things that drive price, template count, copy, migration, CMS expectations, reuse and budget, and let studios compete on everything else.
- We supply the photography — what do we actually need, and when?You need fewer images than you have pages, you need them specified by template slot and aspect ratio before anyone shoots, and the biggest waste is a production shoot booked before the templates exist.
- What should we measure before the redesign goes live?Pick three or four numbers before design starts, record them for a clean period before launch, and accept that anything you did not baseline is an argument you will lose later.
- We have 400 pages and a redesign coming — how do we decide what to keep, merge, rewrite or delete?Give every page one of four verdicts before design starts: keep as is, merge, rewrite, or delete. Make delete the default, and sort by what a page earns you rather than what it costs to move.
- Our organic search traffic fell after the redesign — how do we find out why and what do we fix first?Almost always a URL problem, not a design or speed problem, so check the redirect map first: every old URL should land on its closest intent match, not the homepage.
- Should we rebrand at the same time as the website redesign?Rebrand first if the name, logo or positioning is genuinely changing. Otherwise refresh the brand inside the redesign and skip the separate brand project, because running both as one project is where most timelines double.
- Our redesign quote doesn't mention accessibility — what does it cost to add, and what should we refuse to pay for?Most accessibility work costs nothing extra when it is decided before the design is approved; the real money sits in custom interactive components at roughly a day each to build and test; the wasted money goes on overlay widgets and audits of a site you are about to delete.
- Should we change CMS at the same time as the redesign, or do the two separately?Do them separately, and put the CMS move second, unless the current CMS is the reason the site is broken. In that case the platform moves first and the redesign waits.
- Our copy isn't written yet — should we start the redesign anyway?Start — but only if someone on your side has a name, a deadline and time cleared for writing, because the thing that delays redesigns is almost never design, it is the copy nobody was assigned to write.
- Should we hire a design studio, a freelancer, or an in-house designer for our website redesign?Hire a freelancer if the site is under about 15 pages and won't grow; hire a studio if you need a system built once and documented; hire in-house only if that person owns the site as their main job. The deciding factor is who maintains it in month nine, not price.
Design systems
– Tokens, components and documentation, what a design system is for and when a site is big enough to need one.
- We want to add dark mode to our site. What does it actually take, and do we need it?Most marketing sites do not need dark mode. If your colours are already tokens named by role, adding it takes about a week. If they are named by shade, it is a rebuild of your colour system first.
- How much freedom should our CMS give marketers to build new pages?Less freedom than marketers ask for, more than most studios ship: pick one of four levels per page type, and agree the guardrails before the build rather than after the first ugly page.
- Our new marketing site doesn't match our product UI — does that matter?Most of the mismatch is harmless. Fix the differences in meaning first (words, button colours, primary actions), then structure, and leave the cosmetic gap alone until the product is being rebuilt anyway.
- What is a design token, and how is it different from a CSS variable?A design token names a design decision (surface-raised, text-muted); a CSS variable is just the storage slot that holds its value — so any token named after its value, like grey-100 or blue-500, is a CSS variable wearing a token's name and will break at the first rebrand.
- Do I need a design system, a style guide, or just a component library?Most sites need a component library: coded components that are the only way the site gets built. A full design system pays off only when more than one or two people change the site monthly. Standalone style guides are not worth maintaining.
UI and UX principles
– The rules behind interfaces that feel considered: hierarchy, spacing, contrast, motion and feedback.
- Our cookie banner is the first thing every visitor sees. How do we make it less damaging?Most of the damage is design and configuration, not law. The rules require a clear, free choice. They do not require a full screen blocker, a scroll lock, or a banner that asks again on every visit.
- Our site has ended up with a dozen button styles. How many do we actually need?Four: one primary, one secondary, one tertiary, and one destructive. The rule that keeps it at four is one primary button per view.
- Our site looks fine on a designer's laptop but wrong on the sales team's screens. What are we missing?Your design was validated on one screen. Four things usually break on the others: grey text tuned to a calibrated panel, full-height heroes on short laptops, hairline font weights, and colour picked in a dark room. Most are a day of token edits, not a redesign.
- Marketing keeps bolting widgets onto the site. How do we decide what stays?Judge each add-on by what it costs the visitor, not what it costs to install. Most sites carry three or four overlapping widgets and only one earns its place.
- People say our website is hard to read, but the font size is fine. What is actually wrong?Font size is rarely the cause. Reading difficulty almost always comes from line length, line spacing, contrast and paragraph rhythm, and those four are set by the layout, not the type scale.
- Our forms get abandoned halfway through. What in the interface is causing it?In most cases it is not the number of fields. It is validation that fires while someone is still typing, error messages placed away from the field, required fields that only reveal themselves on submit, and inputs that wipe what was typed when the page reloads.
- Why does our site feel cramped and awkward on mobile when desktop looks fine?Almost always because the desktop design was shrunk proportionally rather than redesigned for a small screen, and five specific causes account for nearly every case we audit.
- Everything is in our navigation, so why can't people find anything?Because people don't read a list of everything you have, they scan for words matching the job they arrived with, so most findability complaints are naming and ordering problems, not missing-link problems.
- Why did our new design look great in Figma and worse once it was built with our real content?Because the mockups were dressed with content that behaves better than yours does, and a layout that only works with ideal content is not a finished design.
Working with Glasspage
– How projects run, what we hand over, what we need from you, and what happens after launch.
- How many revision rounds should a redesign include, and what counts as one round?Two or three rounds per deliverable is standard, but a round is one consolidated set of comments from your whole team against one named deliverable, so how you collect it matters far more than how many you buy.
- After launch, do we need a retainer with the studio or can our own team maintain the site?Most teams don't need one. If your page set is stable and someone in-house can edit the CMS, default to no retainer and buy hours only when you need them.
- Which post-launch website issues are free bug fixes and which are paid changes?A bug is the site failing to do what was agreed; a paid change is the site doing what was agreed and someone now wanting something else.
- Our redesign feels like it is going badly — how do we intervene before launch?A failing redesign is usually visible by week three, and the signals are procedural rather than visual: late unpolished work, unanswered feedback, and nobody able to name the decision being made this week.
- We were told our change is out of scope — is that fair or padding?Judge the request against what the studio agreed to produce, not against how difficult it sounds: restyling inside existing components is cheap and should rarely be refused, while new page types, components or content models are genuinely new work.
- Who should have final sign-off on our website redesign?One named person should hold final sign-off — chosen before design starts, given a short written remit, with everyone else's opinion routed through them as advice rather than veto. It is rarely the CEO and never a committee.
- Our site looked great at launch and looks tired eighteen months later — what happened?Nothing broke and nobody changed the design — the pages added after launch were built by people who were never given a way to add a page correctly, so design decay is an authoring problem, not a design problem.
- How do we give design feedback that actually changes the page instead of stalling it?Feedback changes a page when it names one element, describes what you observe rather than the fix you imagine, and lands in one of three buckets: a token change (about an hour), a component variant (about a day), or a new component (about a week).