Web Design vs. Web Development: What to Actually Hire For

The textbook definitions, briefly

If you ask the internet what a web designer does, you get this answer: visual design, layout, typography, color, user experience, prototypes in Figma. If you ask what a web developer does, you get this: code, HTML/CSS/JavaScript, frameworks, databases, hosting, performance.

That separation is true in the same way that the separation between "person who designs cars" and "person who builds cars" is true. Both jobs exist. Both jobs are real. Neither one of them, by itself, gives you a car you can drive.

How the work actually shakes out

On a typical small-business or organizational website project, here is the work that needs to happen:

Decisions a designer normally owns

Brand and visual identity. Typography. Color palette. Layout system. Information architecture. The way each page reads. Hierarchy of headings, calls to action, photography style. The part of the site the visitor experiences as look and feel.

Decisions a developer normally owns

Platform choice (WordPress, headless, static, custom). Hosting and deployment. Database structure if there is one. Build pipelines. Performance budgets. Security headers. Backup and maintenance posture. The technical surface the visitor never sees but always feels.

Decisions that are both

This is the long list. Mobile responsive behavior. Accessibility. SEO. Schema markup. Form handling. Email integrations. Analytics tagging. Site speed. Image optimization. Content management workflow. Editorial admin design. Search behavior. Navigation interaction. Animation. Microcopy. Conversion design. The way the site behaves when it loads slowly, when JavaScript fails, when a user is on a screen reader, when an LLM crawls it.

That third category is enormous. It is also the category where most projects go wrong, because the designer assumes the developer will handle it and the developer assumes the designer thought about it. Things that fall in the gap include accessibility, SEO, content workflow, and, increasingly, AI integration.

Why hiring just one of them goes sideways

Two patterns I have watched go badly more times than I would like:

The designer-only project

You hire a great visual designer. They produce beautiful comps in Figma. The site looks like a magazine. Then someone has to build it, and now you are scrambling to find a developer who will translate Figma to code. The developer asks questions the designer did not think about: what happens at this breakpoint, what is the loading state, what schema does this content type use, how does the editor add a new entry. The site ships late and over budget because the design was made without engineering reality in the room.

The developer-only project

You hire a senior WordPress developer who can build anything. They build it. It works perfectly, accessibly, fast, secure. It looks like every other WordPress site that ever existed because it is using a starter theme and a stock font and the visual decisions were made in five minutes. The site does its job functionally and produces zero of the brand differentiation you were trying to achieve.

Both failure modes are common. Both produce sites that disappoint. Both are usually the result of the brief saying "we need a web designer" or "we need a web developer" instead of "we need a website that does these things."

What to actually hire for

The cleanest path is to hire someone (or a small team) who does both, where the design and engineering decisions are made by the same brain or by people who sit close enough together to make them in real time. That can look like:

• A solo practitioner who can design and build, common for sites under a certain scale.
• A studio or small agency with both disciplines under one roof, where the project lead handles the hand-off internally.
• An in-house team with a designer and a developer who have worked together long enough to know each other's instincts.

What you want to avoid is hiring two strangers from two different places to work in sequence. The handoff overhead is brutal, and the gaps between their assumptions are where projects go to die.

Questions to ask

Whatever the title on the contract, here are the questions that surface whether the work will land the whole site, not just half of it:

• Walk me through your discovery process. (Real practitioners have one. People who do not have a discovery process show you their portfolio instead.)
• How do you handle accessibility? (If the answer involves "we'll layer that on" or "we usually meet the basics," keep looking.)
• How do you think about SEO and the AI answer engines? (If they have not heard of AEO, that is a 2026 red flag.)
• Show me a project where the design and development were tightly coupled. (Not just a screenshot. The story.)
• What happens after launch? (Maintenance, performance monitoring, content workflow. The half of the site's life nobody talks about during the sales process.)

A note on titles

I describe my own practice as senior web design, WordPress development, and AI integration. The reason all three are in the title is that any one of them on its own does not describe what a website needs. I have been doing all three for the same clients for twenty-five years.

The honest version of "do I need a web designer or a web developer" is "you need someone who does both, plus a few other things, all at once." Hire for the outcome. The titles will sort themselves out.