Build a Web Design Prospect List from Observable Evidence

Write the agency offer before choosing prospects

Describe what the agency can deliver in practical terms. A five-page service-business redesign, an industrial product-catalog restructure, a subscription-store improvement project, and ongoing landing-page production require different prospects. List the project type, platforms you support, typical content responsibility, integration boundaries, and the business models you understand. This gives the researcher a reason to care about particular website observations.

Then define the minimum business conditions. A small design studio may need an operating business with a clear service offering, an accessible decision-maker, and a website scope it can deliver. A specialist ecommerce team may require an active merchant and a supported commerce platform. An enterprise agency may need evidence of multiple stakeholder groups or complex content rather than a simple broken button.

Separate mandatory conditions from preferences. A platform your team cannot maintain can be an exclusion even when the design opportunity looks attractive. An outdated visual style may be only a preference because it says little about project economics or business priority. Write the exclusions early so an interesting screenshot does not override the agency's actual delivery constraints.

Use a one-sentence target definition as the review anchor: 'Operating industrial suppliers whose public product information and enquiry journey create a plausible need for a catalog redesign within our supported stack.' The sentence does not assume that every target needs to buy. It narrows the research to a problem area your team can discuss credibly and deliver if the business confirms the need.

Confirm the business and the website being reviewed

Verify that the website belongs to the intended operating company. Check the business description, branding, contact context, and any supplied account information. Similar names, regional franchises, parent-company domains, and outdated redirects can send a reviewer to the wrong property. A detailed review of the wrong site is still unusable research.

Identify the web property's role. A corporate brochure, consumer store, support portal, event microsite, and recruitment page have different purposes. A deliberately minimal investor site should not be judged by the same conversion expectations as a service landing page. Record the page set you are reviewing and the business task it is expected to support.

Look for signs that the business is currently operating, using public evidence within the scope. Current service pages, active product offerings, recent company-authored material, and a consistent contact identity can support that judgment. Do not assume that an old copyright date proves inactivity or that a recent blog post proves financial health. State the actual observations rather than translating them into unsupported business conclusions.

Keep group relationships visible. A local subsidiary may use a central corporate site it cannot independently redesign. A franchise may have limited control over templates. A brand may share a platform with several sister stores. These facts can change the likely project owner and delivery scope. When control is unknown, make it a discovery question instead of assuming the visible business can authorize every website change.

Choose a small but representative page sample

Select pages by user task rather than convenience. A useful initial sample includes the homepage, one important service or product page, a category or navigation page, a proof page such as a case study, and the main enquiry or purchase entry point. Add a second example when the site contains clearly different templates or business lines.

Use both desktop and a mobile-sized view for the chosen journeys, and record the review conditions. If you use an actual device, note the device context. If you use browser emulation, say so. The aim is a reproducible observation, not a claim that every possible device has been tested. A problem found at one viewport deserves a scoped statement.

Do not select only the weakest-looking page. A campaign should reflect the business's current public experience, including strengths. If the homepage looks dated but the service pages and enquiry flow work well, the potential project may be a limited visual refresh rather than a complete rebuild. If a modern homepage leads into a confusing catalog, the deeper content structure may be the more relevant issue.

Set a stopping rule for prospect research. The first pass should collect enough evidence to decide whether a discovery conversation is justified. It is not a free comprehensive audit of the entire site. Escalate a promising account for deeper review when the expected project fit warrants it, and keep the initial evidence boundary visible so the findings are not mistaken for a full technical assessment.

Use a rubric that separates evidence from priority

Create one row per observation with the page URL, task, device or viewport, observed behavior, potential user consequence, uncertainty, and offer relevance. The observed behavior should be concrete enough to repeat: a menu item opens off-screen, a service page lacks a next step, or product specifications are split across unrelated downloads. Avoid labels such as bad, ugly, or outdated without explaining the task impact.

Rate issue severity separately from account fit. A severe mobile defect on a site outside your supported platform may be a poor prospect. A modest content-structure issue on a business that closely matches your offer may justify a useful conversation. Keep the ratings separate so that a dramatic screenshot does not dominate the entire qualification.

Add a counterevidence column. The site may offer an alternative contact path, a clear downloadable specification, or an intentionally simple purchase process. Counterevidence can narrow the finding and improve the recommendation. It also helps reviewers avoid collecting only facts that support a redesign sale.

Review mobile tasks without inventing user behavior

Choose a task a plausible buyer would perform, such as finding a service area, comparing two product specifications, or locating the enquiry route. Follow that task at the recorded mobile viewport. Note where the layout or interaction prevents progress, obscures information, or makes the next action unclear. Describe what happened rather than assuming how many customers abandon at that point.

Check the complete local sequence. A menu may open correctly but close before a submenu can be selected. A sticky banner may leave a button visible yet cover the form field that follows. A product table may remain readable only through horizontal scrolling that the page does not make apparent. The evidence should identify the step and page state, not simply label the entire website non-mobile-friendly.

Distinguish content density from an actual barrier. A detailed industrial specification can legitimately require a large table, and a buyer may need that detail. The design question is how the information is presented and navigated on a small screen, not whether the page has fewer words. An agency specializing in technical content can use this distinction to propose a better structure without deleting useful material.

Record an alternative route if one works. If the mobile navigation fails but the homepage provides a clear direct service link, the finding is narrower than 'customers cannot reach services.' If the issue appears only in one browser state, preserve that condition. This precision makes the eventual discussion credible and gives a developer a useful reproduction path if the prospect asks for details.

Assess content and navigation against the buying task

Read the site as a prospective buyer trying to decide whether the company can solve a particular problem. Can you identify what is sold, who it serves, which constraints matter, and how to take the next step? A generic slogan is not automatically a flaw, but the journey needs enough concrete information somewhere to support the decision.

Map the path from the homepage or relevant landing page to a specific service or product. Record labels that are ambiguous, categories that mix unlike concepts, and pages whose promised information is missing. For an industrial supplier, grouping products only by internal model codes may be less helpful to a new buyer than grouping by application. That is a design hypothesis to discuss, not proof that current customers are confused.

Check whether proof matches the offer. A company may claim expertise in a service while its case studies describe a different line of work. This can justify asking whether the website reflects the current business. It does not prove that the company lacks the claimed capability. The content gap may be a publishing backlog, a confidentiality constraint, or a deliberate focus.

Look for strengths that a redesign should preserve. Clear technical explanations, useful downloadable resources, strong project photography, and a simple quotation route can be valuable assets even on a dated site. A prospect brief that recognizes those strengths can propose a focused improvement rather than treating the entire existing site as something to discard.

Inspect the enquiry path without submitting a fake lead

Follow the visible route from a relevant service page to the enquiry entry point. Check whether the call to action matches the page's purpose, whether the form or contact route is understandable, and whether the buyer knows what information to provide. Record the visible structure without sending a message, creating an account, or triggering a transaction merely to qualify the prospect.

A long form is not automatically wrong. It may support a technical quotation that genuinely requires specifications. A short form is not automatically good if it gives the company too little context to route the request. The prospecting question is whether the required information and instructions fit the apparent sales process. Internal completion rates and lead quality remain unknown.

Check for mismatches between promise and destination. A button offering a product-specific quote may open a generic contact page with no product context. A consultation invitation may lead to a form whose fields assume an existing customer. These are concrete observations that can support a discussion about routing and page design without claiming that the company loses a particular amount of revenue.

Separate visible form behavior from back-office workflow. You can observe field labels, instructions, and the initial route. You cannot infer who receives submissions, how quickly they respond, or whether a CRM automation exists. A useful discovery question asks how enquiries are triaged. An unsupported claim says the team manually processes every form and needs automation.

Use preliminary accessibility checks within their limits

Include a small number of accessibility observations when they are relevant to the agency's capability. The W3C Web Accessibility Initiative's Easy Checks resource covers a preliminary review and explicitly says that passing those checks is not a comprehensive evaluation. That boundary matters in prospecting: a quick check can identify a specific barrier without establishing overall conformance or nonconformance.

Use the source guidance to choose checks you can perform competently, then record the exact result. A visible keyboard-focus problem on a particular control is more useful than declaring the site inaccessible. A form label concern on one page should remain attached to that form. If you do not have the expertise to interpret a result, mark it for specialist review rather than converting a tool warning into a confident claim.

Do not use accessibility observations as a threatening sales device or imply a legal conclusion from a quick public review. The relevant agency conversation is about making tasks usable and deciding whether a proper assessment is needed. A business may have existing accessibility work underway, internal constraints, or a specialist provider. Those are discovery topics.

Keep the service boundary explicit. An agency offering visual redesign may need a qualified partner for a comprehensive accessibility evaluation. An agency with that expertise can describe its assessment process and deliverables without claiming that a prospecting pass has already completed them. This distinction helps the buyer understand the difference between a preliminary observation and a scoped professional engagement.

References: W3C WAI: Easy Checks for a first accessibility review ↗

Treat performance tests as evidence, not a revenue calculator

Automated performance reports can identify areas worth investigating, but one score should not decide whether a business needs a redesign. Chrome's Lighthouse documentation explains that performance results can fluctuate with underlying conditions and that the score summarizes weighted metrics. Record the page, test context, date, and relevant measurements rather than presenting one number as a permanent property of the website.

Repeat a consequential observation under comparable conditions before relying on it in a prospect brief. If the result varies, show the variation or state that the evidence is inconclusive. Do not select only the weakest run because it makes the sales case stronger. A fair review asks whether the issue is reproducible and relevant to a buyer task.

Separate a performance concern from its cause. A slow observed page may involve content, scripts, network conditions, or other factors. Public prospect research usually cannot determine which internal decision produced the result. Avoid prescribing a complete platform migration when the evidence supports only a narrower performance investigation.

Do not convert a score into estimated lost sales without the company's actual traffic, conversion, and commercial data. A hypothetical improvement model can be discussed later with explicit assumptions, but it should not appear as a measured fact in the initial brief. The useful conclusion is that a defined page and task showed a performance concern worth validating, not that the company is losing an invented sum each month.

References: Chrome for Developers: Lighthouse performance scoring ↗

Worked example: an industrial catalog with a focused fit

The fictional company Fenwick Motion supplies industrial actuators and installation support. The agency specializes in product-catalog websites for technical suppliers. The homepage is visually dated, but that is not the main qualification. The reviewer selects a buyer task: identify an actuator suitable for a wet environment and request an application-specific quotation.

The product navigation uses internal model families without explaining their application differences. Two relevant specification sheets are accessible, but the page that links them does not explain which model fits the chosen environment. On the reviewed mobile viewport, the table extends beyond the visible area without a clear scrolling cue. The quotation button opens a general contact page with no product reference.

The brief also records strengths. The technical PDFs are detailed, the company clearly lists installation support, and the contact page provides a named business function. Those assets suggest that a content and catalog-structure project could preserve substantial existing material. The agency does not need to claim that the entire site is broken to explain a relevant service.

The qualification result is a supported business fit plus several reproducible task observations. Internal traffic, quotation completion rates, and project ownership remain unknown. The recommended discovery question asks how buyers currently choose between model families and whether the team wants to make the application-to-quote journey more self-service. It does not assert that the current structure has reduced revenue.

If the prospect says most buyers are returning engineers who know the model codes, the agency should revise the hypothesis. The opportunity may lie in helping new buyers rather than replacing the existing expert path. That response would improve the project scope. A good prospect brief anticipates such counterevidence instead of treating the initial review as a final diagnosis.

Worked example: a modern service site needs a narrower offer

The fictional consultancy Lumen Field Advisory has a modern website with clear typography, fast-feeling navigation in the review, and well-written case studies. An agency searching only for old-looking sites would skip it. The agency's actual offer, however, is service-page restructuring for consultancies with several buyer groups.

The reviewer follows a task for an operations leader interested in a short assessment engagement. The homepage groups services by broad themes, while the relevant assessment is described only inside a long case study. The main call to action invites a general conversation without explaining whether a smaller initial engagement is available. No broken control is observed; the issue is how a specific offer is represented.

The evidence supports a content-discovery hypothesis, not a complete visual redesign. The agency can ask whether the firm wants to make its assessment offer easier to evaluate independently. It should not claim that the current site performs poorly, that buyers cannot contact the consultancy, or that the brand needs replacing. The site's existing strengths are part of the rationale for a limited engagement.

Suppose the consultancy explains that the assessment is intentionally offered only through referrals. That answer weakens the proposed public-service-page project. The agency should accept the counterevidence rather than insisting that every offer needs a prominent page. Public research identifies a question; the business determines whether the proposed change matches its sales strategy.

The resulting prospect list can still include Lumen Field Advisory in a 'content opportunity to validate' segment, provided the agency's campaign accepts such hypotheses. It should not be mixed indistinguishably with accounts that have a confirmed functional defect. Segmenting the reason for inclusion helps the salesperson choose an accurate opening and a proportionate next step.

Worked example: a visibly weak site is still a poor prospect

The fictional business Coastline Heritage Tours has small text, inconsistent page layouts, and a booking link that behaves poorly in the reviewed mobile state. The reviewing agency delivers complex B2B product websites and does not implement booking systems. The website observations are real within the fictional example, but they do not make the company a suitable client for this agency.

The researcher also finds that the business is part of a franchise whose central office manages the booking platform. Local pages contain content the operator may control, but the ownership of the booking experience is unclear. A campaign aimed at the local owner with a complete-platform replacement proposal would therefore rest on two unsupported assumptions: delivery fit and decision authority.

The appropriate disposition is exclude from this campaign or route to a separately defined partner opportunity. The evidence note can preserve the observed issue without pretending the agency should pursue it. If the firm has a trusted booking specialist, a referral process might be relevant, but that is a different offer and should not be added to the campaign silently.

This case demonstrates why website severity and account fit need separate columns. A list sorted only by the number of issues can prioritize businesses the agency cannot serve. A list sorted only by company size can miss important delivery constraints. The best prospect for a specific agency is an account where supported observations, business context, and delivery capability align.

Record the exclusion reason in a way that remains useful later: unsupported booking-system scope and uncertain local authority. Do not label the company low quality or unworthy. Another agency could serve it well. Offer-relative qualification is a decision about your campaign, not a universal judgment about the business.

Build a score that explains priority

Use a score only after defining the dimensions. A simple internal model can separate business eligibility, relevance of the observed issue, delivery compatibility, evidence strength, and access to a plausible stakeholder. Keep mandatory exclusions outside the point total so that several attractive observations cannot compensate for a platform or project type the agency cannot deliver.

Treat unknowns explicitly. If website ownership is unclear, the account may need review rather than a low score. If the business model is well supported but performance evidence is inconclusive, the score can reflect the supported content opportunity without awarding points for speed. A combined number should not conceal which part of the case remains uncertain.

Write a one-paragraph explanation beside the score. For example: 'Relevant industrial supplier; application-selection journey has reproducible content and navigation friction; agency can deliver the required catalog work; project owner and priority unconfirmed.' This is more useful to a salesperson than a score of 82 with no account-specific rationale.

Test the model with counterexamples. Include a visually weak site outside your capabilities, a polished site with a narrow relevant content problem, and a site with several issues but no clear operating business. If the score ranks the first or third highest merely because more problems were found, revise the rules. The model should support the agency's service strategy rather than reward criticism.

Turn observations into a respectful approach brief

Choose one or two findings that connect directly to the agency's service. Include the page, task, and observation, then state a neutral question. A prospect does not need a catalogue of every cosmetic concern discovered in a quick review. The purpose of the brief is to help a salesperson begin an informed conversation, not to overwhelm the business with an unsolicited audit report.

Use wording that distinguishes the observation from the hypothesis. 'The actuator page links to two specification sheets without an application comparison' is an observation. 'This may make first-time selection harder' is a hypothesis. 'How do new buyers choose between those models today?' is a discovery question. Keeping the sequence visible makes the reasoning easy to assess.

Recognize what already works. Mentioning a useful technical resource or a clear service explanation can show that the review was specific rather than a generic criticism template. The recognition should be relevant to the proposed project, not empty praise. For example, preserving the existing specification content can reduce the apparent scope of a catalog restructuring discussion.

Do not state fabricated conversion losses, traffic declines, security vulnerabilities, or legal exposure. Do not imply that the business has approved a redesign or lacks an internal team. The approach should be grounded in public evidence and the agency's actual capability. Buying contact data does not by itself settle whether or how outreach is permitted; the campaign team must handle that separate decision.

Audit the list and troubleshoot weak results

Review a sample of included, held, and excluded accounts. Confirm that the cited page belongs to the right company, that the observation can be reproduced under the stated conditions, and that the proposed service follows from the evidence. Check whether reviewers are consistently applying the same business and delivery exclusions.

If the list contains many unattractive but irrelevant sites, tighten offer fit before collecting more observations. If it contains strong businesses but generic rationales, improve the task-based review. If every account receives a full-redesign recommendation, add a requirement to consider narrower alternatives and counterevidence. The failure may be in the qualification method rather than the source list.

If reviewers disagree on severity, compare the task and expected user. One may assume a first-time buyer while another assumes an expert returning customer. Resolve that assumption explicitly. If a mobile issue cannot be reproduced, retain the original context and mark the result uncertain rather than escalating the language. If the site changes, preserve the earlier observation as history and update the current decision.

Measure useful outputs: supported eligible accounts, unresolved ownership cases, reproducible observations, and the proportion of briefs with a specific service rationale. Do not treat the number of flaws found as the primary success metric. A research process that finds fewer but more relevant opportunities can be more useful than one that produces a long list of indiscriminate criticisms.

Run the prospecting process as a repeatable workflow

Prepare the research brief with the agency's website, service description, inclusion rules, exclusions, supported platforms, and examples of good and poor fit. If requesting seller-specific intelligence, provide enough offer context to distinguish a catalog project from a brochure redesign or an ongoing landing-page service. A generic request for businesses with bad websites leaves too much room for subjective interpretation.

Set a review budget per account and a clear escalation path. Initial qualification should identify whether a deeper conversation is justified. Promising complex accounts can receive a more detailed dossier, while straightforward exclusions should be recorded promptly. This keeps the process focused without pretending that every public review is a comprehensive audit.

Keep the deliverable usable in a table and a brief. The table should hold sortable fields such as company, property, business type, supported platform, disposition, and score. The brief should explain the observed journey, evidence, strengths, uncertainties, and proposed discovery question. Both should share a stable company identifier.

Before launch, recheck the most consequential website observations and contact roles. Websites can change between research and use. A final review does not need to repeat every optional note, but it should prevent a salesperson from opening with a problem that has already been fixed. Preserve the dates so the team can understand what was actually checked.

• Define the service, supported delivery scope, and mandatory exclusions.
• Confirm the operating business and the exact web property being reviewed.
• Choose representative buyer tasks and record mobile or desktop conditions.
• Log concrete observations, strengths, uncertainties, and potential service relevance.
• Use accessibility and performance evidence only within the review's actual scope.
• Separate website issue severity from account fit and buying readiness.
• Write an account-specific discovery question and preserve counterevidence.
• Audit the list, refresh consequential facts, and retain evidence through handoff.