PDFs are a bad way to serve a menu. Anyone who’s tried to read one on a phone knows the drill: pinch, zoom, scroll sideways, lose your place, zoom out, try again. It’s a UX problem we’ve been fixing for hospitality clients for years — but the more interesting problem, the one that actually matters if you get it wrong, is dietary data.

A menu isn’t just a list of dishes and prices. For a lot of customers it’s the thing they rely on to work out whether they can eat somewhere at all. Allergen and dietary information needs to be clear, current, and easy to find — and a laminated chart printed six months ago, or a PDF nobody’s updated since the menu changed, makes that much harder than it needs to be. That constraint has shaped how we build these systems far more than anything to do with layout or animation.

It’s worth saying upfront why this problem is worth solving at all, beyond the obvious duty of care. Dietary requirements are common enough that ignoring them is a commercial mistake, not just an ethical one. Coeliacs, nut allergy sufferers, vegans, vegetarians, people avoiding spice for medical or personal reasons — a filterable menu turns “can I even eat here” into a five-second answer instead of a phone call to the venue or an awkward conversation with a waiter. For the venue, that’s fewer support calls, fewer walk-outs, and clearer, more current information than a static document can offer.

Version one: a binary that wasn’t enough.

My first attempt at this was years ago, on Webflow. Every menu item had a required field for each of the fourteen major allergens: contains, or does not contain. It worked, in the sense that it produced a filterable menu. But it had two problems that only became obvious with real use.

The first was maintenance. Every single item needed an explicit yes/no for every allergen, whether or not that allergen was remotely relevant. Adding a new dish meant working through fourteen fields one at a time, even for something as simple as a black coffee. Multiply that by a menu with eighty items and a chef who wants to swap two dishes a week, and the system quietly encourages shortcuts — which is exactly what you don’t want in data customers rely on.

The second was that “contains / does not contain” is a false binary. Kitchens have shared fryers, shared prep surfaces, and dishes that can be made without an allergen if someone asks. None of that fits into two states. A dish that “may contain traces of nuts due to shared equipment” is a materially different claim from “does not contain nuts”, and collapsing them into the same answer loses information a customer might actually want.

There’s a subtler failure mode too, which only shows up once a client has been using the system for a while: a required field that’s usually “no” trains people to click through it without reading it. If ninety percent of your allergen answers for a given dish are “does not contain,” the person entering the data stops treating each field as a meaningful decision and starts treating it as a box to clear. That’s exactly the kind of drift you don’t want in information customers rely on when choosing what to order. A model that only asks about what’s relevant doesn’t have that failure mode, because there’s nothing to click through — you either add a tag or you don’t.

Version two: a proper data model.

The current version fixes both problems with a schema that only records what’s actually true, and a three-state enum instead of a binary:

• Menu items — the dishes themselves
• Dietary tags — allergens, plus vegetarian, vegan, and (for kitchens that serve spicy food) a spice flag
• A join table between the two, carrying a status enum: contains, may_contain, removable

Rather than every item needing fourteen explicit fields, you only add a row when there’s something to say. A black coffee gets no allergen rows at all. A curry gets contains: gluten, may_contain: nuts, removable: dairy if it can be made without the yoghurt on request. Adding a dish is now “tag what’s relevant,” not “answer fourteen questions” — which means it’s far more likely to actually be kept up to date by whoever’s entering the menu.

The three-state enum matters because it maps onto real decisions a customer makes when reading the menu — it’s what drives the small symbols shown against each dish, and the same values populate the allergen chart. contains gets one symbol, may_contain another, removable a third, so a customer glancing at a dish gets the nuance without having to ask.

Filtering is a separate, deliberately blunter piece of logic. When someone filters out an allergen, anything carrying that allergen in any state — contains, may_contain, or removable — is excluded. The enum informs what’s displayed; it doesn’t get consulted when deciding what to hide. That’s on purpose: a filter is a safety mechanism, and a mistake there should always fail toward hiding a dish rather than showing one that turns out to be unsuitable. The nuance is for a human reading the symbols and making their own judgement call; the filter itself doesn’t try to be clever about degrees of risk.

Take a real example: a Caesar salad. It contains gluten (croutons), contains dairy (parmesan, dressing), and may contain egg depending on how the dressing’s made. The anchovies are removable on request. On the menu, that’s three distinct symbols next to the dish, telling a customer exactly where they stand with each one. Filter for gluten-free or dairy-free, though, and it disappears from the list entirely, same as it would for someone filtering nuts if nuts were merely “may contain” — the filter doesn’t try to distinguish “definitely” from “possibly,” it just removes anything with any degree of risk. Under the old binary model, none of that nuance existed at all; every field was just yes or no, with nothing to tell the customer why a dish had been ruled out or whether asking staff might change the answer.

Vegetarian and vegan don’t need the same three-state treatment, so they’re kept simple: a boolean on the item itself rather than a row in the join table. There’s no meaningful “may be vegetarian” the way there’s a meaningful “may contain nuts” — a dish either fits the diet or it doesn’t, so a flag is enough and the extra structure would just add complexity without buying anything. The rule of thumb that fell out of this: use the tri-state enum where the real-world answer genuinely has more than two states, and don’t force it onto data that doesn’t need it.

One more change I’m currently working through: previously each food menu had its own table, which meant a dish served on both the lunch and dinner menu had to be entered twice — two places for the data to drift apart. That duplication doesn’t just cost time re-entering a dish; it means the dietary tags for “the same” dish can end up subtly different between menus if one gets updated and the other doesn’t. A kitchen fixes the dressing recipe on the lunch menu to remove egg, forgets the dinner menu has the identical dish under a different row, and now the site is telling two different stories about the same plate of food.

I’m moving to a model where menu items exist independently, menus are their own entity, and a join table links items to whichever menus they appear on. Same dish, one row, referenced wherever it’s needed. A venue with a lunch menu, dinner menu, and a set menu that shares six dishes with the other two now enters those six dishes once and links them three times, rather than maintaining three separate copies of the truth. It’s a small change on paper but it removes an entire category of “the allergen info doesn’t match between the two menus” bugs before they can happen, and it’s the kind of thing that only becomes obvious once you’ve watched real venues struggle to keep multiple menus in sync by hand.

One dataset, two legally required outputs.

In the UK, hospitality businesses are legally required to display allergen information for customers — traditionally a printed chart, often laminated, frequently out of date the moment a dish changes. Because the allergen data already exists as structured rows against the same menu items, generating that chart is close to free: it’s a different view over the same source of truth, not a separate document someone has to remember to update.

That’s the part of this I think is actually worth paying attention to, more than the filter UI itself. The interesting engineering problem isn’t “let a customer tick a box” — it’s making sure there is exactly one place the allergen data lives, so the online menu, the filtered view, and the legally required chart can never quietly disagree with each other. A PDF chart printed in January and a menu that changed in March is a compliance risk as well as a UX one. Deriving both outputs from one schema removes the drift entirely.

Making the filtering feel instant.

None of the above matters if the filtering itself feels sluggish, so the client-side side of this is built to be fast:

• Menu content is cached in Cloudflare KV, so it’s served to the client quickly rather than round-tripping to Postgres on every page load.
• Menu items render in a keyed {#each} block, and filtering is done client-side with Svelte 5 runes — toggling a dietary requirement re-evaluates the list without a network request.
• Because venues often have more than one menu (food, drinks, brunch), the customer’s selected dietary preferences are held in shared state and persist as they move between menu pages, rather than resetting every time.

The combination means a customer can tick “vegetarian, no nuts” once and have it apply everywhere on the site, with the list updating instantly as they adjust it. The filtering itself is a $derived.by that builds a map of active allergen filters from state, then checks each menu item against it:

const filteredMenu = $derived.by(() => {
	const filters = {
		gluten: dietary.glutenFree,
		dairy: dietary.dairyFree,
		nuts: dietary.nutFree,
		// ...remaining allergens
	};

	function filterMenuItems(items: FoodMenuItemWithAllergens[]) {
		return items.filter((item) => {
			for (const [key, value] of Object.entries(filters)) {
				if (
					value === true &&
					item.food_menu_allergens.some((allergen) => allergen.allergens.name === key)
				)
					return false;
			}
			return true;
		});
	}

	if (dietary.vegan) return filterMenuItems(veganItems);
	if (dietary.vegetarian) return filterMenuItems(vegetarianItems);
	return filterMenuItems(menu);
});

Vegan and vegetarian are checked first against their own boolean-filtered lists, then the allergen filters run on top — keeping the two concerns separate rather than folding everything into one combined condition.

What I’d still improve.

I don’t think this is finished. A few things I’m actively thinking about:

• The filtering logic above checks whether an allergen row exists at all, not what its status is — so a removable allergen currently excludes an item from a filtered view in exactly the same way a contains one would. A dish where nuts can be left out on request should probably still show up for someone filtering nuts out, with a note that it needs a modification. That’s the next thing to fix, and it’s a good example of the schema already being ahead of the UI that reads from it.
• Surfacing may_contain more clearly in the UI than a small icon — it’s the state most likely to be misread at a glance.
• Making the menu/item split above easier to migrate existing clients onto without re-entering their data by hand.

The unglamorous parts of this — the schema, the enum, the single source of truth — matter a lot more than the filter buttons on the page. The UI is the easy bit once the data underneath it is structured properly.

Every studio reaches a point where the tools that got you started stop being the tools that get you where you’re going. For us, that moment arrived with Webflow.

We loved Webflow, and in a lot of ways we still do — it’s a phenomenal way to move fast on marketing sites and get a client’s vision live without a six-week build. But as our clients’ ambitions grew, so did the demands we were placing on it. We started bolting on custom data layers here, mounting interactive components there, wiring up bits of JavaScript to make a visual design tool behave like an application. Each individual patch was fine. Taken together, they were a sign. We weren’t building websites anymore — we were building products, and we were building them on top of a tool that was never designed for that job.

So we went looking for a real foundation: a full-stack framework we could commit to as our default, one that could handle everything from a simple marketing page to a data-heavy client dashboard without switching tools halfway through. That search led us to SvelteKit, and a couple of years and dozens of projects later, it’s not an exaggeration to say it’s changed how we work.

The evaluation.

When we compared frameworks, we didn’t go in with a favourite. We looked at the major options the way we’d look at any tool we were about to build a business on: performance, developer experience, the size and readability of the resulting codebase, and how quickly a new team member could get productive in it.

Svelte kept winning on all four.

The core of it comes down to how Svelte works under the hood. Most JavaScript frameworks ship a runtime to the browser — a chunk of library code whose job is to compare your application’s state against the DOM and figure out what changed, every time something updates. That’s the “virtual DOM” model, and it works, but it’s overhead: code the browser has to download, parse, and run before your app even starts doing its job.

Svelte takes a different approach. It’s a compiler. It does that comparison work at build time, not in the browser, and outputs small, surgical JavaScript that updates exactly the parts of the DOM that need to change. There’s no framework runtime shipped to the client — just your code, distilled. The practical result is smaller bundles, faster first loads, and less work happening on every device your site touches, including the underpowered ones.

We felt that difference immediately, not as an abstract number but as a feeling: pages that snapped instead of settling.

Why SvelteKit specifically.

Svelte is the language. SvelteKit is what makes it a serious platform for client work. It’s the layer that gave us everything Webflow-plus-patches never quite could:

• File-based routing that maps cleanly onto how we think about a site’s structure, with no separate routing library to configure and maintain.
• Server-side rendering and static generation, chosen per-route, so a marketing page can be pre-rendered to the edge while a logged-in dashboard renders fresh on every request — in the same project, without contorting either use case to fit the other.
• Load functions and form actions that give us a clean, built-in way to move data between server and client, instead of the improvised glue code that pattern usually demands.
• A genuinely full-stack story. We can write API endpoints, handle authentication, and manage server logic in the same project as the front end, which means fewer moving parts, fewer repos, and fewer places for something to quietly break.

For us, that last point mattered more than any benchmark. Complexity is a cost every client eventually pays for, whether it’s in their invoice or in how long it takes us to safely make a change six months later. SvelteKit let us collapse a stack that used to be four or five tools into one coherent framework.

Pragmatic, not dogmatic.

We want to be upfront about something: we chose Svelte for the front end, but we didn’t marry ourselves to one way of doing everything. For backend services we reach for Hono when we want something fast and minimal, and every so often a project calls for Go — usually when raw performance or concurrency is the whole point. We pick tools for the job in front of us. It just happens that, for the front end, Svelte is the tool that keeps being the right answer.

We should also be honest about the trade-offs, because a framework choice without any downsides isn’t a real evaluation, it’s marketing copy. There’s a common assumption that Svelte’s ecosystem is small compared to React’s — the industry default, and for good reason, given its head start and adoption. In practice that gap is smaller than it looks. Svelte components aren’t a new language bolted onto JavaScript; they’re HTML, CSS, and the JS or TS you already know, extended with a small set of template syntax for things like conditionals and loops. Because of that, Svelte doesn’t need a Svelte-specific version of every package the way some frameworks do — it can use the vanilla JavaScript ecosystem directly. Svelte-native packages tend to be more reactive out of the box, but they’re an enhancement, not a requirement. The result is an ecosystem that’s larger, and more mature, than the “Svelte-only” package count would suggest.

Where the trade-off is real is around the wider talent pool: more developers currently know React, simply because it’s been the default for longer, and some clients — particularly larger organisations with an established stack — come to us already expecting it. That’s a conversation worth having openly rather than glossing over. But it’s less of a constraint than it sounds. Svelte’s learning curve is shallow enough that a developer who knows JavaScript tends to be productive in it within days, not months, because there’s less framework-specific ceremony to learn in the first place. That matters whether you’re a small studio pulling in a freelancer for a sprint, or a larger team bringing someone on permanently — either way, the ramp-up cost is genuinely low.

What this means for our clients.

Framework choice can feel like an internal, technical decision — the kind of thing that shouldn’t matter to anyone outside the engineering team. In practice, it shows up everywhere a client can measure:

Faster load times feed directly into Core Web Vitals, which feed into search ranking and, more importantly, into whether a visitor sticks around long enough to convert. A smaller, more coherent codebase means we can build features faster and with more confidence, which shows up as shorter timelines and fewer surprises in maintenance further down the line. And because the same framework can handle a static marketing page and a dynamic client application, we’re not asking clients to pay for a rebuild the moment their site needs to do more than sit still.

SEO in particular is one of the reasons SSR is our default rather than an occasional option. Most of our projects render server-side, with static generation used where content doesn’t need to change per request. Even client dashboards, which people often assume have to be client-rendered, we serve server-side using cookie-based auth — so an authenticated page still arrives from the server rather than being assembled after the fact in the browser. Anything that matters for search — the content a crawler actually needs to index a page properly — is delivered directly in the HTML response, not fetched in afterward. We’ll occasionally stream in secondary, below-the-fold content that isn’t critical to SEO or first impression, but that’s a deliberate choice for perceived performance, never a way of hiding content search engines need to see. It’s a small distinction, but it’s the difference between a site that merely looks fast and one that’s actually built to be found.

None of that is about chasing a trend. It’s about choosing infrastructure that keeps pace with a client’s ambition instead of quietly limiting it, the way Webflow eventually did for us.

Where we’re headed.

We’re already heavily using Svelte 5, and have migrated all projects originally built on Svelte 4, and its new runes-based reactivity model has continued the pattern we noticed from the start: less code to express the same idea, and a mental model that gets out of the way rather than sitting in front of it.

We didn’t set out to become a “Svelte studio.” We set out to build fast, maintainable products for our clients, and Svelte and SvelteKit turned out to be the clearest way to do that. That’s really the whole case — not that it’s fashionable, but that it keeps making the actual work easier and the actual outcomes better. So far, it hasn’t stopped.

If you’ve read anything about Schema.org, you’ve read the standard pitch: add structured data, get rich results in Google, maybe a nice star rating or a recipe card. That’s true, but it’s a narrow way to think about what structured data is for. The deeper value isn’t the visual reward in a search results page — it’s that you’re handing machines, AI search agents, and LLM crawlers an explicit, unambiguous description of your content instead of leaving them to guess.

Think about what a crawler sees when it hits a typical webpage: a tree of <div>s and <span>s, styled and positioned for humans, with no inherent meaning attached to any of it. A number next to some text might be a price. It might be a quantity, a rating, a year, an ID. The crawler has to infer structure from layout and hope its heuristics hold up. Schema.org lets you skip the guessing entirely. You’re not describing how something looks — you’re stating what it is.

The menu problem.

A food menu is a great example because it’s genuinely hard to parse without help. If it’s a PDF, you’re relying on OCR and layout heuristics, which is fragile at best. If it’s HTML, you’ve usually got a repeating pattern of divs: name, description, price, maybe a category heading somewhere above them. Nothing in the markup says “this price belongs to this item”, or “this item belongs to this section of the menu”. A machine has to reconstruct that relationship from proximity and formatting conventions that could easily change.

Mark it up with Schema.org’s Menu, MenuSection, MenuItem, and Offer types, and that ambiguity disappears. You’re explicitly saying: this is a menu section called “Starters”, it contains these menu items, each item has a name, a description, and an offer with a price and currency. Nothing is left for the crawler to infer. That’s the whole point — not decoration, but disambiguation.

Rich snippets are the visible tip, not the whole iceberg.

Google is explicit that only certain schema types are eligible for rich results, and that list is a small subset of the full Schema.org vocabulary. It’s easy to read that and conclude the rest isn’t worth doing. I think that’s the wrong conclusion. Search engines and AI crawlers alike are still ingesting and processing structured data even when there’s no visual payoff in the SERP — it feeds entity understanding, disambiguation, and increasingly the kind of retrieval that underpins AI-generated answers, even when there’s no snippet to show for it.

This matters even more as more traffic comes from tools that summarize or answer rather than list links. Those tools benefit from unambiguous entity data just as much as traditional crawlers do — arguably more, since they’re synthesizing an answer rather than just ranking a page. sameAs properties linking your entities to Wikidata or Wikipedia aren’t just a Knowledge Graph nicety; they’re a strong disambiguation signal for any system, human-built or AI-built, trying to work out which “Springfield” or which “Jordan” you mean.

JSON-LD isn’t always the right answer.

Google’s own documentation recommends JSON-LD as the preferred format, and for a lot of use cases that’s fair advice. But I think it gets applied too broadly. JSON-LD lives in a <script> tag, separate from the content it describes. For sitewide, contextual information — your WebSite, your Organization, your LocalBusiness — that separation is fine, even useful, because you’re describing things that exist independently of any single piece of visible content.

The problem shows up when you use JSON-LD for on-page content that already exists in the DOM. A menu, a blog post, an event listing, a product — the content is already there, visibly rendered. Duplicating it into a JSON-LD block means you’re now maintaining two representations of the same information. Someone edits the visible price on the menu page and forgets the JSON-LD block sitting in the <head>, and now your structured data is silently wrong. It also means shipping the same content twice in the page payload, which isn’t a big deal for a small site but adds up.

Microdata avoids this by attaching structured data directly to the content that’s already there — an itemprop="price" attribute doesn’t add a new price, it labels the existing one. There’s a single source of truth. Change the visible content and the structured data updates itself, because it is the structured data. For content that’s inherently page-specific — a menu, an event, a blog post, a recipe, a product page — that property alignment matters more than the tooling convenience JSON-LD offers.

There’s a genuine counterargument worth naming here, because it’s the reason Google leans towards JSON-LD in the first place: it’s much easier to inject via a tag manager without touching page templates. In large organisations where marketing controls GTM but doesn’t have commit access to the front end, that’s a decisive advantage, and JSON-LD wins on pragmatic grounds regardless of the duplication issue. If you own your templates directly, though, that advantage disappears, and Microdata’s tighter coupling to content starts to look like the better trade, and personally I think developers should be including this by default from the get-go.

One underused Microdata feature worth knowing about is itemref. Normally an item’s properties have to be DOM descendants of the element with itemscope, which doesn’t always match your markup structure — maybe your price sits in a different column, structurally unrelated to the item name. itemref lets you associate properties with a scope by ID reference instead of DOM nesting, which solves a lot of the “my structure doesn’t match Schema’s expectations” complaints people have about Microdata.

Where I land: mix them deliberately.

My rule of thumb is simple: JSON-LD for things that describe the site or organisation in general — WebSite, Organization, LocalBusiness, BreadcrumbList — and Microdata for things that describe specific, already-rendered on-page content — menus, events, blog posts, recipes, products.

The genuinely satisfying part is that you don’t have to choose one exclusively. You can link the two together. A JSON-LD LocalBusiness block can reference a Microdata-marked-up menu on the page using @id, and the Microdata item can point back using itemid, referencing the same identifier. Nest a Review inside a MenuItem. Reference an Organization from within an Event. The connections between entities are as valuable as the entities themselves — you’re not just saying “here’s a menu” and “here’s a restaurant”, you’re saying “here’s a menu, and it belongs to this specific restaurant, which is this specific entity, which has these reviews”. That web of explicit relationships is where structured data goes from useful to genuinely powerful.

<!-- JSON-LD in <head> -->
<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Restaurant",
    "@id": "https://fernlondon.co.uk/#restaurant",
    "name": "Fern",
    "hasMenu": {
      "@type": "Menu",
      "@id": "https://fernlondon.co.uk/menu/#menu"
    }
  }
</script>

<!-- Microdata in <body> linked via itemid -->
<main 
  itemscope 
  itemtype="https://schema.org/Menu" 
  itemid="https://fernlondon.co.uk/menu/#menu"
>
  <section itemscope itemtype="https://schema.org/MenuSection">
    <h2 itemprop="name">Starters</h2>
    <div itemscope itemtype="https://schema.org/MenuItem">
      <span itemprop="name">Charred Sourdough</span>
      <div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
        <span itemprop="price">6.50</span>
        <meta itemprop="priceCurrency" content="GBP" />
      </div>
    </div>
  </section>
</main>

A practical note if you’re doing this properly: @id values need to be unique across the page, and if you’re nesting scopes with Microdata, watch for itemid collisions across different levels of nesting — it’s an easy mistake to make and a difficult one to debug.

If you want to see this in action rather than just read about it, this very article is nested with structured data too — run it through Schema.org’s Validator and you’ll see the nesting described above reflected in the scan.

The takeaway.

Structured data isn’t a checkbox for rich snippets — it’s an opportunity to make your content legible to machines without ambiguity. Treat JSON-LD and Microdata as tools with different strengths rather than a single “best practice” to follow uniformly, and use nesting and @id/itemid references to make the relationships between your content as explicit as the content itself. That’s the part most structured data advice skips entirely, and it’s the part that actually makes a difference.

Every so often a piece of engineering work quietly becomes load-bearing for the whole industry, and accessibility is having exactly that moment. It's not new — WCAG has existed in some form since 1999 — but the conversation around it has changed. What used to be treated as a nice-to-have, tackled if there was time left at the end of a sprint, is increasingly treated as a baseline requirement, in the same category as "the site should work on mobile" or "the checkout should not lose people's baskets."

We wanted to write about why, what the practical risks are, and — more usefully — what we actually watch for when we're building.

The people first, the law second.

It's tempting to lead with legal risk because it's the thing that gets budget approved. But it's worth being honest that the actual reason to care comes first: a meaningful number of the people visiting any website have some kind of access need, whether permanent, temporary, or situational.

That covers a lot more ground than people sometimes assume. Screen reader users navigating by heading structure rather than visual layout. People with motor impairments who can't use a mouse and rely entirely on a keyboard or switch device. Users with low vision who rely on zoom, high contrast, or reflow. People with cognitive or attention differences who need consistent navigation and plain language. And then there's the situational and temporary end of the spectrum — a broken arm, a screen in bright sunlight, a crying toddler making full concentration impossible, a slow connection dropping images. Accessible design tends to make things better for all of these groups simultaneously, which is part of why it's such good value as an investment: you're rarely building for a narrow edge case, you're building for resilience.

The legal landscape is genuinely shifting.

That said — the legal picture matters too, and it's worth understanding in outline, even if you're not a lawyer (we're not either, and this isn't legal advice).

Several territories are actively legislating or tightening enforcement of digital accessibility requirements at the moment. The EU has had accessibility legislation in force for a while now, but the compliance deadline landed in mid-2025, and the year since has been the first real period of active enforcement — audits, information requests, and regulatory scrutiny rather than a distant future obligation. It applies broadly, and notably it isn't limited to companies based in the EU: it extends to any business selling goods or services to EU consumers, regardless of where they're headquartered, which catches a lot of UK studios and their clients by surprise.

The UK has its own long-standing framework, primarily through equality legislation that has been interpreted to extend to websites and digital services, alongside specific accessibility regulations for the public sector.

It's not only Europe, either. In the US, there's no single federal law written specifically for website accessibility, but a steady stream of lawsuits under existing disability rights legislation has made accessibility a live legal risk for years, with case numbers still climbing rather than settling down. It's a different enforcement mechanism to the EU's — driven by litigation rather than a specific digital regulation — but the practical effect for anyone building a website used by the public is much the same.

We're deliberately not going to go deep into specific clauses, case law, or how each jurisdiction differs — partly because it moves fast enough that a blog post is the wrong place to keep it current, and partly because we're developers, not solicitors. If you want the detail, the European Commission's own page on the European Accessibility Act and the UK government's guidance on accessibility requirements are both good starting points, and we'd always recommend proper legal advice if you need to know exactly where you stand. What's useful to take away at a glance is simply this: this is an active, moving area of law in multiple territories our clients trade in, not a settled one, and "we'll deal with it eventually" is a riskier position than it used to be.

What we actually watch for on projects.

This is where we spend most of our time, and it's more interesting than the law anyway. A non-exhaustive list of things that come up again and again:

Semantic HTML gets stripped out by good intentions.

Modern component-driven frontend work makes it very easy to build everything out of divs and spans with click handlers bolted on, because the framework doesn't stop you. The result looks fine and works terribly for anyone not using a mouse. Buttons should be <button>. Links should be <a>. Headings should be structured in order, not chosen for font size.

Focus states disappear in the name of aesthetics.

A CSS reset or a "clean up the outline" pass removes outline:none somewhere and nobody puts a visible focus style back. If you can't see where keyboard focus is, keyboard navigation is functionally broken, even though nothing "crashed."

Modals and overlays trap or lose focus incorrectly.

A well-behaved modal moves focus into itself, keeps it there while open (a "focus trap"), and returns it to a sensible place on close. Getting this wrong is one of the most common failures we see, and one of the easiest to miss in testing if you're only using a mouse.

Contrast fails on brand colours.

Brand palettes are often chosen for print, marketing, and vibe, not necessarily for contrast ratios against body text or interactive states. It's a conversation worth having early with clients and their brand teams — usually a small adjustment fixes it without compromising the identity.

Forms don't announce errors properly.

Visually, a red border and a message above or below the field might be perfectly clear. To a screen reader user, if that error isn't programmatically associated with the field and announced when it appears, it may as well not exist.

Motion and autoplay ignore reduced-motion preferences.

Parallax, autoplaying video, and animated transitions can range from mildly annoying to actively harmful for people with vestibular disorders. Respecting prefers-reduced-motion costs very little and matters more than it looks like it should.

Where headless and JAMstack builds specifically catch people out.

Given a lot of our own work is headless commerce and custom-built frontends, it's worth calling out the failure modes that are specific to that architecture, because they're easy to miss if your accessibility knowledge comes from more traditional server-rendered sites.

Client-side routing is the big one: when a page "changes" without a full browser navigation, screen readers don't automatically announce the new page title or move focus anywhere sensible, unless you build that behaviour in deliberately. Dynamically injected content — a cart drawer appearing, search results updating live — needs ARIA live regions or equivalent handling, or it simply goes unnoticed by assistive technology. Rich text coming out of a CMS is only as accessible as the markup the content team produced, which means editorial tooling and training matter as much as code. And third-party embeds — payment widgets, chat tools, booking systems — can undo all of your own careful work, because you don't control their code; it's worth accessibility-testing anything you bolt on, not just what you built.

Building it in, not bolting it on.

The common thread across all of this is that accessibility works best as a property of process, not a task on a punch list at the end. Design tokens with contrast built in from the start. Component libraries tested with a keyboard and a screen reader before they're approved, not after launch. Automated tooling like axe or Lighthouse as a first pass — genuinely useful for catching a meaningful chunk of common issues quickly — combined with manual testing for the things automation structurally can't catch, like whether the experience actually makes sense.

None of this is exotic. It's the same discipline as testing across browsers or checking a site works on a slow connection: something that's cheap when it's part of the process from day one, and expensive to retrofit once launched.

At studio:sc®, we build bespoke websites, web applications, and headless commerce solutions for clients who expect two things that are often in tension: rock-solid data integrity, and load times that feel instant no matter where in the world someone opens the page. Over the last year, we've settled on an architectural pattern that gives us both — and I want to walk through how it works, why we built it this way, and what we learned along the way.

A single-region database and a global audience.

Our stack varies by project, but there's a strong default we reach for: SvelteKit as the framework, Supabase for database and auth, and Cloudflare's edge network for hosting, with R2 for object storage. Supabase's Postgres instance lives in a single AWS region — in our case, eu-west-2. That's fine for a UK-based audience, but the moment you have users in Singapore, São Paulo, or Sydney, every database query is making a genuinely long round trip. For transactional, personal, or write-heavy data, that's an acceptable cost. For public, read-heavy content — blog posts, event listings, marketing copy — it's an unnecessary tax on every page load.

The naive fix is “just add a CDN cache in front of the API”, but that only gets you part of the way. You still need a strategy for freshness, invalidation, and what happens when the cache is empty or stale. So we built something more deliberate.

Postgres as truth, KV as the fast path.

The rule we apply is simple to state: Postgres is always the source of truth. Cloudflare KV is a read-optimized, globally distributed cache in front of it.

When a site admin makes a change on their admin dashboard — publishing a blog post, updating an event, editing a page of copy — that write goes to Postgres as normal. Postgres then fires a webhook to an API endpoint we control, which takes the updated record and writes it into KV. From that point on, edge requests for that content are served directly from KV, at the edge, typically in single-digit milliseconds, with no trip back to eu-west-2 at all.

Crucially, the application never trusts KV blindly. Every load function that reads from KV has a fallback: if the KV key is missing or the read fails, it falls back to querying Postgres directly, and — depending on the content type — will repopulate KV with the result. This means a KV outage or a cold key never results in a broken page; it just results in a slightly slower one, exactly once, until the cache is warm again.

Handling time-sensitive content differently.

Static content like a blog post is straightforward: it changes rarely, and when it does, the webhook keeps KV in sync almost immediately. Event listings needed a different approach, because “upcoming events” isn't really a property of any single record — it's a query result that changes simply with the passage of time, even if nothing in the database has been edited.

For this, individual event records are upserted into KV permanently and kept fresh via the webhook, exactly like blog posts — they have no TTL, because an event's own details don't go stale with time in the way a listing does. When an event is added or updated, that same webhook also invalidates the current cached listing, so the next request for the listings page is guaranteed to rebuild against the latest set of events rather than serve something we already know is out of date.

The listing itself — the computed set of “which events are upcoming right now” — is the one place we do apply a TTL, because it needs to expire on its own even when nothing has changed in the database. An event that started yesterday shouldn't still be showing up in a “what's on” list today, and no webhook fires just because time has passed. So the listing expires hourly; when a user hits the page and the cached list has expired, the load function fetches a fresh set from Postgres, serves it immediately, and repopulates KV in the background for the next visitor. Blog posts and their listings, by contrast, don't expire on a timer at all — they only change when someone publishes or edits something, so invalidation-on-write is sufficient and there's no need for a TTL. This is a variant of the stale-while-revalidate pattern: nobody waits on a slow recomputation, but the cache never drifts far from reality either.

Drawing the line between KV and Postgres.

The rule of thumb we apply is deliberately simple: KV is for public, static data — blog posts, case studies, event listings. Anything that needs complex querying, or is personalised to a specific user, stays in Postgres. KV is a key-value store, not a database; it has no concept of joins, filters, or relationships. The moment content needs to be queried in a non-trivial way, or is tied to an individual user's account, it doesn't belong in the cache layer at all — it belongs in Postgres, queried directly.

We did briefly consider Durable Objects, which are a better fit when you need strong consistency or coordination between requests — think collaborative editing or rate limiting — but they're a heavier tool than a read-heavy, mostly-static content problem calls for. In practice, KV's simplicity is exactly what we wanted: reads typically come back in around 20ms or less, it's trivial to keep in sync with a single webhook, and it doesn't ask us to reason about coordination at all.

The trade-off we accept: eventual consistency.

Nothing here is free. KV is eventually consistent — a write in one region can take up to around 60 seconds to propagate globally. In practice, that's a non-issue for the content we're putting through this pipeline. None of it is mission-critical or time-sensitive at the second-by-second level; nobody is going to notice or care if a newly published blog post takes up to a minute to appear for a visitor on the other side of the world. The pattern only works if you're honest with yourself about which data can tolerate that lag and which can't. Personal data, checkout flows, and anything transactional stays firmly on the direct-to-Postgres path, where consistency actually matters.

Keeping the webhook honest.

Because the webhook endpoint can write directly into our edge cache, it's a meaningful attack surface if left unguarded. We require a bearer token on every request — a long, securely generated secret that only Postgres knows — and reject anything that doesn't present it. Beyond that, the endpoint does nothing except validate, transform, and write; there's no arbitrary logic and minimal surface area for something to go wrong. If the webhook delivery fails for any reason, the fallback-to-Postgres behaviour in the read path means the site keeps serving correct data; it's just temporarily slower for that one piece of content until the next write or a manual re-sync.

I'll admit failure handling is the part of this system we'd most like to harden further. Right now there's no automatic retry or reconciliation job if a webhook delivery genuinely fails — the read-path fallback covers us, but it's a passive safety net rather than an active one. In over a year of running this in production, we haven't had a failure yet, but “hasn't happened” isn't the same as “can't happen”, and it's the next thing on my list to properly solve. I'll follow up on this piece once it's built.

What this has bought us.

In practice, this pattern has meant fast, consistent page loads across the projects where we've implemented it, while keeping a single, well-understood source of truth for every write. Reads from KV typically come back in around 20ms, regardless of where in the world the request originates — a meaningful improvement over a round trip to a single-region Postgres instance, even if I don't have hard numbers on that specific comparison across every global region we serve.

It's also had a real, measurable effect on cost. KV's free tier includes 100,000 reads a day; the paid Workers plan includes 10 million reads before usage-based pricing kicks in at 50¢ per million. Because only a fraction of requests — personal data, admin actions, cache misses — ever reach Postgres directly, we've meaningfully reduced connection load and query volume against Supabase. For projects with real global traffic, that's not a trivial saving.

More than anything, it's a reminder that “cache invalidation is hard” doesn't have to mean “avoid caching”. It means being deliberate about what you cache, how long you trust it, and what happens the moment it's wrong. Postgres tells the truth. KV tells it fast. And the fallback path makes sure our users never have to choose between the two.

When Ungarnished came to Studio Smith-Cordell, the brief was straightforward on paper: build a headless Shopify store to sell Angelos Bafas’s cocktail book, some merchandise, and future publications. Angelos — known to his following as Mr Ungarnished — has built a reputation as one of London’s most respected bartenders, and the studio wanted a store that matched the quality of everything else they do. Nothing about the store should feel like an afterthought bolted onto a beautiful site.

What started as “build a fast Shopify front end” turned into a genuinely interesting engineering problem, mostly centred on one component: the cart. We’ve used enough e-commerce sites to know exactly where they tend to fall apart, and we wanted to fix as many of those problems as we could within this project.

The core problem: most carts live on a server, and it shows.

The standard pattern for e-commerce carts is to treat the server as the single source of truth. You click a button, a request goes out, you wait, and eventually the UI updates to reflect what actually happened. Most of the time this is fine. But the seams show constantly: a laggy click-to-quantity-change, a spinner that appears for a fraction of a second too long, a cart that silently fails to update and leaves you wondering if you actually added anything.

None of that is really Shopify’s fault — it’s a consequence of treating the network as the thing your UI waits on, rather than something your UI works alongside. So for Ungarnished’s store, we flipped the model.

Local-first state, synced in the background.

The site is built using SvelteKit and hosted on Cloudflare’s edge network, so the shell of the site is about as fast as it can be. But speed at the network layer doesn’t help if the cart itself still waits on a round trip to Shopify for every interaction.

Instead, the cart’s state lives in three places, in this order of precedence:

1. Application state — the actual source of truth while you’re on the page, held in a class in a .svelte.ts file. Using Svelte 5’s runes inside the class means every property is reactive via $state(), so updating a value on the class ripples through the whole UI immediately — no separate store wiring, no manual subscriptions.
2. Browser local storage — a persistent copy, so refreshing the page or closing the tab doesn’t lose your cart.
3. Shopify’s servers — synced via their API, which is what ultimately processes the order.

The class itself only handles cart state — quantities, line items, totals, and the logic for what should happen when. All the actual Shopify request functions live in a separate file. That separation kept state and side effects from tangling together, and meant the request layer could evolve without touching any of the reactive logic sitting on top of it.

When you add something to the cart, the UI updates immediately from application state. The write to local storage and the sync call to Shopify both happen in the background, without the user needing to wait for either. This is what’s usually called an optimistic update: assume the action will succeed, show the result straight away, and only correct course if it turns out you were wrong.

That correction matters, because sometimes you are wrong. A product might sell out in the moments between a page loading and someone clicking “add to cart”. Someone might bump a line item’s quantity above what’s actually in stock. In both cases, the optimistic change rolls back once the sync with Shopify completes and reveals the real state of inventory — the user sees an accurate cart again, with a moment’s warning rather than silence or a confusing checkout error later.

The same principle applies when someone closes the tab entirely and comes back later. On return, the cart loads instantly from local storage — so there’s no blank flash or spinner while it figures out what you had — and then quietly validates that cart session against Shopify’s servers in the background. If the session has expired, or stock has changed in the meantime, the local copy gets corrected. You get the speed of a cached cart without the risk of it going stale and silently showing you something that’s no longer true.

Debouncing the quantity buttons.

One detail I’ll happily call out as a personal pet peeve: quantity steppers in carts that can’t keep up with you. You click “+” a few times quickly, and either it visibly lags a step behind, or — worse — a race condition between overlapping requests leaves the quantity wrong entirely.

The fix is a short debounce on the sync to Shopify. Every click updates the local application state instantly, so the number on screen changes exactly as fast as you click it. The actual API call to update the quantity on Shopify’s side waits for a brief pause in activity before firing, batching up rapid clicks into a single request rather than firing one for every click. The result is a stepper that feels instantaneous and never falls out of sync with itself, no matter how fast you click.

A cart that knows what free delivery costs.

Ungarnished ships to many countries, but in the UK, free delivery kicks in above a certain spend. Rather than leaving that as a line of text buried in the cart or, worse, a surprise at checkout, the cart shows a sliding progress indicator: how much further you need to spend to unlock free UK delivery, updating live as you add or remove items. It’s a small nudge, but it’s an honest one — it tells you something useful about your own order rather than trying to manipulate you into spending more, and it only appears for users actually browsing from the UK, where it’s relevant.

Fixing the multi-tab problem.

Here’s a scenario anyone who shops online has lived through: you’ve got a product open in one tab and a comparable one in another, so you can weigh them up side by side. You add one to the cart. You flick back to the other tab, and it has no idea anything happened — no updated total, no indication the cart changed at all, possibly not even after a refresh depending on how the site’s caching behaves.

Because the cart’s canonical state during a session lives in local storage, this turned out to be solvable with the browser’s own storage event. Every open tab attaches a listener — using Svelte’s on function from svelte/events rather than the raw DOM API, which keeps it consistent with the rest of the codebase and gets cleaned up automatically. When one tab writes a change to local storage, every other tab picks it up straight away and updates its own view of the cart to match — no server request needed to reconcile it. Add something in one tab, and the running total updates in every other tab you’ve got open on the same site, in real time.

The cart drawer component, and the accessibility details that don’t get skipped.

The cart itself is a drawer that slides in from the right-hand side of the screen. On larger screens it’s a fixed-width panel — capped at a max-width of around 480px, user font size dependent. On mobile, it expands to fill the entire viewport instead, since a narrow drawer on a small screen is just fiddly to use and reads as an afterthought. It opens automatically when you add an item, both as confirmation that the action worked and as a gentle nudge toward checking out — but it’s never a trap. You can close it by clicking anywhere outside it, by pressing the top-right X, by hitting Escape, or by clearing every item from the cart.

On mobile, closing the cart needed its own thought. A swipe-back gesture on a phone’s browser normally means "go back a page," which is the last thing you want to trigger when someone’s just trying to dismiss a drawer. The cart’s open and closed state is tied into the page’s history stack: opening the cart pushes a new history entry, and closing it pops that entry back off. That means a swipe-back gesture closes the cart rather than navigating away from the page entirely, matching what people actually expect from the gesture without any of the side effects.

Every interactive element in the cart has proper aria labelling, so it holds up under a screen reader as well as it does visually. And for anyone with prefers-reduced-motion set at the OS level, the drawer’s animations are switched off entirely rather than just toned down — the cart still opens and closes exactly the same, just without the sliding motion for people who’ve asked not to see it.

Why bother with any of this?

Realistically, none of this was strictly necessary to sell some cocktail books and merch. A conventional Shopify cart would have worked. But “would have worked” is a low bar, and it’s rarely the reason people remember a piece of digital work. The gap between a store that functions and one that feels considered is almost always in details like these — the ones a customer might never consciously notice, but that add up to a site that feels quick, honest, and looked-after rather than merely adequate.

That’s the standard we try to hold headless commerce builds to, and it’s exactly the kind of project — a premium brand, backed by someone genuinely respected in their field, that cares as much about craft as we do — that makes this kind of engineering worth doing properly.

Most websites lie to your screen a little. Not maliciously — just by default. Almost every image on the web is encoded in sRGB, a colour space designed in 1996 for CRT monitors. It was a sensible standard at the time, and it’s still a perfectly reasonable one for most sites. But it covers a noticeably smaller slice of colour than modern displays can actually produce.

Since around 2015, Apple has shipped Display P3 panels across iPhones, iPads and Macs, and P3-capable screens are increasingly common elsewhere too. P3 covers roughly 25% more visible colour than sRGB, mostly in the reds and greens — exactly the range that makes a slice of blood orange or a sprig of basil look alive rather than flat. If your image pipeline flattens everything to sRGB before it ever reaches the browser, none of that headroom gets used, no matter how good the display is.

For most projects, that’s a fine trade-off. Nobody’s cocktail order hinges on it. But Cato isn’t most projects.

Why this client, why this detail?

Cato is a high-end cocktail bar built almost entirely around colour. Their brand photography is vivid, close-up cross-sections of ingredients — the kind of shots where colour is the subject, not a supporting detail. Their current menu, Colour Has Flavour, is a synesthesia-inspired concept where the drinks are organised and described by colour and the sensations it evokes. If there was ever a brief where “the site should render the truest colour possible” was a legitimate technical requirement rather than an indulgence, this was it.

So we built something most sites don’t need: an image pipeline that unlocks the full P3 gamut on displays that support it, while still serving perfectly correct sRGB to everything else.

Getting P3 in at the source.

Colour management is only as good as its weakest link, and the weakest link is usually right at the start. It doesn’t matter how carefully you handle colour in code if the source image was already clipped to sRGB during export. So before writing a line of the pipeline, we spoke with Cato’s photographers and asked them to export their edited RAW files with a Display P3 profile rather than the sRGB default most editing software assumes. It’s a small workflow change — one export setting — but it’s the difference between capturing the wider gamut and inventing it after the fact, which doesn’t really work.

The pipeline.

The site itself is a SvelteKit application on Cloudflare’s edge network, with an R2 bucket for storage and a Postgres database. The upload flow is straightforward: an image lands in R2, a record is written to the database, and a request goes out to a separate image transformation service with the details of the original.

That service is a small Hono application running on a VPS. It fetches the original, and produces a full set of responsive variants — JPEG and WebP, each in both P3 and sRGB — before writing them back to R2 and marking the database record that transformation is complete. Generating both gamuts, rather than just P3, matters just as much as the P3 work itself: a P3 image sent to a display that doesn’t support it can render with dull or shifted colour, so the sRGB set isn’t a fallback in name only — it has to be a properly graded, correct version in its own right.

Because this transformation happens asynchronously, the site’s image component checks whether formatting is done. If it isn’t yet, it shows the original upload as-is, so editors see their image immediately rather than a broken state. Once processing completes, the component renders a full <picture> element with every variant available, and lets the browser choose.

Letting the browser decide.

The actual mechanism for gamut selection is a single CSS media feature: color-gamut. Inside the <picture> element, <source> tags carry a media="(color-gamut: p3)" query alongside the usual type and srcset attributes. A browser on a P3-capable display matching that query will pick the P3 source; everything else falls through to the sRGB sources, exactly as <picture> was always designed to work with format and resolution. No JavaScript, no user-agent sniffing, no risk of serving the wrong image to the wrong screen. The browser already knows what its display can do — the job was just giving it the option.

<picture>
  <!-- 1. Display P3 WebP (Best quality + Wide Color for modern displays) -->
  <source
    type="image/webp"
    media="(color-gamut: p3)"
    srcset="
      /images/hero-p3-400w.webp 400w,
      /images/hero-p3-800w.webp 800w,
      /images/hero-p3-1200w.webp 1200w
    "
    sizes="(max-width: 768px) 100vw, 1200px"
  />

  <!-- 2. Standard sRGB WebP (Modern format, standard color space fallback) -->
  <source
    type="image/webp"
    media="(color-gamut: srgb)"
    srcset="
      /images/hero-srgb-400w.webp 400w,
      /images/hero-srgb-800w.webp 800w,
      /images/hero-srgb-1200w.webp 1200w
    "
    sizes="(max-width: 768px) 100vw, 1200px"
  />

  <!-- 3. Display P3 JPEG (Legacy browser/device with wide-gamut screen) -->
  <source
    type="image/jpeg"
    media="(color-gamut: p3)"
    srcset="
      /images/hero-p3-400w.jpg 400w,
      /images/hero-p3-800w.jpg 800w,
      /images/hero-p3-1200w.jpg 1200w
    "
    sizes="(max-width: 768px) 100vw, 1200px"
  />

  <!-- 4. Default Fallback (sRGB JPEG for ultimate compatibility) -->
  <img
    src="/images/hero-srgb-1200w.jpg"
    srcset="
      /images/hero-srgb-400w.jpg 400w,
      /images/hero-srgb-800w.jpg 800w,
      /images/hero-srgb-1200w.jpg 1200w
    "
    sizes="(max-width: 768px) 100vw, 1200px"
    alt="Cocktail served at Cato bar"
    loading="lazy"
  />
</picture>

Was it worth it?

Almost certainly not, in any strict cost-benefit sense. It added a second full set of generated variants, extra transform time on every upload, and genuine complexity to a pipeline that could have shipped in an afternoon without it. Nobody visiting the site consciously notices “ah, wider gamut.” If anything, the win is invisible by design — which is either the best or worst kind of engineering effort, depending on your mood that day.

But invisible isn’t the same as unimportant. For a brand built entirely on the idea that colour carries meaning, serving a slightly duller version of every photograph would have been a small, constant betrayal of the concept — one nobody could quite put their finger on, but everyone would feel. Colour Has Flavour deserved to actually taste of something. The pipeline is a bit of engineering nobody will ever be told about, in service of a detail that, for this client, was never really optional at all.

For decades, web designers and developers have been constrained by the limitations of sRGB and the awkwardness of HEX notation. We’ve all been there: staring at #3A7BD5 and trying to remember whether that’s the blue we wanted, or wrestling with RGB values that bear no resemblance to how we actually perceive colour. However, the landscape is changing, and OKLCH (Oklch colour space) represents perhaps the most significant advancement in how we define and manipulate colour on the web.

The problem with traditional colour spaces.

Let’s start with what we’ve been using. HEX codes, whilst compact, are essentially meaningless to the human eye. Can you tell me what #FF6B9D looks like without looking at it? Probably not. RGB and even HSL, whilst more intuitive than HEX, have their own shortcomings.

HSL (Hue, Saturation, Lightness) was a step forward. At least you could read hsl(200, 50%, 60%) and have some idea that you were looking at a medium-light blue. But HSL has a fundamental flaw: its lightness component isn’t perceptually uniform. A yellow at 50% lightness appears far brighter than a blue at the same 50% lightness. This makes creating harmonious colour palettes considerably more difficult than it should be.

RGB suffers from similar issues. It’s based on how screens emit light, not how humans perceive colour. This disconnect between the technical representation and our perception has real-world consequences when you’re trying to build accessible, visually coherent designs.

Perceptually uniform colour.

OKLCH (Oklab Lightness Chroma Hue) is built on the Oklab colour space, which was specifically designed to be perceptually uniform. What does this mean in practice? When you adjust the lightness value in OKLCH, the perceived brightness changes uniformly across all hues. A blue at 60% lightness will appear just as bright as a red at 60% lightness. This is transformative for designers.

The syntax is refreshingly straightforward: oklch(60% 0.15 250). That’s lightness (0-100%), chroma (roughly equivalent to saturation, typically 0-0.4), and hue (0-360 degrees). Just like HSL, you can read this and immediately understand what you’re looking at, but unlike HSL, the values actually correspond to how you perceive the colour.

Unlocking Display P3.

Perhaps the most exciting aspect of OKLCH is its native support for wide-gamut colours. The sRGB colour space, which has been the web’s standard since the 1990s, can only represent about 35% of the colours visible to the human eye. Modern displays—particularly phones, tablets, and high-end monitors—support Display P3, which encompasses roughly 50% of visible colours.

With OKLCH, you can specify colours that exist beyond the sRGB gamut. That electric cyan you’ve been trying to achieve? The vibrant coral that always looks slightly muted? These colours are now accessible. And here’s the clever bit: if a display doesn’t support Display P3, OKLCH automatically falls back to the nearest sRGB colour. Your designs remain functional whilst taking advantage of better displays where available.

Try achieving this with HEX or standard RGB notation, and you’ll quickly find yourself in a world of colour profile conversions and browser inconsistencies.

Comparing modern alternatives.

It’s worth examining how OKLCH stacks up against other modern colour spaces now available in CSS:

Display P3

Display P3 is a colour space, not a notation. You can write color(display-p3 1 0.5 0.3), but these RGB-style values suffer from the same perceptual non-uniformity as sRGB. You’re working with wider colours, but you’re still guessing at the results.

LCH

LCH (Lightness Chroma Hue) was a significant step forward and shares OKLCH’s human-readable format. However, it’s based on the older CIELab colour space, which has some perceptual quirks. Blues tend to appear darker than they should, and certain hue transitions can look uneven. OKLCH, based on the newer Oklab, corrects these issues.

LAB and Oklab

LAB and Oklab are powerful but less intuitive. Working with values like lab(60% 20 -40) requires understanding what positive and negative values mean for red-green and blue-yellow opponent channels. For most design work, the polar coordinate system of OKLCH (with its explicit hue angle) is far more practical.

Practical benefits in real-world work.

The advantages of OKLCH extend beyond theory into everyday design tasks:

Colour palettes become trivial to create.

Need a lighter version of your brand colour? Increase the lightness value. Want a desaturated variant? Reduce the chroma. The perceptual uniformity means these adjustments work consistently across your entire palette.

--red-100: oklch(0.5726 0.2037 26.3); /* Base colour */
--red-75: oklch(from var(--red-100) calc(l + (1 - l) * 0.25) c h); /* 25% brighter */
--red-50: oklch(from var(--red-100) calc(l + (1 - l) * 0.5) c h); /* 50% brighter */
--red-25: oklch(from var(--red-100) calc(l + (1 - l) * 0.75) c h); /* 75% brighter */

Gradients maintain their vibrancy.

Anyone who’s created a gradient from yellow to blue knows the muddy grey that appears in the middle. OKLCH gradients maintain colour vibrancy throughout the transition because the interpolation happens in a perceptually uniform space. To ensure your gradient interpolates in OKLCH, simply specify it in the gradient declaration:

background: linear-gradient(in oklch, 
  #ffa44e,
  oklch(70% 0.189 240)
);

The in oklch keyword tells the browser to perform the colour interpolation in the OKLCH colour space, ensuring smooth, vibrant transitions even when mixing colours defined in other formats.

Accessibility improvements are more predictable.

When contrast ratios are calculated based on perceived lightness, and your colour space accurately represents perceived lightness, ensuring sufficient contrast becomes more straightforward. The lightness value in OKLCH directly correlates to how bright text or backgrounds will appear.

Systematic colour generation becomes possible.

You can programmatically generate entire colour schemes by varying OKLCH parameters whilst maintaining visual harmony. This is invaluable for design systems, theming, or any project requiring consistent colour variations.

--brand-colour: oklch(0.6739 0.1906 36.33);
--complementary: oklch(from var(--brand-colour) l c calc(h - 180)); /* Hue rotated 180º */

The from keyword in CSS allows you to create new colours based on existing ones, accessing and manipulating individual OKLCH channels. This means you can define a single brand colour and systematically generate an entire palette—lighter variants, darker text colours, or colour harmonies—all whilst maintaining the perceptual relationships that make the palette feel cohesive.

Browser support and progressive enhancement

At the time of writing, OKLCH enjoys excellent support in modern browsers. Safari, Chrome, Edge, and Firefox all support OKLCH, covering the vast majority of users. If you must support older browsers, progressive enhancement is straightforward: provide an sRGB fallback, then specify your OKLCH value. Browsers that don’t understand OKLCH will ignore it and use the fallback.

.element {
  background: #1483dc; /* Fallback */
  background: oklch(0.6 0.163 250); /* Modern browsers */
}

This is the beauty of CSS: it’s designed for exactly this kind of graceful degradation.

Making the switch

Transitioning to OKLCH doesn’t require rebuilding everything overnight. You can adopt it incrementally, starting with new projects or specific components. Tools like colour converters can help translate existing palettes, though you’ll likely find yourself rethinking some colour choices once you see what’s possible.

The learning curve is minimal if you’re already comfortable with HSL. The syntax is similar, the values are human-readable, and the results are more predictable. It’s simply a better tool for the job.

OKLCH represents a fundamental improvement in how we work with colour on the web. It combines human-readable syntax with perceptual uniformity and wide-gamut support, solving problems that have plagued designers since the web’s inception. As displays continue to improve and users expect more vibrant, engaging experiences, OKLCH is here, well-supported, and it’s the pragmatic choice for modern CSS.

We're excited to share that our project for Isabella Vranic has been awarded Site of the Day, marking our second recent recognition in the Vice Website Awards. This project represents everything we love about working with passionate individuals who are ready to make their mark in the digital space.

Isabella Vranic came to us with a clear vision: she wanted to expand her personal brand as a digital marketing professional while creating a platform to educate others about diabetes through her podcast, "Diabetes Decoded." The challenge was to build a site that could seamlessly blend professional portfolio functionality with podcast hosting capabilities, all while reflecting Bella's expertise and authentic voice.

The result is a fast, responsive website that goes beyond typical portfolio sites. We developed a custom podcast audio player that persists between pages, allowing visitors to continue listening while exploring Bella's work. The player even saves audio progress, so users can pick up where they left off if they accidentally close their browser. An automatically generated RSS feed ensures the podcast reaches all major platforms, extending Bella's reach beyond her website.

What makes this project particularly rewarding is how it demonstrates the impact of purposeful design. Bella isn't just showcasing her marketing expertise—she's using her digital skills to address real challenges faced by people with diabetes. Her site becomes a hub for both professional opportunities and meaningful advocacy work.

This recognition reinforces our belief that personal branding websites should be more than digital business cards. They should be platforms that amplify expertise, facilitate meaningful connections, and enable individuals to share their unique perspectives with the world. This project for Isabella achieves all of this while maintaining the technical excellence and user experience standards that define our work.

As we celebrate this award, we're reminded of why we're passionate about working with forward-thinking individuals and brands. Whether it's a startup looking to make waves or a professional ready to expand their influence, great digital experiences start with understanding what makes each story worth telling.

We're thrilled to announce that our latest project, "Trickle — No fuss. Big flavour." has been awarded Site of the Day from the Vice Website Awards. This recognition celebrates not just our design and development expertise, but the collaborative spirit that drives every project at Studio Smith-Cordell.

The Trickle project exemplifies our digital-first approach to brand storytelling. Working closely with the Bart & Taylor team, we created a web experience that perfectly captures their brand philosophy of simplicity meeting bold flavor. The site's confident, intuitive design allows the concept to shine while delivering an engaging user journey that converts visitors into customers.

What makes this recognition particularly meaningful is how it validates our belief that great digital experiences emerge from the intersection of strategic thinking, creative vision, and technical excellence. The Vice Website Awards celebrate sites that push boundaries while maintaining usability—exactly the balance we strive for in every project.

This award represents more than individual achievement; it's a testament to the power of partnership. The Bart & Taylor team trusted us with their vision, and together we created something that resonates with both industry professionals and end users. It's this collaborative approach that continues to drive our studio forward.

As we celebrate this milestone, we're already looking ahead to new challenges and opportunities. For forward-thinking brands ready to make their mark in the digital space, this recognition reinforces why Studio Smith-Cordell remains the partner of choice for bespoke websites and web applications that truly make a difference.

Thank you to the Vice Website Awards judges, the Bart & Taylor team, and everyone who has supported our journey. Here's to creating more award-winning digital experiences that matter.

As the founder of a digital-first design and development studio, we pride ourselves on creating bespoke digital experiences that convert while delighting users. We spend our days crafting engaging, high-performance websites that help our clients achieve their business goals. Yet, somehow, when it came to our own digital presence, we had fallen into a classic trap: the cobbler's children had no shoes.

The convenience trap

Like many studio owners, I found myself stretched thin across client projects, team management, and business development. In the name of efficiency, I optimised our website for my convenience rather than for our prospects' experience. The centerpiece of our lead generation strategy was a prominently displayed Calendly integration that allowed potential clients to book discovery calls directly into my calendar.

On paper, this is a win-win. Prospects could instantly schedule time with me without the back-and-forth of email coordination, and I could efficiently fill my calendar with potential business. The reality, however, told a different story.

We began noticing concerning patterns:

• High-value prospects were meeting with competing agencies before speaking with us
• No-show rates were creeping upward
• Many scheduled calls were with leads lacking appropriate budgets for our services
• Other potential clients bypassed the scheduling tool altogether, sending vague emails that required extensive follow-up

What I had designed for my convenience was undermining our business development efforts. The frictionless booking process meant we could not qualify leads or establish value before the call. And without contextual information about their projects, we entered conversations at a disadvantage.

The revelation

The turning point came during a client project where we were optimising their conversion funnel. As we analysed the data and redesigned their lead capture process, I had an uncomfortable realisation: we failed to apply our expertise to our website.

We regularly tell clients that successful digital experiences balance business objectives with user needs. Yet our site prioritised neither. Ironically, it wasn't serving prospects or genuinely serving our business.

The transformation

Armed with this insight, we embarked on a complete overhaul of our website with two primary objectives:

1. Create a lightning-fast, engaging experience that reflects our capabilities
2. Implement a lead generation approach that better qualifies prospects while capturing crucial project information

Performance first

We rebuilt the entire site using a modern JavaScript framework, focusing on performance optimisation at every step. This technical foundation ensures visitors experience our site as we intend—quick, responsive, and friction-free. It reinforces our reputation for technical excellence before a single word is exchanged.

Strategic lead capture

The more significant change, however, was our approach to lead generation. We replaced the calendar booking tool with a simple form that requests the prospects contact information, a budget indication, and prompts the prospect to provide information about the project without feeling overwhelming.

The form submissions are instantly posted to a dedicated Slack channel, alerting me to new opportunities while simultaneously being logged into our database for tracking and analysis.

Higher quality leads

By requesting budget information upfront, we now quickly identify prospects aligned with our service level. This transparency benefits everyone—clients find agencies matching their investment level, and we focus our energy on opportunities where we can deliver appropriate value.

More informed conversations

When we do schedule discovery calls, we now enter them with substantial context. This allows us to prepare relevant case studies and questions, demonstrating our expertise from the first interaction and accelerating the trust-building process.

Lessons learned

This experience reinforced several valuable lessons:

Apply your expertise internally

As service providers, we must apply the same rigor to our business that we bring to client work.

Convenience isn't always optimal

What seems efficient in the short term may undermine long-term objectives.

Qualification is mutual

The proper lead capture process helps prospects determine if you're a good fit for them, not just the reverse.

Technology choices matter

Building on modern, performant frameworks isn't just about technical preferences—it directly impacts user experience and business outcomes.

Moving forward

Our website will continue to evolve as we gather more data and feedback. The current version isn't perfect, but it represents a significant step toward aligning our digital presence with our capabilities and business goals.

For other studio/agency owners, I encourage you to step back periodically and evaluate whether you're applying your expertise to your digital presence. Are you falling into the convenience trap? Is your website genuinely conveying your value proposition and capturing the necessary information to succeed?

Sometimes, the most important client we serve is ourselves.

When Perfect Havoc, a UK dance and house record label based in London, approached Studio Smith-Cordell with a unique challenge, it highlighted a common scenario in modern web development: how to extend a platform's capabilities while maintaining security and user experience. Their existing Webflow website needed a secure, password-protected form for artist onboarding that would interface with their royalties platform—a requirement that pushed beyond Webflow's native capabilities.

The challenge: security meets functionality

Webflow excels as a website-building platform, offering powerful design/development tools and hosting capabilities. However, like many no-code/low-code platforms, it has limitations when it comes to server-side operations. In Perfect Havoc's case, they needed to:

• Create a secure, password-protected form for new artists
• Interface with multiple APIs requiring secret keys
• Embed an external platform via iFrame post-authentication
• Maintain data security throughout the process

The primary challenge was not just implementing these features but doing so securely. API keys are like digital passwords for applications, and exposing them in client-side code would be equivalent to leaving your house keys under the doormat.

Engineering a secure solution

Our approach combined the best of both worlds: Webflow's excellent front-end capabilities with custom secure infrastructure. We developed a two-part solution:

1. A lightweight JavaScript application embedded within the Webflow page, handling user interactions and form display
2. A Cloudflare Worker serving as our secure backend, managing API communications and protecting sensitive credentials

This architecture allowed us to keep all sensitive operations server-side while maintaining a seamless user experience. Cloudflare Workers proved to be an ideal choice, offering:

• Edge computing capabilities for faster response times
• Secure environment for API key storage
• Cost-effective scaling
• Minimal maintenance requirements

Why this approach matters

Security isn't just a feature—it's a fundamental requirement in modern web development. When handling sensitive data like artist information and payment details, there's no room for compromise. Our solution demonstrates how to bridge the gap between platform limitations and security requirements.

Consider these statistics: according to IBM's Cost of a Data Breach Report, the average cost of a data breach reached $4.88 million in 2024. Many of these breaches occur due to exposed API keys and inadequate security measures. By implementing proper security architecture from the start, we help our clients avoid becoming part of these statistics.

The bigger picture: extending platform capabilities

This project exemplifies a broader trend in web development: the need to extend platform capabilities without sacrificing security or user experience. While platforms like Webflow provide excellent foundations, businesses often need custom solutions to:

• Integrate with external services and APIs
• Implement complex authentication flows
• Handle sensitive data securely
• Create custom functionality specific to their business needs

Our approach demonstrates how to achieve these goals while working within platform constraints. By combining Webflow's strengths with custom solutions, we deliver secure, scalable, and maintainable solutions.

Looking forward

As web platforms evolve, the need for secure custom solutions will grow. At Studio Smith-Cordell, we specialise in bridging these gaps, helping clients leverage the best of both worlds: the ease of use and reliability of established platforms like Webflow, combined with the power and security of custom solutions.

There’s often a secure, elegant solution for businesses using Webflow or similar platforms who find themselves bumping up against platform limitations. Whether integrating with external APIs, implementing custom authentication flows, or adding unique functionality, these challenges can be addressed without compromising security or user experience.

The Perfect Havoc project showcases how modern web development requires thinking beyond platform constraints. Combining Webflow's excellent front-end capabilities with secure custom infrastructure, we delivered a solution that met all security and functionality requirements while maintaining a seamless user experience.

If your Webflow website needs functionality that pushes beyond the platform's native capabilities, remember that solutions exist. With the right approach and expertise, it's possible to extend your website's capabilities while maintaining the security and reliability your business demands.

Whether you're looking to integrate external services, implement custom authentication, or add unique functionality to your Webflow site, Studio Smith-Cordell has the expertise to help you achieve your goals securely and effectively.

Studio Smith-Cordell, a digital-first design studio known for crafting bespoke web experiences, has received an Honors award from Awwwards for their innovative project My Delhi Indian Streetary. The recognition, awarded on September 17, 2024, celebrates the studio's commitment to excellence in digital design and development.

The award-winning project showcases Studio Smith-Cordell's signature approach of blending aesthetic excellence with technical innovation. The Awwwards recognition acknowledges the "great talent and effort invested in its creation," highlighting the studio's dedication to pushing creative boundaries in the digital space.

My Delhi exemplifies Studio Smith-Cordell's holistic approach to digital design, where brand storytelling meets cutting-edge development. The project joins the studio's growing portfolio of work for forward-thinking brands worldwide, reinforcing their position as innovators in the digital design landscape.

This recognition from Awwwards, a prestigious authority in web design excellence, validates Studio Smith-Cordell's mission to create engaging and delightful brand interactions that resonate with modern audiences while maintaining exceptional functionality.

For more information about Studio Smith-Cordell and their award-winning work, visit smith-cordell.com.

We are immensely proud to announce that our work on the Bart & Taylor website has been recognised with an Honorable Mention award from Awwwards. This accomplishment reflects our dedication, skill, and unwavering commitment to pushing the boundaries of digital design.

Behind the design

When we began our collaboration with Bart & Taylor, the goal was clear — to mirror their vision of redefining local hospitality on a digital canvas. As we embarked on this journey, we ensured the website copy and every design choice, from layout to typography, narrated their ethos and commitment to community and excellence.

Why this recognition matters

Awwwards is renowned worldwide for championing creativity, design, and innovation on the web. Receiving Honors is a nod to our relentless pursuit of excellence and an acknowledgement that we're on the right track in setting industry standards.

A note of thanks

Successes like these are team efforts. We want to extend our gratitude to everyone involved who brought this project to life. From the photographers who have expertly captured each of the Bart & Taylor venues and their food and drink offerings to Ground who created the Bart & Taylor brand identity. We thank Bart & Taylor for their trust and collaboration in this venture.

As we celebrate this achievement, we're also reminded of our mission: to utilise the power of branding, design and content to empower brands to thrive in our modern digital age. With this accolade, we're even more energised for what the future holds.

We're thrilled to announce that our recent project, "Fern — From Dawn 'till Dusk", has garnered significant recognition in the digital design world. Awwwards, a platform renowned for spotlighting the talent and effort of the best web designers, developers, and agencies in the world, has graced us with an 'Honorable Mention' award.

This achievement underscores our unwavering commitment to crafting bespoke digital experiences that not only resonate with audiences but also push the boundaries of contemporary web design. A heartfelt thank you to our wonderful client who trusted us with their vision, and the Awwwards judges for this honour.

For those who haven't seen our award-winning design, you can explore it here. Stay tuned as we continue to create delightful brand interactions in our ever-evolving digital landscape.

At Studio Smith-Cordell, we're constantly in pursuit of creative excellence. Our purpose has always been to design and develop websites that look fabulous and function flawlessly while resonating with users in ways that truly matter. This drive has guided us through projects, continually pushing us to raise the bar higher with each new undertaking.

A short while ago, we pledged to you, our clients, our followers, and the broader global community. We committed to going beyond just creating high-quality digital experiences. We promised to design responsibly, acknowledging the environmental implications of our work and striving to offset the carbon footprint resulting from every website we create.

Today, we're thrilled to report on the first fruits of that commitment, delivered through the successful completion of a brand-new e-commerce website for Flowers from the Grove, an Australian florist specialising in native Australian flowers. This project was the perfect opportunity to put our new eco-design principles into practice and fulfil our promise to balance digital innovation with environmental responsibility.

Firstly, let's touch on the steps we took to reduce the website's emissions during the development phase. We used minification where possible, a technique that removes unnecessary characters from the code without affecting functionality. Minification made our code leaner and more efficient, reducing the time taken to transmit data between the server and the end-user and thereby consuming less energy.

We also implemented the use of modern compressed image formats throughout the website. This action resulted in significantly reduced file sizes without compromising the visual integrity of the images. As a result, less data is transferred when images are viewed, making the website faster and more environmentally friendly.

Furthermore, the website runs on sustainable energy. As a digital entity, a website doesn't consume energy directly, but it relies on servers that do. By hosting the website on servers powered by renewable energy, we're helping to shift the Internet's power sources away from fossil fuels and towards a more sustainable future.

But we didn't stop there. Our green initiative extends beyond just reducing emissions – it's about actively participating in environmental restoration and resilience. After assessing the potential ecological impact of the 'Flowers from the Grove' website, we decided to plant ten trees in our dedication to creating a positive environmental impact.

We did this by donating to Tree Canada, a reputable organisation dedicated to planting and nurturing trees across Canada. Since 1992, they've planted a staggering 84 million trees across all provinces and territories, offsetting carbon emissions and enhancing biodiversity, improving air and water quality, and enriching local communities.

It's easy to get overwhelmed by the sheer scale of the global climate crisis. However, if each of us takes small, meaningful steps towards sustainability, together we can make a significant difference. It's with this spirit that we pledge to make every project at Studio Smith-Cordell a part of the solution rather than adding to the problem.

While the steps we've taken with Flowers from the Grove are significant, we acknowledge that there's always room for improvement. We're constantly learning and adapting our practices to be more sustainable, and we're open to any suggestions you may have.

Our commitment to transparency and accountability remains strong. We'll continue to keep you informed about our initiatives, partners, and the outcomes of our eco-design strategies. You can expect more updates on our tree-planting efforts and case studies demonstrating how we're integrating sustainability into our design processes.

In conclusion, we'd like to express our sincere gratitude to Flowers from the Grove for trusting us with their web design project and joining us on this eco-design journey. We also thank all of you who've been a part of this journey so far and have shown support for our green initiative.

We're convinced that creativity and environmental responsibility are not mutually exclusive but can — and should — go hand in hand. Through small, consistent actions, we hope to contribute to a greener Internet, a sustainable future for digital innovation, and a healthier planet for all.

Remember, the fight against climate change is a collective effort. Every website we make greener and every tree we plant brings us one step closer to a more sustainable digital world.

Thank you for being a part of this important journey with us, and we're excited about continuing to create fantastic, sustainable designs together.

At Studio Smith-Cordell, we have always prided ourselves on crafting innovative and engaging websites for a wide range of clients. With each design project, we aim to create something unique, responsive, and impactful. Today, we are turning a new leaf in our journey and taking a step forward to be not just creative and efficient but also environmentally responsible.

Let's pause for a moment and think about something you may have never associated with web design — carbon footprint. As web developers, we spend countless hours on the Internet, creating, tweaking, and fine-tuning websites. But what if we told you that the Internet, the very platform we rely on for our craft, has a colossal carbon footprint? Yes, you read that correctly.

Recent studies suggest that if the Internet were a country, it would have the fourth largest carbon footprint in the world, right after China, the United States, and India. This might seem surprising at first. After all, the Internet doesn't spew out smoke like a factory, nor does it guzzle fuel like an aeroplane. Yet the servers that power our emails, social media, and, indeed, the websites we create consume massive amounts of energy. And most of this energy, unfortunately, comes from carbon-intensive sources.

We find this revelation as staggering as it is alarming, especially given the ongoing climate emergency. As inhabitants of this planet, it is our collective responsibility to minimise our carbon footprint in every way we can. And, as a creative design agency, we believe it's high time we considered the environmental implications of our work.

So, what can we do?

Well, we have an answer: starting today, Studio Smith-Cordell commits to offsetting the carbon impact of each new website we create. And we will achieve this by planting trees after every web design project. Trees are nature's carbon capture technology — they absorb CO2 from the atmosphere and release oxygen, helping to tackle the climate crisis.

But why trees? Simply put, trees are one of the most cost-effective and efficient means of sequestering carbon. They also provide habitat for wildlife, improve air and water quality, and contribute to the well-being of communities. By supporting tree planting, we're investing in a solution that goes beyond just reducing our carbon footprint — it also promotes biodiversity and enhances local ecosystems.

For each project we undertake, we will calculate the estimated carbon emissions and then plant the appropriate number of trees to offset those emissions. This won't just be a one-time gesture but an ongoing commitment. For every update, revision, or redesign we carry out, we will ensure the net carbon impact remains zero.

We realise this is just a small step in the face of a global problem, but we firmly believe in the adage: 'A journey of a thousand miles begins with a single step.' By incorporating this new commitment into our business model, we hope to encourage other creative agencies to join us in our mission towards a greener, more sustainable Internet.

We understand that our clients might have questions about this initiative. How will the tree planting work? How will we ensure the trees are actually planted and cared for? How can you, as a client, verify our actions? In the coming weeks, we will be providing more details on this initiative, the partners we'll be working with, and how our clients can get involved and see the impact of their projects firsthand.

In the meantime, we welcome any suggestions, thoughts, or queries you might have. Let's embark on this journey together towards a greener and more sustainable future for our digital world. Because at Studio Smith-Cordell, we believe that great design and environmental responsibility go hand in hand.

Thank you for being a part of our journey, and let's move forward together in creating a greener, cleaner Internet.

As an e-commerce business owner, your website is the backbone of your digital operations – it's where you showcase your products, take orders, and process payments. It's also the face of your brand, and you want it to make a good impression on your customers. But how do you design a website that's both functional and visually appealing?

Fear not, dear reader – we've compiled a list of web design best practices for e-commerce to help you create a website that's a cut above the rest. Follow these tips to make your website user-friendly, visually appealing, and optimised for conversions:

Keep it simple, stupid.

You want to make it as easy as possible for customers to find what they're looking for and complete a purchase. A clean, uncluttered design can help with that. Use a clear hierarchy to organise your content and ensure that the most critical information (like product descriptions and pricing) is easy to find.

Show off your goods with high-quality product images.

Your product images are often the first thing customers will see when they land on your website, so they need to be top-notch. Use high-resolution images that show off your products in the best possible light. It would be best to consider using multiple images for each product, including ones with different angles and close-ups.

Make the checkout process a breeze.

No one likes a long, complicated checkout process. Consider using a one-page checkout or a streamlined multi-page process to make things easier for your customers. You should also ensure the checkout is secure and use a payment processor that customers can trust.

Optimise for mobile.

More and more people are using their phones to shop online, so it's essential to make sure that your website is mobile-friendly. This means it should be easy to use on a smaller screen and load quickly.

Include customer reviews.

Customer reviews can be a powerful tool for e-commerce websites. They provide social proof that can help boost sales and increase customer trust. Make sure to include reviews on your product pages, and consider using a review platform that allows customers to leave ratings and detailed feedback.

Use clear calls to action.

Calls to action (like "add to cart" or "buy now") are an essential part of e-commerce web design. They should be prominent and easy to find and use clear, actionable language.

By following these best practices, you can create an e-commerce website that's easy to use, visually appealing, and optimised for conversions. With some planning and attention to detail, you can create a website that will help your business thrive. So go forth and create a website that'll have your customers clicking "add to cart" in no time!

When creating a successful website, user experience (UX) is essential. But what exactly is UX, and why is it so important?

UX refers to how a person feels when interacting with a website. It's about ensuring the website is easy to use, accessible, and satisfying for the user. By prioritising UX in your web design, you can create a website that not only meets the needs of your visitors but also delights them. But where do you start when it comes to improving UX? Here are five key elements to consider:

Usability

A website should be a breeze to navigate and understand. Make sure you have a clear structure, with clear headings and subheadings, to guide visitors through the content. Visitors should also easily find what they're looking for, whether it's information, products, or contact details.

Accessibility

Your website should be accessible to everyone, no matter what device they're using or what abilities they have. This includes ensuring that your website is easy to use on mobile devices and accessible to users with disabilities, such as those who are blind or have low vision.

Aesthetics

While functionality is essential, your website's appearance also plays a role in UX. Aim for a clean, visually appealing design that is easy on the eyes. Choose a suitable colour scheme and use high-quality images and graphics to help tell your story.

Speed

In today's fast-paced world, people expect websites to load quickly. However, a slow-loading website can be frustrating for visitors and lead to a higher bounce rate (when visitors leave your site without interacting with it). Therefore, optimising your images and using a fast hosting provider is crucial to improve speed.

Mobile-friendliness

With the proliferation of mobile devices, your website must be mobile-friendly. A responsive design ensures that your website looks and functions well on any device, regardless of screen size or resolution. This is essential for providing a good user experience and ensuring that you don't miss out on potential customers accessing the internet on their phones.

By focusing on these five elements of UX, you can create a website that is not only functional but also enjoyable to use. And when it comes to building a successful online presence, great UX is non-negotiable. So if you're in the process of designing a website, be sure to put the user experience at the top of your priority list. Your visitors — and your bottom line — will thank you.

The impact of colour in web design cannot be overstated. It has the power to influence many aspects of your website. Here's a closer look at some key aspects:

Emotional response

A colour is a powerful tool for evoking emotions in people. Different colours can have various associations and connotations, and by choosing the right colours for your website, you can help to create the desired emotional response in your visitors. For example, red can bring about feelings of passion and energy, while blue can evoke feelings of calmness and trustworthiness. By considering the emotional impact of colour, you can create a more engaging and effective user experience.

Branding

Colour is a fundamental branding element, and your website is no exception. The colours you use on your website should be consistent with your overall brand identity. This helps to create a cohesive look and feel and can help to strengthen your brand in the minds of your users. For example, if your brand is associated with eco-friendliness, you might use shades of green on your website to reinforce this association. On the other hand, if your brand is associated with luxury, you might use richer, more luxurious colours like gold and purple.

Visual hierarchy

The use of colour can also help to create a visual hierarchy on your website, which can be especially important if you have a lot of content. Using different colours to highlight important information or calls to action can help guide your users through your content and make it easier for them to find what they are looking for. For example, you might use a bright colour to draw attention to a sign-up form or a button you want users to click. This can increase the effectiveness of your website by directing the user's attention to essential elements.

Accessibility

It's vital to consider the accessibility of your website when choosing colours. Some users, such as those with colour blindness, may have difficulty distinguishing specific colours. By using a colour scheme accessible to all users, you can ensure that your website is usable by everyone. This can be achieved by using a combination of colours that have sufficient contrast and avoiding using colour as the only means of conveying information.

Using colour in web design is a crucial factor that can significantly impact a website’s overall look. By carefully considering the emotional response, branding, visual hierarchy, and accessibility of your website, you can create a user experience that is both enjoyable and effective.

As a web designer, it's essential to avoid common mistakes that can ruin a website's user experience and effectiveness. These mistakes can not only drive visitors away but also hurt your search ranking and prevent your website from achieving its full potential. Here are the top five web design mistakes to avoid at all costs:

1. Clutter overload

A cluttered website can be a major turn-off for visitors, making it hard for them to find what they're looking for. Too much information, graphics, or other elements on the page can be overwhelming and distract from the central message of your website. To avoid clutter, use a clear layout and include only the most essential information. You can also use whitespace effectively to break up the content and make it easier to read.

2. Illegible text

No one wants to strain their eyes reading tiny, hard-to-read text. Poorly formatted text can be challenging to read and may turn visitors away. To ensure that your text is easy to read, use a clear font and ensure that the size and colour contrast are suitable for the background. For example, dark text on a light background is generally easier to read than light text on a dark background.

3. Slow loading times

In today's fast-paced world, no one has the patience for slow-loading pages. If your pages take too long to load, visitors may bounce. Optimise your images and use a fast hosting provider to improve page loading times. You can also use caching and other techniques to improve speed.

4. A non-responsive design

With more and more people accessing the internet on their phones, your website must be mobile-friendly. A non-responsive design will provide a bad experience for mobile users and could hurt your search ranking. Instead, use a responsive design to ensure that your website looks and functions well on any device, regardless of screen size or resolution.

5. A lack of focus

A website without a clear focus can confuse visitors and make it hard for them to understand what your business does and offers. To avoid this, be sure to have a clear and concise message and focus on explaining the benefits of your products or services in terms that are easy to understand. Avoid jargon or industry-specific language that may confuse the average visitor. Instead, focus on straightforwardly conveying your offerings' value.

By avoiding these common web design mistakes, you can create a website that is effective, user-friendly, and successful. A well-designed website not only helps you attract visitors but also helps you convert them into customers. So, if you're in the process of designing a website, be sure to keep these mistakes in mind and take the time to create a user-friendly, effective design. Your visitors — and your bottom line — will thank you.

There are many different website development tools, content management systems (CMS) and frameworks to choose from, both commercially and with open-source licenses—and we use many of them. However, we select Webflow for most marketing website builds. Here are seven reasons why:

Rapid development

Webflow is a visual development tool that allows developers to build at a higher speed than traditional hand-coded solutions while still allowing the full implementation of custom code where necessary. As a result, a reduction in development time reduces the overall cost of a website build.

Fully bespoke

Webflow doesn’t rely on templates to create a website. Instead, you can completely customise and build any design starting from a blank canvas.

The Webflow Editor

The Webflow Editor is intuitive and allows a website owner to adjust content on-page without affecting the design with ease. There is no complex dashboard to navigate.

Bloat free clean code

Webflow generates clean code without excess bloat from unused functions, resulting in faster-loading websites that are more SEO-friendly.

Security you can trust

Webflow requires no manual security updates or plugin maintenance which means a much lower risk of a malicious actor taking down your website. Instead, all security patches and maintenance are automatic. In addition, all Webflow websites include an SSL certificate providing end-to-end encryption.

No updates, no worries

Webflow doesn’t require regular manual updates and doesn’t require the use of third-party plugins. As a result, there’s no risk of updates breaking third-party code and crashing a website, thus removing potentially expensive maintenance costs when something goes wrong.

World-class hosting

Webflow provides lightning-fast, ultra-reliable hosting without the hassle of maintenance. Built using Amazon Web Services (AWS) and Fastly’s networks, Webflow-hosted websites take advantage of enterprise-grade scalability and security. While processing over 10 billion page views a month, Webflow hosting had 99.99% uptime in the last 12 months*.

‍^{*as of January 2023}

Using Webflow, we can deliver bespoke websites faster than traditional methods while maintaining the highest quality.

Are you tired of DIY website disasters? Do you want to create a professional online presence that impresses and engages your audience? If so, it's time to consider partnering with a top-notch web design studio.

Sure, there are plenty of website builders and templates out there that promise an easy, affordable solution. But let's be real: those cookie-cutter designs are about as appealing as a bowl of cold oatmeal. On the other hand, a professional web design studio has the skills and experience to craft a website that truly stands out from the competition.

But it's not just about looks. A web design studio can also optimise your site for search engines, ensuring potential customers easily find your business. And, as your business grows and evolves, a web design studio can help you update and expand your website to meet your changing needs.

You'll have peace of mind knowing that your website is in good hands with ongoing support and maintenance. No more worrying about technical issues or downtime — a professional web design studio has got you covered.

Don't settle for a mediocre DIY website. Invest in a professional web design studio and watch your online success soar. Your audience — and your bottom line — will thank you.

Your website is often the first point of contact that potential customers have with your business. It's the place where they'll learn more about what you do, what you offer, and why they should choose you. For this reason, it's crucial that your website is well-designed and effectively communicates your brand and value proposition.

But what makes for good web design? Here are a few key elements:

A clear and concise message.

Your website should be the go-to source of information for potential customers who want to learn more about your business. This means that it's crucial that your website clearly communicates what your company does and what you offer.

To do this, it's important to avoid jargon or industry-specific language that may confuse the average visitor. Not everyone visiting your website will be familiar with your industry or the specific terminology you use. By using language that is easy to understand, you'll be more likely to communicate your message effectively to a broader audience.

It's also essential to focus on explaining the benefits of your products or services in terms that are easy to understand. For example, consider how your products or services can solve problems or improve your customers' lives rather than simply listing features. By highlighting the benefits of what you offer, you'll be more likely to engage visitors and encourage them to take action.

A visually appealing design.

First impressions are essential; your website is often the first point of contact potential customers have with your business. This means your website must have a visually appealing design that catches the eye and leaves a positive impression.

A well-designed website should be easy on the eyes and easy to navigate. This means using a clean, uncluttered layout that doesn't overwhelm the visitor with too much information. It also means choosing a suitable colour scheme that reflects your brand and is easy to look at for extended periods.

In addition to a clean layout and a suitable colour scheme, it's also crucial to use high-quality images and graphics to help tell your story and showcase your products or services. Poor-quality photos or graphics can distract from your message and make your website look unprofessional. You'll be able to engage visitors better and help them understand your business by using high-quality visuals.

Easy navigation.

One of the most important aspects of good web design is ensuring that your website is easy to navigate. Visitors should be able to find what they're looking for quickly and easily without having to dig through multiple pages or menus.

To achieve this, it's essential to have a logical structure to your website, with clear headings and subheadings that help visitors understand the hierarchy of the content. You should also consider using a navigation menu or other navigation elements, such as a search bar or a "breadcrumb" trail, to help visitors find their way around your site.

It's vital to use descriptive and relevant titles for your pages and content. This will help visitors understand what they can expect on each page and make it easier to find the information they're looking for.

Mobile friendliness.

With the proliferation of smartphones and tablets, it's more important than ever for websites to be accessible on mobile devices. Several recent studies found that over 50% of all internet traffic worldwide now comes from mobile devices. So, if your website isn't mobile-friendly, you could miss out on a significant portion of your potential audience.

A responsive design ensures that your website looks and functions well on any device, regardless of screen size or resolution. This is achieved through flexible layouts, images, and other elements that adjust automatically to fit the screen they're viewing on.

There are several benefits to having a mobile-friendly website:

• Improved user experience. A responsive design ensures visitors can easily access and use your website on their preferred device, leading to a better overall user experience. This is especially important given that studies have shown that users are more likely to purchase from a mobile-friendly website.
• Better search ranking. Google and other search engines favour mobile-friendly websites, so having a responsive design can help improve your search ranking. This is particularly important given that mobile searches now account for the majority of all searches globally.
• Increased traffic. Making sure your website is mobile-friendly will make you more likely to rank higher in search results and drive more organic traffic. This can be especially helpful for small businesses that rely on local search traffic.

A strong call to action.

Your website should encourage visitors to take the next step, whether filling out a form, making a purchase or contacting you for more information. A solid call to action (CTA) is an essential element of good web design, as it helps to guide visitors towards your desired outcome.

To create a compelling CTA, it's vital to use actionable language that clearly communicates what you want the visitor to do. For example, "Sign up for our newsletter" and "Buy now" are clear, actionable CTAs. It's also essential to make your CTAs prominent and easy to find so they can't be missed. You can use buttons, links, or other elements to draw attention to your CTAs and make them stand out.

It's necessary to consider their placement on your website. The best CTAs are placed in a logical and strategic location, such as near the end of a blog post or at the bottom of a sales page. This helps to increase the chances that visitors will take action.

‍

Good web design is essential because it helps to establish credibility, establish your brand, and convert visitors into customers. However, a poorly designed website can turn off potential customers, leading them to choose a competitor. On the other hand, a well-designed website can help to build trust, showcase your products or services, and drive conversions.

If you're designing a new website or updating an existing one, focus on these critical elements of good web design. By doing so, you'll be able to create a website that effectively communicates your brand and value proposition and helps you achieve your business goals.

In today's digital age, it's more important than ever for websites to be accessible on a wide range of devices, including phones, tablets, and laptops. This is where responsive design comes in.

Responsive design ensures that a website looks and functions well on any device, regardless of screen size or resolution. This is achieved through flexible layouts, images, and other elements that adjust automatically to fit the screen they're being viewed on. There are several reasons why responsive design is vital in the modern world:

It provides a better user experience.

With the proliferation of smartphones and tablets, a significant portion of your website's traffic will likely come from mobile devices. If your site isn't optimised for mobile, visitors may have difficulty navigating and using it, leading to a high bounce rate and low conversion rate. On the other hand, a responsive design ensures that users can easily access and use your site on their preferred device, leading to a better overall user experience. This is especially important given that studies have shown that users are more likely to purchase from a mobile-friendly website. A recent survey found that 88% of consumers said they were less likely to return to a website after having a bad mobile experience.

It helps with search engine optimisation (SEO).

Google and other search engines favour mobile-friendly websites, so having a responsive design can help improve your search ranking. This is particularly important given that mobile searches now account for the majority of all searches globally. So by ensuring your website is responsive, you'll be more likely to rank higher in search results and drive more organic traffic. In addition, having a responsive design can also help improve your local SEO, as Google now considers a website's mobile-friendliness when determining local search rankings.

It saves time and resources.

Rather than designing and maintaining separate mobile and desktop versions of your website, a responsive design allows you to create one site that works seamlessly on all devices. This saves time and effort and ensures a consistent user experience across all devices. In addition, having a responsive design means you only have to design and develop your website once, which can save money in the long run.

It's the future of web design.

As more and more people use mobile devices to access the internet, it's clear that responsive design is the way of the future. By embracing responsive design now, you'll be ahead of the curve and better prepared for the future of the web.

Responsive design is essential for any modern website that wants to provide a good user experience and be competitive in the digital landscape. If you're designing a new website or updating an existing one, make responsive design a top priority. By doing so, you'll be able to provide a better user experience for your visitors, improve your search ranking, save time and resources, and stay ahead of the curve in the world of web design.

When creating a website, it's important to remember that it's not just about making it look good — it's about designing a site that is functional, easy to use, and meets the needs of both your business and your target audience. Here at Smith-Cordell Design, we can assist you in creating a successful website that achieves all these goals. In the meantime, here are 10 tips to help you get started:

1. Clearly define your target audience.

Understanding whom you are designing for will help you create a website that resonates with them and meets their needs. Consider factors such as age, gender, location, and interests when identifying your target audience.

2. Establish a clear purpose for your website.

What do you want your website to achieve? This could be anything from generating leads to providing information about your products or services. Once you know the purpose of your website, you can design it in a way that helps you accomplish those goals.

3. Keep the user experience in mind.

Your website should be easy to navigate and use, with a logical layout and clear calls to action. Consider using tools like heatmaps and user testing to see how users interact with your site and identify any areas for improvement.

4. Make use of responsive design.

With more and more people accessing the internet on their phones, it's crucial that your website looks and functions well on mobile devices. Responsive design ensures that your site adjusts automatically to fit the screen size of the device it's being viewed on, providing a better user experience.

5. Use high-quality images and graphics.

Visual elements can help to engage visitors and make your website more visually appealing. Be sure to use relevant images for your business and choose graphics that are easy to read and understand.

6. Use white space effectively.

Don't overcrowd your website with too much content or too many elements — this can make it feel cluttered and confusing to visitors. Instead, use white space to create a clean and uncluttered design that allows the essential elements of your site to stand out.

7. Use clear and concise copy.

Keep your text short and to the point, and use headings and subheadings to break it up and make it easier to read. Consider hiring a professional copywriter to help create compelling content that resonates with your target audience.

8. Use strong calls to action.

Encourage visitors to take the next step, whether filling out a form, making a purchase or contacting you for more information. Use actionable language and make your calls to action prominent and easy to find.

9. Make it easy for visitors to contact you.

Include your contact information prominently on your website, and consider adding a contact form or chat feature to make it even easier for people to get in touch.

10. Test your website.

Before you launch your website, test it thoroughly to ensure that it's functioning correctly and providing a good user experience. This could include testing on different devices and browsers and getting feedback from friends and colleagues.

Designing a successful website requires a combination of aesthetics, functionality, and a focus on the needs of your target audience. By following these 10 tips and partnering with a professional web design agency like Smith-Cordell Design, you can create a website that effectively achieves your business goals and provides a positive user experience.