If you’ve dealt with people who build websites before, you’ve probably noticed that some refer to themselves as web designers, others call themselves web developers, and some even claim to be both.
The terms often get used interchangeably, and in many ways are interchangeable because they’re both concerned with the production of a website – but there are differences, so let’s start with the clean answer.
Web designers work on what a website looks like, developers work on a website’s code
This is maybe too simplistic a way to describe the differences between the roles in the age of AI because nowadays designers are able to produce code, and developers are able to produce mockups, based on simple prompts.
But historically, in design agencies, this is how the work was divvied up:
Web designers create pictures of what a website should look like, and web developers use that picture as a reference to build the website itself.
In many ways, it’s still how most agencies work. Designers produce a file using Figma, InDesign, Sketch or even Photoshop – which shows the layout, typography, colours, buttons, and every other visual element, and then hands that file over to the developer, who turns that into a working website using code.
In a typical project, the design team never touches the actual website until the very end, where they review it and provide feedback. But the construction of the website asset itself, the thing your customers will actually use, is handled entirely by the web development team – from start to finish.
That’s a helpful distinction, but it hides quite a lot.
Why the word “design” causes so much confusion
Part of the problem is that “web design” means different things depending on who’s saying it.
When a business owner says “I need a web design agency,” they tend to mean the whole outcome – they want a website, and they don’t especially care how the work is divided internally.
A good agency will quietly assemble a copywriter, an SEO specialist, a designer and a developer to deliver it – collectively, those people design a website.
But when someone in the industry says “web designer”, they tend to mean a much narrower role: a graphic designer who specialises in websites. They handle the visual flow, spacing, font choices and hierarchy, button and link styles. Things like how the header and footer are laid out is often part of it too.
That’s a real craft, but it’s almost always done outside of the actual website.
Once it is approved, it gets packaged up into a file and then organised into a handover meeting where it’s explained to the developer, who builds the website component of the project.
The work that falls between the picture and the build
But when you spend much time inside an agency, you start to see certain tasks that have no specific owner. There’s a whole spectrum of work that isn’t purely visual, and isn’t “just code” either. Let’s look at some examples:
Semantic markup
Because the purpose of the web is as a document sharing platform, every web page (including this one) is drawn using HTML tags that represents information. For instance, this text is wrapped inside <p></p> tags, which represent paragraphs. The element just before this is a heading tag, specifically a third-level heading <h3>Semantic markup</h3>.
Everything you see on a web page is a tag, but who should decide which tag to use? A lot of people think that, because it’s code, it should be the coder’s responsibility. And often it ends up that way, because they’re the ones with the most knowledge of what it should be. But when we’re talking about text within an article, the responsibility of whether a certain piece of text should be a paragraph, list or heading (and what level heading it should be) is actually the content marketing or SEO team. They’re the ones that have to deal with the consequences of getting it wrong.
Other parts of the site have similar questions with different answers. Should this article content be wrapped inside a <main></main> or <section></section> or <div></div> tag?
The answer
That’s a trick question, because the answer is actually an <article></article> tag.
Interestingly, none of those choices above change how the page looks because we can style any element to look like anything. What changes is how the page is understood by browsers, by screen readers, by Google’s crawlers, and more recently by AI agents that summarise and cite web pages.
That decision is about meaning and hierarchy – a decision about information architecture that just happens to live entirely in code so it gets filed under development and never appears in a design file.
ARIA and technical accessibility
ARIA attributes are the clearest example of the overlap. They tell assistive technology what an element is and what state it’s in — that this button is expanded, that this region is a live area, that this control labels that field.
They are almost exclusively implemented by developers. Most web designers don’t know they exist, and that’s not really their fault — it’s a tooling and training gap. Their deliverable is a static file, so their involvement ends where the code begins.
But ARIA is a design decision. It determines whether a portion of your audience can comprehend and operate your website at all. That’s not a technical detail bolted on at the end. That’s the design of the experience.
Technical SEO
The same applies to structured data, heading structure, internal linking, and the rest of the technical SEO layer. It’s usually framed as a marketing concern, it’s almost always implemented by a developer, and it’s fundamentally about how your site represents itself and what it communicates.
If design is about how something works and what it means, then all three of these are design. They’re just invisible.
Where the visual-only approach falls down
I’ll be blunt, because I think it needs saying – most websites are designed as though they are purely aesthetic objects.
Here’s some design choices I’ve seen made repeatedly:
- Colour combinations get chosen because they look good in the mockup, without ever going through a contrast checker
- Interactive elements get designed with no consideration of keyboard focus or how they’ll behave for someone who can’t use a mouse
- Text gets set at sizes that look elegant on a designer’s monitor and nowhere else
- Content that is genuinely difficult to read on a phone in daylight
When things like this happens, the person who often catches it is usually a developer who happens to care about accessibility – they either send the design back, refuse to build it as specified, or quietly fix it and have the conversation afterwards.
This is a strange arrangement: the developer constantly making design decisions (and arguably better ones for the end user) because the design process didn’t account for who was going to use the result.
I’m not taking shots at individual designers – I am naming the practice that I have seen happen many times over the past decade-plus as an agency developer.
When designers treat their websites as purely visual artefacts, it’s an incomplete understanding of what it is for.
Good design has never been only about how a site looks – but it is what wins awards, prestige, promotions and job offers, so that ends up being the focus.
What great visual design genuinely brings
That said, a skilled visual designer brings a holistic consistency that is very hard to fake – every spacing decision, type choice, and component state that belongs to the same visual system, making the whole feels considered rather than assembled. That coherence is the difference between a site that looks professional and a site that looks like a filled-in template.
Designers also bring creative application of a brand – given a set of brand guidelines, a good designer will find expressions of that brand in a website that developers would never think of.
That’s a genuine, non-trivial skill, and there are projects where it’s exactly what’s needed.
But business websites are not art pieces; they are marketing engines built to attract visitors and convert them into customers.
The words are part of the design
There’s another direction the overlap runs, and it’s the one that causes the most avoidable damage.
Web design and web copy can’t really be separated, but they’re routinely produced by different people at different times. Designers tend to create sections using either dummy text or something short and poetic, tuned precisely to fit across two lines at a specific size – built to look fantastic, but only for those exact words.
Then when, weeks or months later, the business owner or marketer finally gets time to “do the website copy”, they find that the actual copy they need to add doesn’t look right – it’s either too cluttered or too empty – and so naturally, they ask the design agency for assistance.
It looks bad because you wrote too much – it can’t be any longer than six or seven words
Your web designer, probably
In this situation, the business owner is stuck – redesigning the sections around the words that describe their customer’s actual goals brings with it a dreaded scope change, which requires another meeting, another quote, and yet another delay.
In my experience, most web design work doesn’t spend much time on copy, or on establishing what the client actually wants to rank for – that’s treated as an SEO agency’s job, arriving later. But if you don’t know what the page needs to say before you start, you’re designing a container for content that could drastically differ from expectations.
When beautiful websites don’t work
Business owners who’ve been burned usually describe the same thing: they paid for a site that looked great and didn’t produce anything.
From what I see when handed those sites to rebuild, the pattern is fairly consistent:
- There’s no topical authority – nothing on the site establishes that this business knows its field better than the alternatives
- There’s no real thinking about how a visitor becomes an enquiry
- There’s a blog full of filler, written because someone said every site needs a blog, with no direction behind any of it
- There’s enquiry forms that are either too demanding, or so bare that there’s no reason to believe filling one out leads to anything other than a sales call
None of that is visible in a website mockup – when the site looks finished, everyone assumes it is firing on all cylinders.
That being said, many of those businesses are doing perfectly well – their reputation, word of mouth referrals and Google Business Profile are doing most of the work. Plenty of cafés and restaurants don’t even have a website and don’t need one – they just need to appear when someone searches fish and chips near me, which is a different problem entirely.
If a business is succeeding despite its website rather than because of it, that’s worth knowing before spending any money.
Based in Perth, Western Australia. If you’d like a second opinion on a site that looks fine but isn’t performing, get in touch.