Hiring a Web Designer: Questions to Ask, Red Flags & What to Check

A web designer can show you an attractive homepage within minutes. That does not tell you whether they can plan a useful site, protect your search visibility, manage technical requirements, or deliver what your business actually needs.

The right hiring process looks beyond visual style. You need to understand how the designer thinks, what work is included, who owns the finished website, and what happens after launch.

This guide gives you practical questions to ask a web designer, a method for reviewing portfolios, common warning signs, and the contract terms worth checking before you pay a deposit.

Key Takeaways

• Define your business goals, required features, budget, and approval process before requesting proposals.
• Ask how the designer handles strategy, content, mobile layouts, accessibility, performance, search engine optimization, and post-launch support.
• Review live websites, not screenshots alone, and test them on both desktop and mobile devices.
• Treat vague pricing, unclear ownership, unrealistic promises, and pressure to pay in full as warning signs.
• Make sure the contract defines the scope, deliverables, revision limits, payment schedule, ownership, and launch responsibilities.

Prepare Before Interviewing Web Designers

A designer cannot give you a useful recommendation when the project is described as “I need a better website.” Before contacting anyone, write a short project brief explaining what the website must accomplish.

Start with the business outcome. You might need more qualified inquiries, online appointment booking, eCommerce sales, membership registration, or a clearer way to present several services. These goals affect the site structure, platform, content, integrations, and budget.

Your brief should cover:

• The main purpose of the website and the actions visitors should take.
• The pages, products, services, or locations the site must include.
• Required functions, such as booking, payments, gated content, forms, calculators, or customer accounts.
• Existing materials, including copy, photography, branding, videos, and product data.
• Websites you like, along with specific reasons you like them.
• Your preferred launch window and any fixed business deadlines.
• The people responsible for feedback and final approval.

Also list the problems with your current site. “It looks old” is less useful than “mobile visitors struggle to find the quote form” or “staff cannot update service pages without calling a developer.”

If you already have a website, work through a structured website redesign checklist before requesting quotes. It will help you identify content, search, performance, accessibility, and technical issues that should be addressed during the project rather than discovered after launch.

Separate essential requirements from preferences

Divide your requirements into three groups:

Priority	Meaning	Example
Required	The site cannot launch without it	Online booking connected to the existing scheduling system
Important	It strongly affects the project’s value	Staff can edit services without touching code
Optional	Useful if the budget allows	Custom animation on the homepage

This prevents decorative preferences from taking priority over features that support sales or operations. It also gives designers room to recommend a simpler approach when an optional feature would add unnecessary cost or maintenance.

For example, a landscaping company might request a custom project-filtering system because it saw one on another site. A well-organized portfolio with service and location categories may solve the same problem with less development work.

Questions to Ask a Web Designer

The best questions reveal the designer’s process, judgment, and ability to explain tradeoffs. You are not testing whether they know technical vocabulary. You are checking whether they can connect design decisions to your customers and business goals.

1. What do you need to learn before recommending a design?

A strong designer should ask about your audience, services, competitors, sales process, current website data, and internal workflow. Be cautious if the conversation moves directly to colors, templates, or payment without discussing why the website exists.

The discovery process may include stakeholder interviews, analytics review, competitor research, content inventory, customer questions, and technical inspection. The exact method can vary, but there should be a clear learning stage before visual design begins.

2. Who will actually work on my project?

The person leading the sales call may not design or build the website. Ask who will handle strategy, design, development, content, search requirements, testing, and project management.

You should know:

• Whether the work is completed in-house or subcontracted.
• Who your main contact will be.
• How often you will receive updates.
• Who makes technical decisions.
• Who is responsible for final quality checks.

Outsourcing is not automatically a problem. The concern is whether responsibilities are disclosed and managed properly.

3. Have you worked on businesses with similar needs?

Industry experience can help, but it should not be the only deciding factor. A designer who has built booking sites, multi-location service websites, or large product catalogs may be more relevant than someone who has worked in your industry but only built simple brochure sites.

Ask what made those projects difficult. Listen for specific answers involving content, integrations, customer behavior, approvals, migrations, or technical constraints.

You can also review detailed web design and SEO case studies to see whether a provider explains the original problem, the work completed, and the outcome rather than showing a gallery of finished pages.

4. How will you plan the site structure and customer journey?

A website needs more than a homepage and several service pages. The designer should explain how visitors will move from an entry page to the information and action they need.

For a local service business, that journey might be:

1. A visitor lands on a service page from Google.
2. The page confirms the service, location, and problem addressed.
3. Proof elements answer trust questions.
4. Pricing or process information reduces uncertainty.
5. A short form or phone link provides the next step.

Ask whether the project includes a sitemap, wireframes, content hierarchy, and calls to action. These planning documents allow you to fix structural problems before time is spent polishing visual details.

5. Is the design custom, template-based, or a combination?

There is nothing inherently wrong with a well-chosen theme or design framework. It can reduce cost and development time. The problem arises when a provider sells minor template edits as fully custom work.

Ask which parts are prebuilt and which will be designed for your business. Request an explanation of any theme, page builder, plugin, or proprietary framework that will be used.

A small professional services firm may not need a completely custom system. An eCommerce company with unusual product rules, subscriptions, or account functions may require considerably more custom development.

6. How do you design for mobile users?

Do not accept “the site will be responsive” as a complete answer. Ask how navigation, forms, tables, calls to action, images, and interactive elements will change on smaller screens.

Google recommends responsive web design because it is generally the easiest mobile configuration to implement and maintain, according to its mobile-first indexing guidance. Your designer should test real page layouts at several screen widths rather than merely checking whether the desktop layout shrinks.

Ask to see the mobile version during the design stage. Waiting until development is complete makes mobile problems more expensive to correct.

7. How do you address accessibility?

Accessibility should be considered while planning components, colors, navigation, forms, and content. It should not be treated as a plugin installed just before launch.

Ask whether the designer considers:

• Text and background contrast.
• Keyboard navigation.
• Visible focus states.
• Form labels and error messages.
• Heading structure.
• Alternative text requirements.
• Captions or transcripts for media.
• Controls that do not rely only on color or motion.

The Web Content Accessibility Guidelines overview explains the shared international standard for accessible web content. A designer does not need to promise legal compliance in every jurisdiction, but they should be able to explain the accessibility standard used and how the site will be tested.

8. What web designer skills does this project require?

Visual design is only one part of many business website projects. Depending on your requirements, the work may call for user experience planning, responsive development, content architecture, accessibility, technical search knowledge, conversion planning, analytics, and integration experience.

Ask the designer which capabilities they provide directly and which require another specialist. For a WordPress project, you may need expertise in theme development, plugin selection, user roles, backups, staging environments, security, and content editing.

For more complex WordPress requirements, compare the designer’s capabilities with the work normally provided by a WordPress development team. This can help you distinguish a visual page-building service from a project that includes deeper technical development.

9. How will you protect our existing SEO?

A redesign can affect URLs, internal links, metadata, page content, structured data, mobile rendering, and loading performance. If the current website receives organic traffic, the designer should have a migration plan.

Ask whether the project includes:

• A crawl of the current website.
• A record of existing URLs and their performance.
• A redirect map for changed or removed URLs.
• Preservation of important page content and metadata.
• Checks for broken internal links.
• Review of indexing controls and canonical tags.
• Google Search Console monitoring after launch.

Do not assume a visually improved site will automatically perform better in search. Removing useful copy, consolidating pages without redirects, or changing URL paths carelessly can cause traffic loss.

10. How will you test speed and performance?

Ask which templates will be tested and which tools will be used. Testing only the homepage can miss problems on product pages, service pages, blog templates, and pages with forms or third-party scripts.

Google’s Core Web Vitals guidance focuses on loading performance, responsiveness, and visual stability. A practical testing plan should also review image sizes, font loading, scripts, video embeds, plugin weight, caching, and hosting limitations.

Request a record of test results before launch. Performance expectations should be realistic because analytics tools, booking systems, advertising scripts, and other third-party services may affect the final results.

11. What content is included?

Clarify whether the designer will write, edit, migrate, or format your content. Many proposals cover layout design but assume the client will provide finished text and images by a specific date.

Ask who is responsible for:

• Page copy and calls to action.
• Search intent and keyword research.
• Image selection, licensing, and editing.
• Product descriptions.
• Staff biographies.
• Case studies and testimonials.
• Privacy, accessibility, and policy pages.
• Content entry and formatting.

Content delays are a common reason website projects stall. Agree on responsibilities and deadlines before design begins.

12. What will our team be able to edit?

Ask the designer to show how an employee would change text, replace an image, publish an article, update a staff profile, or add a service.

A content management system should not give every user unrestricted access to critical templates and settings. Discuss reusable page sections, user permissions, documentation, and training.

Also ask whether editing ordinary content could break the layout. A website that looks polished but requires a developer for every small change may create avoidable costs.

13. What happens after launch?

Launch is the beginning of the website’s operational life. Software updates, form delivery, backups, security monitoring, analytics, content changes, and browser updates continue after the project ends.

Ask whether there is a warranty period for defects and how support requests are handled. Clarify what counts as a bug, what counts as a new request, and how additional work is priced.

When a business lacks an internal technical team, ongoing website maintenance services may need to be planned as part of the project rather than purchased after the first problem appears.

14. Can you explain the full cost and payment schedule?

Request an itemized proposal. It should identify the work included, optional costs, recurring fees, third-party licenses, hosting charges, and the rate for out-of-scope work.

Ask what could cause the price to change. Common examples include additional page templates, delayed content, new integrations, extra revision rounds, data cleanup, and requirements discovered after work begins.

A clear designer will not know every possible cost at the first meeting. They should, however, explain assumptions and describe how changes will be approved.

How to Evaluate a Web Design Portfolio

A portfolio shows what a designer wants you to see. Your job is to examine the work beyond the curated screenshot.

Select three to five relevant projects and open the live websites. Do not judge only by whether you like the color palette. Look for evidence that the site serves its audience and business purpose.

Use a consistent portfolio review process

For each project, complete these checks:

1. Open the homepage on desktop and mobile. Check whether the main offer and next step are immediately understandable.
2. Review an interior page. Service, product, article, and contact pages often reveal more than the homepage.
3. Test navigation and forms. Look for confusing labels, unnecessary fields, broken controls, or dead ends.
4. Read the content. Check whether it is specific to the business or filled with generic statements.
5. Inspect consistency. Buttons, spacing, headings, cards, forms, and imagery should follow a recognizable system.
6. Consider accessibility. Test keyboard navigation, visible focus, text contrast, and basic form labeling.
7. Ask what the designer personally completed. The project may have involved another agency, developer, writer, or branding team.

Record your findings instead of relying on an overall impression.

Portfolio question	Strong evidence	Weak evidence
Does the site fit the business?	Layout and content reflect the audience and buying process	The same structure appears across unrelated clients
Is the work easy to use?	Clear navigation, readable pages, and simple forms	Decorative effects compete with basic tasks
Does it work on mobile?	Content order and controls adapt thoughtfully	Desktop sections merely stack into a long page
Is the project explained?	The designer describes the problem, decisions, and responsibilities	Only screenshots and praise are shown
Is there proof of outcomes?	Verified client feedback or documented results	Unsupported claims about traffic or sales
Is the work current?	Recent live projects work correctly	Several portfolio links are broken or heavily outdated

Ask for context behind each project

A good portfolio discussion should explain constraints. Perhaps the client supplied the branding, required a particular platform, had a limited launch window, or declined a recommended feature.

This context helps you evaluate judgment rather than assigning all credit or blame to the designer. It also reveals whether they can discuss limitations honestly.

For example, a designer may show a polished restaurant website with online ordering. Ask whether they planned the ordering flow, integrated an existing service, or only styled a page that links to another platform. Those are different levels of work.

Do not expect every project to share your taste

A capable designer adapts to different audiences. A law firm, children’s activity center, software company, and luxury retailer should not all look identical.

Consistency in quality is more important than consistency in style. Look for clear hierarchy, appropriate typography, usable navigation, thoughtful mobile behavior, and design choices that suit each business.

Red Flags When Hiring a Web Designer

Some problems become visible before the contract is signed. Others appear when you ask for details and receive vague or defensive answers.

One isolated concern may have a reasonable explanation. Several concerns together suggest that the project carries more risk than the proposal admits.

Promises of guaranteed rankings or sales

A designer can improve page structure, speed, usability, content presentation, and technical foundations. They cannot guarantee a specific Google position or revenue outcome.

Search performance depends on competition, content, authority, technical health, and many factors outside a designer’s control. Conversion results also depend on your offer, pricing, traffic quality, reputation, and follow-up process.

A portfolio made entirely of mockups

Concept designs can show visual ability, but they do not prove that the designer can deliver a functioning website. Ask for live work and clarify which parts they completed.

A portfolio full of desktop homepages may hide weak mobile layouts, poor internal pages, unfinished development, or a lack of real client experience.

No discovery process

A provider who quotes immediately without asking about goals, content, users, integrations, and current systems may be selling a predetermined package rather than planning the right website.

Fixed packages can still work for straightforward projects. The concern is whether the provider checks that the package fits before recommending it.

Vague deliverables

Terms such as “modern website,” “SEO-ready,” and “mobile-friendly” are not sufficient contract deliverables. Ask what pages, templates, functions, tests, and services those phrases include.

For example, “basic SEO” could mean editable title fields, or it could include keyword research, redirects, metadata, internal linking, structured data, and Search Console setup. Those are not equivalent.

Unclear ownership or restricted access

You should understand who owns the design files, written content, custom code, domain, hosting account, analytics property, and third-party licenses.

Be cautious if the designer insists on registering critical accounts under their own name without giving you administrative access. Changing providers later may become difficult.

Full payment required before work begins

A deposit is common because the designer reserves time and begins planning. Requiring the entire fee before any defined milestone places most of the risk on the client.

A staged schedule tied to discovery, design approval, development, testing, and launch gives both parties clearer responsibilities.

No process for revisions or scope changes

“Unlimited revisions” may sound generous, but it often hides an undefined process. A better agreement states what is reviewed, how many revision rounds are included, who can request changes, and what happens when the approved scope changes.

Without these rules, feedback can continue indefinitely or produce unexpected invoices.

Poor communication during the sales process

Delayed replies, missed meetings, contradictory answers, and disorganized proposals can preview the project experience.

The designer does not need to answer every message immediately. They should set expectations, document decisions, and communicate in a way your team can follow.

Dependence on undocumented proprietary systems

Some agencies use their own platforms or frameworks. Ask what happens if you stop working with them.

Find out whether the website can be transferred, what data can be exported, which features will stop working, and whether another qualified provider can maintain it.

Web Design Contract Essentials

A web design contract should turn the proposal into specific obligations. It protects both parties by defining what will be delivered, when decisions are due, and how changes are handled.

Contract requirements vary by project and jurisdiction. Have a qualified attorney review the agreement when the budget, intellectual property, privacy obligations, or business risk justifies it.

Scope and deliverables

The contract should list the pages, templates, functions, integrations, content responsibilities, and technical services included.

Avoid relying on a proposal that says only “ten-page website.” Ten unique page designs require more work than ten pages built from two reusable templates. The agreement should distinguish pages, templates, and content entry.

Project stages and timeline

The schedule should identify major stages, such as discovery, sitemap approval, wireframes, visual design, development, content entry, testing, and launch.

It should also explain how client delays affect the timeline. A designer cannot finish a project when required copy, product data, credentials, or approvals arrive weeks late.

Feedback and revision limits

Define how many revision rounds are included at each stage. State how feedback must be submitted and who has authority to approve it.

Consolidated feedback is usually more efficient than separate comments from several stakeholders. Assign one person to gather internal input before sending it to the designer.

Payment terms

The agreement should show the deposit, milestone payments, final payment, due dates, accepted payment methods, and consequences of overdue invoices.

It should also explain whether taxes, software licenses, stock media, hosting, domains, fonts, and external services are included.

Change requests

A change request process prevents informal conversations from altering the project without adjusting the budget or timeline.

The process should require a written description, cost estimate, schedule impact, and approval before additional work starts.

Intellectual property and licensing

Confirm who owns the final design, custom code, copy, photography, and source files after payment. Identify any elements that are licensed rather than transferred.

Themes, plugins, fonts, stock images, and software services may have separate licenses. Ask whether those licenses belong to your business, must be renewed, or remain under the provider’s account.

Account access and credentials

List the accounts you will control, including:

• Domain registration.
• Hosting.
• Content management system administration.
• Analytics and tag management.
• Search Console.
• Email delivery services.
• Payment gateways.
• Booking or customer relationship management integrations.

Do not wait until the end of the project to determine who owns these accounts.

Testing and acceptance

The contract should explain which browsers, devices, templates, forms, integrations, and accessibility checks will be tested.

It should also define acceptance. For example, the client may have a set number of business days to report defects after receiving the staging site.

Launch, warranty, and support

Clarify who handles backups, deployment, domain settings, redirects, analytics, form tests, and post-launch monitoring.

The warranty section should define how long the designer will correct defects related to the agreed scope. Ongoing content changes, new features, software updates, and third-party failures are usually separate support work.

Cancellation and project inactivity

The agreement should explain what happens if either party ends the project or if the client becomes unresponsive.

Check whether completed work will be delivered, which payments are refundable, how reserved time is treated, and whether a dormant project requires a restart fee.

FAQs