Strategy Before Design: Why Most Website Projects Fail

Strategy before design is the difference between a website project that succeeds and one that quietly becomes a redesign of a redesign a year later. Industry data on why businesses undertake a redesign in the first place tells the real story: the large majority start one because the existing site fails to convert visitors, not because it looks dated, and most are specifically triggered by unresolved user experience problems. Both of these are strategy failures dressed up as design problems, and they usually trace back to the same root cause: the project began with “what should this look like” rather than “what is this website actually supposed to achieve.”

This piece looks at what strategy before design actually means in practice for a small business, why skipping it costs more than it saves, what a genuinely useful discovery process looks like before a designer opens a blank canvas, and how to brief or evaluate a design partner using that discovery work as leverage.

Why So Many Website Projects Start With the Wrong Question

Nielsen Norman Group, one of the most established UX research and consulting organisations, defines the discovery phase as the preliminary stage of a project focused specifically on researching the problem itself and framing what needs to be solved, deliberately before any testing of solutions or designs begins. That ordering matters. Discovery is meant to establish the problem with enough clarity that design decisions become a natural consequence of the research, rather than a starting point that research gets retrofitted to justify afterwards.

In practice, many small business website projects skip straight past this. A business owner has a rough sense that their current site “doesn’t look right” or a competitor’s site looks more modern, and the natural next step feels like calling a designer and describing a look. The problem isn’t wanting a better-looking site. It’s that “better-looking” isn’t a strategy, and a designer working from aesthetic preference alone has no way to know whether a homepage redesign should prioritise lead capture, product discovery, brand credibility, or something else entirely, because nobody has defined which of those actually matters most for this specific business.

What Discovery Actually Involves

A proper discovery phase answers a small number of concrete questions before any visual work begins: what is this website’s single most important job (generating enquiries, selling directly, building credibility for referral business, something else), who is the specific audience arriving at it, what does success actually look like in measurable terms, and what’s currently working on the existing site that shouldn’t be thrown away in the process of “fixing” it.

That last question is easy to overlook and expensive to get wrong. Skipping an audit of what already works, specific pages, content, or rankings the current site has earned, is one of the more common ways a redesign quietly destroys value it didn’t need to touch.

Common Mistakes Even in Businesses That Think They’re Doing This Properly

It’s worth being honest that plenty of businesses believe they’ve done a discovery phase and still end up with the same problems, usually for one of a few specific reasons.

The most common is defining goals alone, without input from anyone who actually deals with customers day to day. A founder deciding unilaterally that the website’s job is “generating enquiries” without checking that assumption against what the sales or customer service team actually hears from prospects can miss the real barrier entirely, if, for instance, most lost enquiries are actually happening because pricing isn’t visible anywhere on the current site, a detail a founder working from memory of the business might not think to mention.

A second common mistake is defining success vaguely enough that it can’t actually be measured. “We want more enquiries” sounds like a goal, but without a baseline number and a specific target, there’s no way to know after launch whether the new site delivered or not; it’s a preference dressed up as a measurable objective.

A third is treating discovery as something that happens once, in a single meeting, rather than something that gets tested against real evidence. A business that assumes its audience based on who they’d like to attract, rather than checking who’s actually visiting the current site through analytics, is skipping the evidence-gathering step that makes discovery useful in the first place, even if they held a proper “discovery meeting.”

The Real Cost of Skipping Strategy

The costs of skipping this stage aren’t hypothetical, and they show up in two distinct ways: what happens to the business goals the project was meant to serve, and what happens to the site’s existing technical and search performance.

On the business side, the pattern is consistent across industry data: redesigns undertaken without clear, measurable goals tend to replace one set of problems with another, since a fresh visual design with no defined success metric gives a team no way to know whether the new site is actually performing better than the old one, only whether it looks newer. A business that skips defining what “success” means before starting is, in effect, choosing not to be able to answer that question honestly once the project is finished.

On the technical side, the risk is more concrete and better documented. A website relaunch that isn’t planned with existing SEO performance in mind can lose rankings that took months or years to build, and the most common specific cause is a missing or incomplete URL redirect map, where old page addresses simply stop working and search engines are left with nothing to connect the old ranking signals to the new pages. This is entirely preventable with basic planning, which is precisely why it’s so frustrating when it happens: it’s not a technology limitation, it’s a process failure.

Why Cutting Corners on Planning Rarely Saves Time Either

It’s worth addressing directly, since it’s the usual justification for skipping discovery: going straight to design does not typically save time overall. What it does is move the cost of unresolved questions later in the project, when they’re considerably more expensive to fix. A business goal that should have been clarified in week one, but instead surfaces as a disagreement in week six, after design work is already underway, doesn’t just cost the time to resolve the disagreement; it costs the design work built on the wrong assumption. Discovery isn’t an extra phase bolted onto a project for its own sake. It’s the phase that prevents the most expensive kind of rework.

What Strategy Before Design Actually Looks Like in Practice

Defining Clear, Measurable Business Goals

The starting point is a specific answer to what this website needs to do, stated in terms that can actually be measured once the site is live: increase enquiry form submissions by a defined amount, improve the conversion rate on a specific product category, or reduce the bounce rate on the page most visitors land on first. A goal stated this specifically does two useful things: it gives the designer a genuine brief to work from, and it gives the business a way to know, after launch, whether the project actually worked.

A worked example: consider a small accountancy practice whose starting point is simply “we want a better website.” Pushed to be more specific, the actual goal turns out to be increasing enquiries from a particular type of client, small business owners needing ongoing bookkeeping support, rather than the one-off personal tax queries that currently make up most of their enquiry form submissions.

That distinction changes almost everything about the brief: it means the homepage needs to speak directly to business owners rather than individuals, the enquiry form should ask questions that qualify the type of client, and success should be measured specifically by the proportion of enquiries from business clients, not simply the total number of enquiries received. None of that would have surfaced from “we want a better website” alone; it only emerged from pushing the initial vague goal into something specific enough to design around.

Understanding the Actual Audience, Not an Assumed One

It’s common for a business to design a website around who they imagine their customer to be, rather than who’s actually arriving at the current site. Existing analytics, even basic ones, usually tell a more accurate story: which pages people actually spend time on, what device they’re browsing from, where they drop off. Building a new site around an assumed audience rather than the evidenced one is one of the more common ways a redesign fails to improve on the site it replaced.

Structuring Content and Information Architecture Before Visual Design

Deciding how content is organised, what the navigation structure looks like, and which pages exist at all, is a strategic decision that should happen before visual design starts, not as a byproduct of it. A site with a confused structure will confuse visitors regardless of how well it’s styled, and retrofitting a sound structure onto an already-designed visual layout is considerably harder than designing the layout around a structure that’s already been thought through.

Folding SEO Into the Plan From the Start, Not After Launch

Search visibility should be part of the initial planning conversation, not a task handed to someone after the new site goes live. In practical terms, this means auditing which existing pages currently earn meaningful search traffic before the project begins, building a complete map of old page addresses to their new equivalents, and treating that redirect map as a required project deliverable rather than an optional extra. Businesses that build this into the plan from day one consistently retain more of their existing search visibility through a relaunch than those that treat it as post-launch cleanup.

How to Brief or Evaluate a Web Design Partner Using This Work

Once the discovery questions have genuine answers, they become the clearest test of whether a design partner is actually equipped to deliver, and a useful way to evaluate one before committing.

A design partner worth working with will ask these questions before presenting any visual concepts, not after. If an agency or freelancer moves straight to showing homepage mockups in a first conversation, without first asking what the site needs to achieve, who it needs to achieve it for, and what currently works that shouldn’t be lost, that’s a meaningful signal about how the rest of the project is likely to go.

It’s equally worth sharing the discovery answers proactively rather than waiting to be asked. A business that arrives at a first meeting with a specific, measurable goal, real analytics on its current audience, and a list of pages currently earning search traffic gives any competent design partner a genuine brief to respond to, and tends to get a substantially stronger proposal back as a result, since the partner isn’t guessing at what matters.

Measuring Success After Launch

Discovery work isn’t finished once the site goes live; it’s finished once the defined success metric has actually been checked against real results. This means returning to the specific, measurable goal set at the start, whether that’s enquiry volume, conversion rate on a specific page, or the proportion of enquiries from a particular type of client, and reviewing it at a defined point after launch, commonly around one and three months in, rather than assuming the new site is working simply because nobody has complained.

If the metric hasn’t moved, or has moved in the wrong direction, that’s valuable information rather than a failure to hide. It usually points to a specific, fixable issue, a call to action that isn’t visible enough, a form that’s too long, a page that doesn’t answer the question visitors actually arrive with, rather than a signal that the entire project needs to be redone from scratch.

Why Stakeholder Disagreement Is Better Resolved in Discovery Than Mid-Project

One further benefit of proper discovery is worth naming directly: it’s a considerably better setting for resolving internal disagreement than the middle of a design project. It’s common for a small business to have more than one person with a view on what the website should do, a founder focused on brand perception, a sales lead focused on lead quality, an operations person focused on reducing support queries through better self-service content.

These views aren’t necessarily in conflict, but if they’re never explicitly reconciled into a single, agreed set of goals before a designer starts work, they tend to surface as disagreement partway through the project instead, once there’s an actual mockup to react to and disagree about. Resolving this during discovery, while the cost of changing direction is still low, is considerably cheaper and less frustrating than resolving it once visual design work is already underway and each stakeholder is reacting to a finished-looking concept rather than an open question.

A Practical Discovery Checklist for a Small Business

Before briefing a designer, it’s worth having clear answers to the following:

• What is this website’s single most important job, stated specifically enough that a stranger could understand what “success” means for this project.
• Who is actually arriving at the current site, based on real analytics rather than assumption.
• Which existing pages, content, or rankings are already working and shouldn’t be lost in the process.
• What does the current site’s navigation and content structure look like, and does it need restructuring independent of how it looks.
• Is there a complete list of every existing page address, and a plan for where each one will redirect to on the new site.
• What will actually be measured after launch, and at what point, to determine whether the project succeeded.

A business that can answer all six of these before contacting a designer is starting from a fundamentally stronger position than one that starts with a Pinterest board of sites they like the look of.

Frequently Asked Questions