—Service
Web Design
Original interface design built around brand, user behaviour, content hierarchy, and conversion.
01Overview
We design interfaces as systems, not as a sequence of screens. Layout, typography, motion, and component behaviour are defined together against the organisation's brand and the way its users actually move through a product. The output is a coherent design language that engineering can implement without compromise.
02How we approach it
Design work starts with Discover, not with screens. We look at the organisation, its users, and the content the site actually has to carry — page by page, message by message. From that we Define the structure: hierarchy, navigation, the job each page must do, and the visual direction that fits the brand. Only when the structure holds do we start drawing interfaces. It keeps the design honest and stops decoration arriving before decisions.
The Design stage produces a system, not a set of pages. Typography, spacing, colour, and component behaviour are defined once, as tokens and rules, then applied everywhere. Every layout is tested against realistic content — long titles, missing images, awkward word counts — because a design that only works with placeholder copy has not been designed. Responsive behaviour and motion are specified alongside the layouts, not improvised later.
Because we engineer what we design, every decision is made with implementation in mind. Component specifications describe states, breakpoints, and interaction, not just how a screen looks at one width. Design tokens are shared with engineering, so the values in the build match the values in the design file. If our team builds the site, design moves straight into the Engineer stage; if yours does, the specifications are complete enough to build from without interpretation.
A design is judged in the Validate stage on how it performs, not how it presents. We check accessibility, legibility, responsive behaviour, and how the interface holds under the content the organisation will actually publish. After launch, the system is built to Evolve: new pages and sections are composed from the existing components, so the site stays coherent as it grows rather than drifting back towards the ad-hoc state it replaced.
03Suitable for
- Brands replacing a templated site
- Products needing a defined design language
- Teams preparing to scale a marketing site
04Problems solved
- Inconsistent, ad-hoc interfaces
- Designs that look acceptable but convert poorly
- Visual systems that break under real content
05Deliverables
- Interface design system
- Responsive layouts
- Component specifications
- Interaction and motion direction
06Technical considerations
- Design tokens shared with engineering
- Accessibility considered from the first layout
- Built for real content, not placeholder copy
07Common questions
How much does web design cost?
We don't publish prices, because the honest answer depends on scope. The main cost drivers are the number of distinct templates and components, the depth of the design system, interaction and motion work, and whether we are also engineering the build. Once you've told us what you need through the contact or project brief form, we set out scope, cost, and approach in a written proposal before any work begins.
Do you also build what you design?
We do. We're an engineering studio as much as a design one, and a design engagement can continue straight into the Engineer stage with the same team. That isn't a requirement, though. If your own developers or another partner are building the site, we hand over the interface design system, component specifications, and design tokens in a form they can implement directly, and we can review the build against the design as it progresses.
Do we need finished content before design starts?
No, but we do need to understand it. The Discover stage maps what the site has to say and who it has to say it to; design then works with realistic content — actual page counts, actual message lengths — rather than placeholder copy. If content is still being written, we design the system to tolerate the variation, and we'll tell you early where missing content would put decisions at risk.
How do you judge whether the new design is working?
Against the behaviour it was meant to change. During Define we agree what the site is for — enquiries, sign-ups, orders, comprehension — and the design is shaped around those paths. Once the build is live, that intent becomes measurable: conversion on the key journeys, engagement with the content, and performance against Core Web Vitals budgets. Design choices are treated as decisions to verify, not preferences to defend.
Who owns the design work when the project ends?
Ownership of deliverables, along with usage rights and any ongoing service commitments, is defined in the written engagement agreement each project signs before work starts, so there is no ambiguity to resolve later. In practical terms, the deliverables are the design system itself: source files, component specifications, and design tokens, documented so that another team could work with them if needed.
08Related
- Frontend Development
Responsive, accessible, high-performance interfaces built with modern component architecture.
- Website Rebuilds
Complete replacement of outdated, slow, unstable, or template-dependent websites.
- Performance Optimisation
Core Web Vitals, loading speed, caching, code splitting, and database efficiency.
- See it in practice: Kiln
A studio & brand site concept study from our work gallery.
Discuss a web design project.
Tell us what you need. We'll tell you how we'd build it.