Why we place so much importance on the website discovery phase

The voice and reading of this article were created with artificial intelligence.

Most digital projects don’t fail in development, they fail in discovery. Not because the team lacked skill, but because they started solving before they fully understood the problem. The website discovery phase isn’t overhead. It’s where clarity begins and confusion starts to die.

Clients often arrive saying, “We just need a better site,” but nine times out of ten, that’s not the real problem. It’s just the most visible one. A slow site, a dated look, poor conversion, these are symptoms. Discovery is where we figure out what’s actually broken underneath.

This isn’t about wireframes or sitemaps. It’s about asking hard questions before anyone opens Figma. What are you really trying to fix? What does success look like in plain English, not just in analytics dashboards? Who’s going to call this project a win, and what do they actually care about?

One founder described the process as “commercial therapy.” That’s about right. Discovery is the space to say what’s true, even if it makes the brief messy for a bit.

When we worked with Catch, the UK angling platform, they came in thinking about scale and booking flow. But once we unpacked it, the challenge was bigger: they weren’t just building a booking tool, they were shifting toward becoming an ecosystem for anglers. That single realisation reframed the entire product direction. The discovery phase didn’t just validate assumptions; it changed the business.

Too many teams skip this step because they’re eager to show progress. But speed without precision is noise. Discovery is the first step that gives every other step its meaning, and without it, you’re just building prettier problems.

Most briefs are clean. Too clean. They’re polished, rational, and often wrong, because they skip the messy middle where real understanding lives. The discovery process isn’t there to confirm what’s already assumed. It’s there to break it apart.

A good discovery isn’t polite. It questions everything: Why are you really redesigning? Who’s struggling with what? Where is time or money leaking from this system right now?

This is where we move from wish-lists to realities. We’re not just listening, we’re interrogating. We’re surfacing assumptions, exposing knowledge gaps, and reframing conversations around outcomes. Not features. Not opinions. Outcomes.

During one B2B discovery, the client was adamant that their homepage was the problem. But once we gathered information across teams, it became clear the real issue was buried deeper: they were answering the wrong questions for the wrong audience. That shift changed the entire content plan, and ultimately drove a better understanding of their funnel.

The key is not to treat discovery like a static checklist. You need to layer methods: heatmap analysis, stakeholder workshops, content audits, sales call transcripts, even a glance at how support tickets are tagged. Because each piece unlocks a different truth.

Great discovery uncovers user needs that don’t appear in spreadsheets. It picks up on user friction that’s been normalised. It connects disconnected pain points across teams. That’s where the gold is. You won’t find it in the brief, but you will find it if you ask better questions and sit with uncomfortable answers.

Because discovery isn’t about what the client wants, it’s about what the user actually needs, what the business can realistically deliver, and what it all has to achieve commercially. That’s the line we draw.

One of the most common points of failure in digital projects isn’t technology. It’s the wrong people making the wrong decisions at the wrong time. Or worse, right people, but too late.

The project team needs to be shaped at the start, not bolted on after discovery is done. That means getting the project manager, strategist, developer, content lead, and at least one voice of the user involved from day one. Waiting until wireframes are signed off is already too late.

The kickoff meeting isn’t just a formal start, it’s your pressure test. Can the team align around what success looks like? Are there conflicting expectations between marketing and product? Will tech constraints derail scope mid-sprint? These aren’t blockers later, they’re alignment issues now.

In a discovery project for a national property developer, we brought together stakeholders from marketing, sales and the board. On the surface, everyone wanted the same thing: more leads. But as the session unfolded, we uncovered that each team had a very different idea of who those leads should be.

Marketing was chasing volume through brand storytelling. Sales wanted qualified buyers already armed with financial data. And leadership wanted to attract joint venture partners. Same project, three competing goals.

That surfaced in a single face-to-face session. Without it, we’d have built a site optimised for click-throughs… while sales quietly starved. Instead, discovery became a tool for prioritisation. We redefined what a lead actually meant and tailored user journeys to support all three objectives, without cannibalising each other.

Every team member brings a lens. And those lenses only work if they’re present from the start. Developers catch edge cases that strategy might miss. Support teams highlight common UX drop-offs. Marketing sees where content falls short. Discovery is where those perspectives collide, and sharpen each other.

You don’t need everyone in every session. But you do need to design discovery around access, to insights, blockers, contradictions and commercial drivers. That’s the real work.

And when it’s done right? Everyone leaves with clarity. Not just what to build, but why it matters, who it’s for, and what success looks like when we get there.

Data is useful. But it’s not the brief. Google Analytics can show you bounce rates, most visited pages, or session duration, but it can’t tell you why people bounced. Or what they were actually hoping to find when they landed on the site.

In discovery, we look at analytics, heat-maps, scroll depth and traffic sources, but we never treat them in isolation. A spike in traffic to a blog post doesn’t mean that page is working. It could mean it’s misleadingly titled. Or over-indexing on one search term. Or worse, it’s ranking for something you don’t want to be known for.

Page views are interesting. But without context from sales teams, customer support, or product managers, they don’t give you anything actionable. Discovery is where we combine quantitative data with qualitative truth. That means asking teams what they hear on the phone. Where users are getting stuck. What’s not being said.

When we audited the current website for a healthcare project, the analytics showed the careers section was one of the most visited pages. On paper, that looked like success. But in interviews, the internal team revealed that it was mostly internal traffic, staff clicking through to find HR links that weren’t where they should be. The insight? It wasn’t a recruitment asset. It was a workaround for broken internal comms.

Discovery connects the numbers to reality. It stops you from building based on assumptions, or worse, optimising for vanity metrics. If you want to increase website traffic, great. But only if it’s the right traffic, with the right intent, heading toward the right outcomes.

That’s why we look at data. Not to confirm success. But to challenge it.

One of the easiest ways to waste a digital budget? Rebuilding what already exists, just with nicer fonts. A lot of businesses treat their current website like a template to be improved. But if you’re redesigning based on what’s already there, you’re not solving anything, you’re preserving the problem.

In discovery, we audit what’s live. But we’re not looking for what to keep, we’re looking for what to leave behind. What’s underperforming? What’s unclear? What’s been patched over too many times?

That starts with gaining insights from real use. What do users search for that they can’t find? What content gets traffic but never converts? What pages take up space but serve no measurable purpose? Every element, navigation, page hierarchy, search, is on trial.

We took this approach with Catch’s early public-facing site. On the surface, the structure made sense: location filters, lake listings, a few help articles. But when we ran a full analysis during the discovery phase, it became clear that most users were navigating via search, not structure. And the copy wasn’t written for anglers, it was written for Google.

The solution wasn’t just technical. It was editorial. We rebuilt the information architecture from scratch, restructured the content, and wrote in a voice anglers actually recognised. The result? A simplified flow, improved search performance, and a more intuitive, user-friendly product.

That’s why we build low fidelity wireframes during discovery, not to lock in design, but to pressure-test logic. We map what content belongs where, what needs to be merged or deleted, and what’s missing entirely.

Your current site is a lesson. Discovery is where you choose whether to learn from it, or repeat it.ck for a health and wellness website made the brand more relatable and trustworthy to its audience, leading to increased user engagement and loyalty.

That’s why discovery always includes a brutal but necessary step: defining what success actually looks like. Because if we don’t align around website goals now, we’ll argue about them later, when it’s more expensive, more political, and harder to fix.

Some teams want brand visibility. Others want sales-ready leads. Some want users to self-qualify. Others want them to convert fast. There’s no wrong answer, but there has to be one.

In a recent project for a SaaS platform, we uncovered three competing visions during discovery: marketing wanted form fills, product wanted trial sign-ups, and the CEO wanted analyst credibility. That tension wasn’t going away. So we mapped out how each of those outcomes could be served, but made sure only one was prioritised per section of the site. Discovery became the alignment tool, not just the insight phase.

We also look closely at business objectives and how they ladder into digital. Is this project about reducing support calls? Improving close rate? Launching in a new market? Discovery links those business-level needs to web outcomes that can actually be measured, whether that’s conversion rates, sales pipeline impact or content adoption.

From there, we define the desired outcomes of the website. That includes not just what users do, but how they feel. Reassured? Curious? Confident enough to take the next step?

Discovery is where we kill off features-for-feature’s-sake thinking. Every page, every module, every call-to-action has to earn its place. And by the time the first layout hits the screen, the team already knows what that screen is there to achieve.

Without that clarity, projects drift. With it, they perform.

Most personas are too polite. They’re filled with vague hopes and soft attributes like “motivated by convenience” or “tech-savvy.” But good discovery doesn’t create fictional users, it introduces you to the real ones.

This is where user interviews, behaviour data and frontline feedback all collide. We don’t start with stock-photo demographics, we start with friction. What are users trying to do but can’t? What workarounds have they created? What’s their real intent behind that bounce?

At Ronins, we’ve had projects where the target audience on paper was miles away from the one that actually used the product. In one healthcare case, the client was designing content for first-time users, but it was repeat users who drove most interaction. That insight shifted the tone of the site from explanatory to supportive, and dramatically improved engagement.

During the Catch discovery phase, we went deep on identifying different user personas. Not just ‘anglers’ as a block, but nuanced groups: solo hobbyists, family day-trippers, competition fishers, even night anglers booking around shift patterns. Each had different needs, motivations, and tolerance for complexity.

User behaviour told us where they clicked. But talking to them told us why they stopped. That led to clearer journeys, shorter forms, and content that didn’t just inform, it anticipated.

We also mapped the conversion funnel with these audiences in mind. What’s the minimum amount of information a new user needs before they’re ready to act? What builds trust fastest? What disrupts it?

Discovery isn’t about guessing who your users are. It’s about listening, validating, and giving those users a site that fits their context, not just your brand’s. Because when you get that right, conversion isn’t something you chase. It’s something that happens.

Discovery is where we map problems. Design is where we solve them. But if that bridge is broken, everything unravels, wireframes go off-piste, dev sprints derail, and the “final product” ends up answering a question no one’s asking.

That’s why we treat the design process as an extension of discovery, not the start of something new, but the continuation of something already understood.

We don’t launch into visuals. We begin with structure. What does the site need to do, and in what order? That means translating insights into content hierarchy, journeys, and functional flow. Which page needs to reassure? Which one needs to convert? Which should load fastest?

And just as importantly, what needs to be left out?

The development process starts here too, long before code. Tech choices, third-party integrations, platform constraints, SEO implications, hosting decisions… they all need early visibility. Otherwise, someone will suggest a CMS that can’t handle multilingual content, or a design interaction that breaks accessibility.

One example: on a recent project involving booking logic across international time zones, discovery surfaced a technical requirement we might have otherwise missed, calendar slots had to flex dynamically based on user location and the fishery’s own management tools. That insight changed how the dev team approached the architecture, days before anything was committed to code.

This is also where we define functionality. Not in vague “we want a cool dashboard” language, but in use-case terms. What action needs to happen? What does the user expect to see? What happens next?

Everything we design is anchored to outcomes. And every outcome is validated during discovery, not invented in isolation.

When that process is tight, delivery runs lean. There’s less double-handling. Fewer misfires. And far more confidence, on both sides of the table.

Founders often come in thinking discovery slows things down. In reality, it’s the fastest route to a site that works. Why? Because it prevents guesswork, reversals, and six rounds of “can we just tweak the homepage?” after launch.

When done well, discovery helps generate leads earlier, because we’re designing for the right buyer journey, with the right friction removed. The site gets to work faster, because the guesswork’s already handled.

Take the Ronins project for a large education provider. Their existing site looked clean, but lead flow was weak. In discovery, we uncovered that course content was too deep in the structure, and their sign-up form was 11 fields too long. We redesigned their lead funnel around user priority, not organisational hierarchy, and they saw double-digit growth in sign-ups within 60 days of launch. The site didn’t just look better, it sold harder.

That’s the hidden power of discovery. It doesn’t just set up the design. It defines how you acquire, qualify, and convert attention into business.

It also saves internal energy. Clear briefs mean faster stakeholder sign-off. Aligned goals mean less back-and-forth in QA. And when you’ve had tough discussions early, you don’t get political surprises at the eleventh hour.

Discovery links every element, copy, UX, SEO, tech stack, back to a measurable outcome. More qualified leads. Higher engagement. Shorter sales cycles. Increased trust.

If you want a site that functions properly, performs commercially, and builds momentum, not friction, then discovery isn’t the expensive phase. It’s the high-leverage one.

By the end of a well-run discovery, the client often looks relieved. Not because the site is built yet, but because, for the first time, they can see the shape of it. The risks are visible. The unknowns are named. The next steps feel real, not theoretical.

When you get this phase right, it sets the tone for everything. Approvals go faster. Decision making gets easier. The client stops reacting and starts leading. Not because we sold them something clever, but because we helped them see clearly.

We’ve had CEOs tell us, “This is the first time I’ve felt confident briefing our board on the website.” Not because the homepage was finished. But because they could finally articulate the why behind the what.

One senior leader described it like this: “Before discovery, we had content. After discovery, we had conviction.”

And that’s really the goal. Not just to produce a plan, but to build shared belief. Because a confident team delivers better work. A clear client is a better collaborator. And a well-defined problem? That’s half the solution.

The biggest compliment we get isn’t about the code or the visuals, it’s when a client says, “That session changed how we think.” That’s when we know it worked. That’s when discovery paid for itself.

If you’re planning a new website, product, or digital platform, and you’re serious about getting it right, let’s start with a conversation. Not a quote. Not a pitch. Just clarity.

Because once you know what’s really needed, everything else moves faster, sharper, and with far less friction.

Drop me a message or connect on LinkedIn. Let’s see what your real brief might be.