Define the problem before comparing providers
A designer can only be a good fit in relation to the project. Before opening a dozen portfolio tabs, write down why the website needs to change. Common reasons include weak credibility, poor mobile use, unclear services, too few qualified inquiries, difficult updates, or a customer action the current site cannot support.
Add the constraints that matter: who will approve the work, what content exists, whether there is a launch date, which systems must connect, and who should maintain the finished site. This brief does not need to prescribe technology or page layouts. It should give providers a clear business problem to respond to.
Look past the portfolio thumbnail
Strong visuals matter, but a polished screenshot does not tell you whether the site is useful. Open the live work when possible and test it as a customer would. Can you understand the business quickly? Are services easy to find? Does the primary action make sense? Does the experience remain clear on a phone?
Ask the designer what they were responsible for. Strategy, copy, photography, interface design, development, and ongoing optimization may come from different people. That is normal, but you should know which capabilities the work actually demonstrates.
Check the technical baseline
You do not need to become a developer to ask good questions. The provider should be able to explain how they handle the fundamentals in plain language:
- Responsive behavior across current phones, tablets, and desktops.
- Page speed, image handling, and avoidance of unnecessary scripts.
- Keyboard use, readable contrast, form labels, and other accessibility basics.
- Unique page titles, descriptions, crawlable content, sitemap, and redirects.
- Form reliability, spam protection, security updates, and backups.
- Analytics setup that measures meaningful actions rather than page views alone.
No provider can honestly guarantee rankings or perfect performance scores in every situation. They should be able to describe the technical standard they build toward and the tradeoffs a particular feature introduces.
Clarify ownership, hosting, and support
Before signing, establish who owns the domain, content, design files, code, analytics accounts, and third-party subscriptions. Ideally, critical business accounts are created in the client’s name with the provider receiving appropriate access.
Ask what happens after launch. Some businesses want a handoff and an editing guide. Others prefer a partner to handle hosting, maintenance, content, analytics, SEO, and continued development. Either model can work when expectations, response times, and ongoing costs are explicit.
Communication belongs in this conversation too. Find out who leads the project, who does the work, how feedback is collected, and how often you will see progress. The best process is one your team can participate in without becoming the project manager.
Questions worth asking before you sign
- How will you learn about our business and customers?
- What is included in the scope, and what commonly becomes an added cost?
- Who writes and approves the content?
- Who will design and develop the site?
- How will mobile usability, accessibility, performance, and SEO be checked?
- What do we own at launch, and can another provider take over later?
- What support is available after launch?
- What could delay the timeline, and how are changes handled?
Compare the specificity of the answers, not just the confidence with which they are delivered. A thoughtful provider will sometimes ask for more context before recommending a solution.