Practical guidance from 507 Web Pros: this article explains the important decisions, common mistakes, and checks that help small businesses build websites people can actually use.
Identify the business goal
The first question is not what color a homepage should be. It is what the website must help people accomplish. One company wants estimate requests; another needs appointment bookings; a third needs customers to compare products before visiting a store. Write the primary visitor action in one sentence, then identify secondary actions.
Explain what success would look like after launch. Qualified inquiries, a working online booking flow, or fewer repetitive phone questions are clearer goals than simply ‘looking professional.’ Avoid guaranteeing a certain number of leads or a search ranking. Those outcomes depend on conditions outside a designer’s control.
Describe the people you want to reach
List your main customer groups and the questions they ask before contacting you. A homeowner may care about service coverage, process, and scheduling. A business buyer may ask about scope, team experience, and procurement requirements. These differences should guide navigation and page content.
If you serve several audiences, identify where their needs overlap and where separate information is justified. Do not build dozens of near-identical pages merely to reach every imagined search phrase. The small-business website essentials guide can help you distinguish important pages from extras.
Gather accurate content and brand material
Collect your logo, approved business name, phone number, email, service details, and any photographs you own or are licensed to use. Keep the files organized in a shared folder. Mark which claims and descriptions have been approved, and identify who can answer unresolved questions.
Include any existing brand guidelines, examples of prior projects you have permission to show, and required policy language. Do not fill gaps with made-up testimonials, certifications, or customer outcomes. If you need the designer to write copy or source images, make that a clearly priced part of the proposal.
Sketch a realistic page list
A starting sitemap might include Home, Services, About, Contact, and necessary policy pages. Add distinct service pages when visitors have different questions, not simply because more pages sounds better. For each proposed page, write down its main question and next step.
An existing site also needs a URL inventory. Some old pages may have links, search traffic, or bookmarks. If an address changes, decide where it should redirect before launch. Replacing every missing page with a homepage redirect can frustrate visitors looking for specific information.
Separate essential features from optional ones
Describe the actual workflow when requesting booking, online payments, a client portal, subscriptions, forms, or integrations. A simple form that emails the office is not equivalent to a full scheduling system with staff calendars and payment collection.
Put must-have functionality in the first phase and optional enhancements in a later phase. Evaluate complexity, ongoing subscription costs, privacy, and maintenance before approving each feature. A simpler reliable process may be more valuable than a complicated integration no one is ready to support.
Ask for a scope, not just a price
A useful proposal states page count, content responsibilities, design revisions, testing, hosting assumptions, software licenses, and post-launch support. Ask which features and services are excluded. The lowest headline price is not necessarily the lowest total cost.
Discuss change requests in advance. If the company expands the number of pages or introduces e-commerce halfway through development, how will the timeline and cost change? Agreeing on milestones and approval responsibilities prevents avoidable disputes.
Clarify ownership and future maintenance
Confirm who controls the domain, hosting, administrator accounts, images, and any third-party service subscriptions. Ask how the website can be backed up and restored, how updates will be handled, and what access you will retain if you change providers.
Understand the difference between a one-time build and ongoing support. The article on redesign versus website maintenance explains why software repairs and structural design changes should not be treated as the same service.
Define launch tests and acceptance criteria
Before sign-off, require navigation tests, form submission tests, responsive checks, proofreading, working links, clear headings, and appropriate metadata. Inspect pages on a real phone when practical. Verify that the website’s indexability is configured as intended and that backups are available.
Prepare a one-page brief with goals, audience, proposed pages, content assets, required features, budget range, ownership responsibilities, and launch checks. That brief gives every prospective designer the same foundation for a meaningful quote.
Questions to ask during the first consultation
Who writes the copy, who supplies imagery, and who reviews factual claims? Which devices will be tested, and how are accessibility problems reported? How will updates be handled after launch? Answers to these questions reveal whether a quote covers only appearance or the complete customer experience.
Ask for examples relevant to your type of project, but avoid assuming that a visually impressive portfolio proves every technical requirement. Request a walkthrough of the development and approval process. If a designer promises a specific ranking or sales result, ask what evidence supports that promise and what variables remain outside their control.
Prepare feedback that leads to useful revisions
Feedback such as ‘make it pop’ is difficult to act on because people interpret it differently. Instead, describe the visitor problem: ‘The service description is hard to find,’ ‘the phone number is too small on mobile,’ or ‘this button should open the estimate form.’ Point to the affected page and explain the intended outcome.
Collect comments from decision makers before sending a revision request. Contradictory instructions from several people can increase cost and confusion. Keep a record of approved designs and copy so that later changes do not accidentally reintroduce rejected wording.
Understand the difference between staging and live
Ask whether the designer uses a development or staging area. A staging site allows new layouts, forms, and software to be evaluated without immediately changing the pages customers see. The team should still plan for the final move, because domain settings, links, and form behavior can differ on the live site.
For an existing website, discuss backup creation, rollback options, redirects, and launch timing. Do not rely on a backup that has never been checked. Know who can pause the release and who can restore service if something breaks.
Plan the first month after publishing
Keep a short post-launch review list. Confirm incoming inquiries arrive, check important links, observe pages for mobile layout defects, and update incorrect descriptions. Where analytics are installed, review useful visitor actions instead of fixating only on total page views.
Schedule responsibility for software updates, backups, content reviews, and domain renewals. Treat the website as an operating business asset, not a one-time image. The clearest design brief includes this ongoing ownership plan from the beginning.
Review the finished project against the original brief
Before accepting the website, return to the goals written at the beginning. Can a first-time visitor understand the offer? Do important pages lead to working next steps? Are contact details, brand assets, service descriptions, and permissions accurate? Compare the delivered work with the signed scope instead of relying only on whether the final design looks attractive.
Ask for a short handover showing how to edit pages, replace photos, review form submissions, and request support. Save the administrator and hosting access details securely. If the design contains subscriptions or licensed plugins, document renewal dates and the person responsible. That small amount of organization makes it much easier to maintain the site responsibly after launch.
A good designer-client relationship is easier when expectations are written down, decisions are recorded, and feedback is tied to user needs. If you want to see the business behind these website planning resources, visit the 507 Web Pros About page.