What Is Web Design (and What Isn't It)? A Complete Guide

What is web design?
Web design is the discipline of planning how a website looks, how it works and which step it leads each visitor to take. It covers layout, typography, colour, content hierarchy, navigation and interaction. Its goal is not a pretty picture. Its goal is an easy experience that serves a clear business objective.
In this guide I draw the borders of the field based on what I have seen in client projects since 2012. I explain how web design differs from web development, UI and UX design and graphic design. I also list the most common myths and the main project types. Every section links to a deeper article, so you can use this page as a map.
Keep one idea in mind as you read. Good web design answers the question in the visitor's head by the shortest route. Colours, photos and motion support that answer; however, they can never replace it.
What web design is not
Web design is not simply "a site that looks nice". In first meetings, the request I hear most often is "make it look as sleek as our competitor's". Yet sleekness alone does not sell. If visitors cannot find what they came for, even the most elegant page stays an empty shop window.
It is also not a one-off job, because business never stands still. Your products, services and market keep changing after launch day. Therefore you need to plan for design updates driven by measurement. The list below separates web design from the tasks people often confuse it with:
- Choosing a logo and colours: that belongs to brand identity, not the whole site.
- Installing a ready-made theme: that gives you a starting point, not design decisions.
- Writing code: that is development; design decides what the code should do.
- Producing photos and banners: that is graphic production, not page structure.
- A single delivery: a site needs care and improvement after it goes live.
I also meet another belief again and again: "design is a matter of taste." In reality, taste affects only a small share of the decisions. Arguing about button colours wastes time. Instead, talk about which question brings visitors in and at which step they give up. Those questions are measurable, while taste changes from person to person.
Once you draw these lines early, you read proposals more accurately. You also know exactly what to expect from each person on your team.
What is the difference between web design and web development?
Web design defines what a site should do and how it should look; web development turns that definition into working code. A designer prepares page templates, components and interaction rules. A developer then builds those decisions with HTML, CSS, JavaScript and server-side software. The two roles depend on each other, but they require different skills.
| Topic | Web design | Web development |
|---|---|---|
| Core question | What should visitors see and do? | How does it work and stay secure? |
| Output | Sitemap, wireframes, interface files, component library | Code, database, integrations, server setup |
| Tools | Figma, prototyping tools, user tests | Code editor, CMS, version control, staging |
| Success measure | Clarity, conversion, brand consistency | Speed, stability, security, maintainability |
| Typical failure | Nobody understands what the button does | The button does nothing when clicked |
The most expensive problem I see is two roles working in isolation. The designer draws screens without knowing the technical limits. Then the developer fills the gaps with personal guesses. The result is a page that neither the designer nor the client wanted. For that reason, I keep both sides in a short weekly call.
On small projects one person can handle both jobs. On larger corporate builds, however, separating them makes ownership clear. For example, when a form breaks, you can quickly tell whether a design decision or the code caused it.
Where do UI and UX design fit into web design?
UX (user experience) design shapes the journey from the reason a visitor arrives to the moment they reach their goal. UI (user interface) design shapes how each step of that journey appears on screen: buttons, form fields, type, spacing and colour. In other words, UX asks which steps should exist, and UI asks how those steps should look.
Web design is the umbrella over both. Moreover, a good UX decision can fail because of weak UI. You might place the quote form on exactly the right page. Still, if the submit button blends into the background, visitors will not notice it. In my experience, projects where these two layers drift apart almost always convert below expectations.
I cover typical interface mistakes and their effect on revenue in my article on UX mistakes that kill sales. If you plan to hire an agency, this UI/UX design services checklist gives you the right questions to ask.
In practice it also helps to document UX decisions. If you draw the user journey as a simple flow chart, everyone on the team sees the same picture. For instance, a three-step flow such as "service page, case study, quote form" makes the discussion concrete. After that, the UI designer creates a screen for each step, and missing steps become obvious.
Is graphic design the same as web design?
No. Graphic design creates visual communication for a fixed surface: a poster, a brochure, packaging or a social media post. Web design works in a medium where screen sizes change, people click and scroll, and every file takes time to load. A graphic designer's visual instinct is valuable; on its own, though, it is not enough.
The difference shows up in three places. First, the browser reflows the page at different widths, so you design for a range rather than a single size. Second, every image adds page weight and affects speed. Third, both people and search engines read the text. That is why you should never bury important copy inside an image.
These differences become sharper when you move a printed identity onto screens. I explain what to keep and what to adapt in my guide to taking a print brand identity digital. If you need to build the identity itself, take a look at my brand identity service.
What are the stages of a web design process?
A web design process starts with discovery and continues with measurement after launch. Teams name the stages differently, but the logic stays the same. This is the order I follow in my own projects:
- Discovery: you learn the business goal, the audience and the competitors.
- Sitemap: you decide which pages exist and how they link together.
- Wireframes: you lay out each page with plain grey boxes.
- Visual design: you define type, colour, components and imagery.
- Prototype and testing: you put a clickable draft in front of real users or your team.
- Development: you turn the design into code, CMS templates and integrations.
- Pre-launch checks and launch: you verify forms, speed, SEO tags and tracking.
- Measurement and improvement: you update pages based on real data.
The step teams skip most often is discovery. Yet every design decision you make without knowing the audience is a guess. So I recommend finishing a target audience analysis before any screen exists. If you want the tooling side of the interface stage, my Figma walkthrough explains it step by step.
What are the main types of web design projects?
The most practical way to group projects is by what the site has to achieve. Each type needs a different page structure, content depth and success metric. These are the types I meet most often:
- Corporate website: presents the company, services and references; the goal is usually a quote request or a call.
- E-commerce store: centres on product listings, filters, the cart and checkout.
- Landing page: drives one campaign or service towards a single action.
- Content site or blog: puts readability, search visibility and subscriptions first.
- Portal or web app: serves logged-in users with dashboards, reports and forms.
- Personal or portfolio site: showcases the work of one person or studio.
Industry also shapes the type. A manufacturer, for example, needs dealer pages, export information and technical documents. I discuss those needs in my article on websites for manufacturers. So answer "which type" together with "what is the main job of this site".
My personal observation is simple. Choosing the wrong type hurts more than executing the design poorly. A business that sells one service does not need fifteen corporate pages. On the other hand, squeezing a wide product range onto a single page buries information. Write down the visitor's first question before you pick a type.
Should you choose a ready-made theme or a custom design?
The answer depends on your budget, your timeline and how much you need to stand out. A theme launches quickly and costs little. However, its authors built it to suit as many buyers as possible, not you. As a result, it often loads features you will never use.
A custom design starts from your content and your goals. You shape the page structure around your sales process, and you avoid carrying unused code. On the other hand, it takes more time and money. It also needs a proper discovery stage, because the brief shapes everything. A custom build that skips discovery ends up no better than an expensive theme.
Here is the path I usually suggest. If the business is new and the message is still settling, start with a lean theme. Once the site becomes a main sales channel, or you need to stand apart from competitors, moving to a custom design usually pays off. In both cases, judge the option on speed and ease of maintenance as well.
Whichever route you take, ask about licences and updates. Most paid themes come with a yearly update licence; once it lapses, you may stop receiving security patches. With a custom build you own the code, but you still need someone to maintain it. In short, neither option works without a maintenance plan.
Why are responsive and mobile-first design basic requirements?
Because a large share of your visitors arrive on phones, and Google mainly uses the mobile version of a site for indexing. With a mobile-first design approach, you make decisions for the small screen first and then expand to larger ones. That way you remove unnecessary elements from the start.
Responsive design means the same page rearranges cleanly at every screen width. Still, "it fits" is not enough. Tap targets need enough size, people should complete forms with one hand, and a phone number should start a call with one tap. A three-column layout that looks great on desktop can turn into a long, tiring scroll on a phone.
Google explains the details of mobile-first indexing in its Search Central documentation. To check your own site, follow my mobile-friendly test guide.
What are the most common web design myths?
Over the years I have watched the same beliefs slow projects down again and again. Knowing them in advance protects both your budget and your schedule. These are the ones I hear most:
- "Design first, content later." Pages designed without real content break once the copy arrives.
- "More animation means more modern." Excess motion slows the page and scatters attention.
- "The home page must say everything." Many visitors land on inner pages first.
- "Let's put five campaigns in the slider." Most visitors never reach the second or third slide.
- "We'll handle SEO after launch." You decide page structure and URLs during design.
- "A site lasts for years once it's built." Markets change, so your site must change with them.
Each item is here because I have seen it hit a client's budget directly. When content comes last, for instance, the design files almost always need a second round. That stretches both the timeline and the cost.
These myths share one root. Teams decide based on internal preferences rather than visitor needs. In meetings, every department wants its own section on the home page. Visitors, however, do not care about your org chart; they want a solution to their problem. So ask "which visitor question does this element answer?" in every debate.
How can you tell good web design from bad?
You can tell good web design by whether visitors answer three questions within seconds. The questions are simple: what is this, what is in it for me, and what should I do now? If the top of the screen does not answer them clearly, the page is not doing its job, however strong the colour palette looks.
You can also run a few concrete checks. First, is there one clear primary call to action? These CTA button examples give you a good reference. Second, did you break the text into short paragraphs with meaningful subheadings? Third, does the form ask only for the fields you truly need?
Finally, check whether the design ties to a goal at all. If nobody built the site around a measurable target, such as a quote request, a call or a purchase, nobody can say whether it works. I explain goal setting in my guide to website conversion goals. I cover the link between design and results in my article on conversion-focused design.
Is accessibility part of design?
Yes. Accessibility is not a feature you bolt on later; it is a core layer of design. People with visual, hearing, motor or cognitive differences need to use your site too. The international reference is the W3C WCAG 2.2 guidelines, which define three conformance levels: A, AA and AAA.
A handful of design decisions solves a large part of the problem. First, leave enough contrast between text and background. Second, never carry information through colour alone; add text or an icon. Every form field also needs a visible label. Finally, keep the focus indicator visible for keyboard users. When you pick colours, my HTML colour codes tool can help.
Moreover, an accessible site feels easier for everyone. Someone reading a phone in bright sunlight benefits from high contrast. Someone holding a coffee benefits from large tap targets. In short, accessibility is not a favour for a small group; it raises overall quality.
You do not need expensive tools to start testing. First, try to navigate your site with the keyboard alone. Can you reach every link and form field with the Tab key? Then zoom the page and see whether text overflows. These two simple tests reveal many of the problems I find in audits.
Is site speed a design decision?
Largely, yes. Every large image, background video, extra font and scroll effect you add to a page increases loading time. So instead of leaving speed to the developer, treat it as a budget during design.
Google uses three metrics called Core Web Vitals to measure user experience. According to web.dev, the "good" thresholds are 2.5 seconds for Largest Contentful Paint (LCP), 200 milliseconds for Interaction to Next Paint (INP) and 0.1 for Cumulative Layout Shift (CLS). CLS in particular depends on design. Images without set dimensions and banners that appear late push content around.
In practice I recommend three habits. Compress images before upload; my image resizer makes that easy. Limit yourself to two font families. Then test the page with Google Lighthouse. I explain how speed affects rankings in my article on site speed and SEO.
One warning, though. A high lab score does not guarantee that real users get a fast experience. Specifically, old phones and weak mobile connections change the picture. For that reason, also watch real user data in Search Console after launch.
How do SEO and web design work together?
SEO and web design are two faces of the same foundation. The page structure, URLs, heading hierarchy and internal links you choose during design shape how search engines understand the site. Leaving SEO until after launch is like planning the plumbing after you pour the concrete.
Designers should know a few basics. For example, each page needs one main heading. Important copy belongs in real text, not inside images. The menu should consist of links that search engines can follow. Google's SEO Starter Guide summarises these basics officially.
That said, UX and SEO sometimes seem to pull in opposite directions. The designer wants a clean page, while the SEO specialist wants more text. I explain how to settle this in my article on balancing UX and SEO. If you are redesigning an existing site, read my guide to protecting SEO during a redesign before you start.
Should content come before design?
Whenever possible, yes. Design is a container for content. If you size the container before you know the content, it either overflows or looks empty. That is why I ask for real draft copy for at least the home page, service pages and contact page before design starts.
Designs built on placeholder text such as "lorem ipsum" look flawless in the first presentation. Then the real headline wraps onto two lines, a service description runs longer than planned, or client testimonials never arrive. In that case the layout falls apart. As a result, the design goes into a second round and the schedule slips.
Planning content first also helps SEO. You decide in advance which page answers which search intent. I walk through that matching process in my keyword mapping guide. When you write the copy, my guide to SEO-friendly content will help.
I also suggest giving clients a content template. For each service page, four questions work well: whose problem does it solve, how does it solve it, what proof do you have, and what is the next step? This removes blank-page fear. The copy then arrives in the same structure, and the design team keeps moving.
Does the work end when the site goes live?
No. The real learning starts after launch. Every design decision is an assumption, and real visitor data either confirms or rejects it. So treat launch day as the start of a measurement period, not a finish line.
In the first weeks I look for answers to a few questions. Which pages do visitors enter on? Where do they leave? Do people start the form and abandon it? Does any element misbehave on mobile? To get these answers, you need tracking in place before launch. To separate campaign traffic, tag your links with my UTM builder.
Next, you make small, measurable improvements. You might sharpen a headline, shorten a form or move a trust signal higher. You also follow search performance in Google Search Console. That way the site matures together with your market.
I follow one rule during this phase. Change one thing at a time and watch the result for at least a few weeks. If you change the headline, the form and the image on the same day, you will never know which change mattered. Also log each change with its date in a simple sheet.
Who does what in a web design project?
The split depends on project size, but the functions stay the same. On a small project one person covers several roles. On a corporate project each role calls for its own specialist. In practice, these are the core roles:
- Project manager: runs the schedule, scope and communication.
- UX designer: prepares the user journey, sitemap and wireframes.
- UI designer: creates the visual language, components and screens.
- Content writer: writes page copy, headings and microcopy.
- Developer: turns the design into code, CMS templates and integrations.
- SEO and analytics specialist: checks URL structure, tags and tracking setup.
The client side also needs a decision maker. In my experience, the projects that stall longest are those where nobody on the client side owns approvals. So agree in writing, at the very start, who has the final word on your side.
What should you look for when hiring for web design?
Look at the process before the portfolio. After all, everyone has beautiful screenshots. The real difference appears in the questions a studio or freelancer asks to understand your business. A proposal without a discovery stage will most likely adapt an existing template to you.
Also clarify ownership. Whose name will hold the domain, the hosting account, the design files and the admin panel? When the project ends, you should hold every one of those accesses. In addition, check whether the proposal states post-launch maintenance, security updates and a support period in writing.
Finally, ask whether measurement and SEO sit inside the scope. Many proposals promise an "SEO-friendly" site without saying what that covers. In my own web design service, I handle discovery, content planning, technical SEO foundations and tracking in one process. Whichever route you choose, ask every bidder the same questions so you can compare them fairly.
When you compare proposals, look beyond the total price. Ask for a line-by-line scope: how many pages, how many revision rounds, who enters content, whether the offer includes training and how many months of support follow launch. Apply the same list to every bid. Then you will quickly spot that a cheap offer often covers a narrower scope.
How should you think about web design?
In short, web design is more than a digital shop window; it is part of your sales process. Look, function, content, speed, accessibility and measurement are not separate line items. They are layers of the same experience, and neglecting one weakens the others.
Use this guide as a starting map. Follow the link for whichever topic you want to explore further; the articles on mobile design, conversion, UX mistakes and SEO protection go into detail. If you want a concrete roadmap for your own project, you can reach me through my contact page.




