Methodology
We set the non-visual requirements before design, build in increments that can be reviewed in a browser rather than a document, and treat URL continuity and rendering as delivery requirements rather than launch-week tasks.
Methodology
Requirements that constrain design are agreed first: server-rendered output, performance budgets, accessible components, a content model that survives editing, and structured data.
These are far cheaper to specify than to retrofit, and retrofitting them is what makes redesigns overrun.
Design happens against real content, not placeholder text. Layouts that look balanced with invented copy routinely fail with the actual headings, and discovering that during build is expensive.
Build proceeds in increments that are reviewable in a browser. Written specifications are a poor medium for agreeing what a page should do; a working page is a good one, and it corrects assumptions while correcting them is still cheap.
Launch is planned as a monitored event. Every existing URL has a decided destination before design finishes, rendered output is compared against the old site on key templates, and indexing and structured data are verified in the first days, because the first fortnight is when a fixable problem is still cheap to fix.
We set the non-visual requirements before design, build in increments that can be reviewed in a browser rather than a document, and treat URL continuity and rendering as delivery requirements rather than launch-week tasks.
Everything above is how we say we work. Thirty minutes on a real problem is the fastest way to find out whether it is also how we behave — and it costs you nothing to check.
