Website design and UI/UX development
A website that looks good in a mockup and a website that performs are produced by different processes. The second requires the design and the engineering to be decided together, because the decisions that determine load time, layout stability and accessibility are made while the design is being drawn — not afterwards.
Where design decisions become performance problems
Four choices made in a design tool account for most of the performance damage we see, and all four are invisible until the build.
Custom fonts are the first. Every additional weight and style is another file, and a font loaded from a third-party host adds a DNS lookup, a TLS handshake and a connection on the critical path. Self-hosting and subsetting solves it. On one build a single currency glyph was pulling an 84 KB typeface that we split down to an 8.6 KB face.
Full-bleed hero imagery is the second: large, above the fold, and directly responsible for the largest contentful paint. Third is anything animated on load, which competes with first paint for main-thread time. Fourth is content that arrives after render — banners, embeds, late-loading images without reserved space — each shifting the layout under the reader's thumb.
Layout stability is a design problem with a numeric score
Cumulative layout shift measures how much the page moves while it loads. It is the metric users feel most directly — it is the reason you tap the wrong link.
It is also almost entirely preventable at design time by reserving space: explicit dimensions on images and embeds, a fixed height for anything that loads late, and no content injected above existing content. On a 3D product build we took CLS from 0.26 to 0.019 by doing exactly that.
Design systems beat page designs
A set of beautiful page comps is a liability once the site has to grow: page nine gets designed by whoever is available, and the site drifts.
A design system — type scale, spacing scale, colour tokens, component states including the empty, loading and error ones nobody draws — means the tenth page looks like the first without a designer being involved. It is more work up front and less work permanently.
This site is built that way, which is why its static content pages inherit the homepage header and footer at build time rather than re-implementing them. The chrome cannot drift, because there is only one copy of it.
Accessibility is not a compliance chore
Sufficient colour contrast, visible focus states, real semantic markup, images with alternative text, and forms whose labels are attached to their inputs. These take modest effort during the build and are expensive to retrofit.
They also overlap almost entirely with what makes a site work well on a poor connection, on an old phone, in bright sunlight, or for someone navigating by keyboard — which is to say, for a lot more people than the word "accessibility" tends to suggest.
Frequently asked
What is the difference between UI and UX design?
User interface design concerns what the product looks like and how its controls behave — layout, typography, colour, components. User experience design concerns whether a person can accomplish what they came to do: flows, information architecture, error recovery. A product can have an attractive interface and a poor experience, and this is common.
Why is my beautiful website slow?
Usually four things decided during design: multiple custom font weights loaded from a third-party host, large above-the-fold imagery, animation competing with first paint, and content injected after render that shifts the layout. All four are fixable, and all four are cheaper to avoid during design than to repair afterwards.
What is a good Core Web Vitals score?
Google's thresholds are a largest contentful paint under 2.5 seconds, interaction to next paint under 200 milliseconds, and cumulative layout shift under 0.1 — measured on mobile, which is stricter than desktop. Mobile is the number that matters, because it is where most traffic is and where the hardware is slowest.
Do you provide design as well as development?
Yes, and we prefer to do both, because the decisions that determine performance and accessibility are made while the design is being drawn. We can also build from designs you already have — we will flag anything that will be expensive at runtime before starting rather than after.
Related
Want this built?
Tell us what you are trying to ship and we will tell you honestly whether we are the right team for it.