Every failed Shopify project we have ever seen shares the same root cause: the team started building before they understood what they were building. It sounds obvious. It happens constantly. Brands come to us after spending months and thousands of pounds with an agency that jumped straight into design without ever asking the fundamental questions about business goals, customer behaviour, or technical requirements.
That is why we treat discovery as a non-negotiable phase. Not as a box-ticking exercise or an upsell, but as the foundation that determines whether a project succeeds or fails. Over two decades of building ecommerce stores, we have refined this process into a structured, repeatable methodology that consistently delivers better outcomes.
This article walks through our entire discovery process in detail. Whether you are about to start a Shopify project with us or with another agency, understanding what good discovery looks like will help you evaluate whether your agency is setting you up for success.
Why discovery matters more than you think
The cost of fixing a problem increases exponentially the later it is discovered. A requirement missed during discovery might cost an hour to address in the scoping document. The same requirement discovered during development could cost days. Found after launch, it could cost weeks and significant revenue.
We have tracked this across dozens of projects. Builds that include a proper discovery phase consistently come in on budget and on time. Builds that skip discovery — whether because the client wanted to move fast or the agency did not insist — almost always experience scope creep, timeline slippage, and budget overruns.
Discovery is not about slowing things down. It is about going fast in the right direction. Every hour spent in discovery saves three to five hours during the build phase.
There is also a strategic dimension. Discovery is where we uncover opportunities that the brand had not considered. Perhaps their competitor analysis reveals a gap in the market that the store can exploit. Perhaps the user research highlights a friction point in the current journey that, once resolved, could materially improve conversion rates. These insights only emerge when you invest the time to look for them.
If you are choosing a Shopify agency in the UK, one of the most telling questions you can ask is about their discovery process. Agencies that skip it are typically prioritising throughput over quality. They want to start billing as quickly as possible. Agencies that insist on it are investing in the project's success.
What a Shopify discovery process actually is
Discovery is a structured investigation phase that happens before any design or development work begins. Its purpose is to answer three fundamental questions:
- What does the business need? Revenue targets, growth plans, operational constraints, brand positioning.
- What do the customers need? How they shop, what they value, where they get frustrated, what drives loyalty.
- What does the technology need to do? Integrations, functionality, performance requirements, scalability considerations.
The output is a comprehensive project brief that serves as the single source of truth for the entire build. Every design decision, every technical choice, every prioritisation call traces back to what was defined during discovery.
Our discovery process typically spans one to three weeks, depending on the complexity of the project. For a straightforward Shopify development project with a clear scope, one week is usually sufficient. For complex builds involving platform migrations, multiple integrations, or bespoke functionality, we allocate two to three weeks to ensure nothing is missed.
Phase 1: Stakeholder interviews
Every discovery begins with conversations. Not with a questionnaire sent by email, but with structured interviews conducted face to face or over video call. There is a reason for this: questionnaires capture what people think is important. Interviews uncover what actually is important, including things the stakeholder had not thought to mention.
We interview everyone who has a stake in the project's success. That typically includes:
- The founder or managing director — for strategic vision, brand positioning, and commercial objectives
- The marketing team — for campaign requirements, content strategy, and channel-specific needs
- The operations team — for fulfilment workflows, inventory management, and process constraints
- Customer service — for common complaints, frequently asked questions, and pain points they hear daily
- Finance — for budget parameters, payment processing requirements, and reporting needs
Each interview follows a structured format but allows space for tangential discoveries. Some of the most valuable insights come from throwaway comments: "Oh, and our wholesale customers always complain about..." or "We tried this once but the old platform could not handle it."
We document every interview and synthesise the findings into a stakeholder alignment document. This surfaces any conflicting priorities early — and there are always conflicting priorities. Better to resolve them during discovery than to discover the marketing team and operations team have opposite expectations two weeks before launch.
What we ask in stakeholder interviews
Our interview framework covers five key areas:
- Business goals: What does success look like in 6, 12, and 24 months? What are the revenue targets? What is the growth strategy?
- Current pain points: What is not working with the current setup? What are the biggest operational bottlenecks?
- Customer understanding: Who are your best customers? What do they value most? Why do people choose you over alternatives?
- Technical requirements: What systems need to integrate? What functionality is essential versus nice to have?
- Brand and content: What is the brand voice? What content assets exist? What photography or video is available or needed?
Phase 2: Competitor and market audit
Understanding your competitive landscape is essential for positioning your store effectively. We audit between five and ten competitor stores, depending on the market, evaluating them across multiple dimensions.
This is not just about noting what they look like. We analyse:
- Performance: Page speed scores, Core Web Vitals, mobile responsiveness
- User experience: Navigation patterns, product page layouts, checkout flows, mobile experience
- Content strategy: How they present products, what educational content they offer, how they use social proof
- SEO positioning: What keywords they rank for, their domain authority, their content architecture
- Technology: What platform they use, what apps and tools they employ, how they handle integrations
- Conversion tactics: Upselling, cross-selling, urgency, trust signals, email capture
The objective is not to copy what competitors are doing. It is to identify where they are strong (so we can match or exceed their standard), where they are weak (so we can differentiate), and where there are gaps in the market that your brand can own.
We present the competitor audit as a structured report with specific, actionable recommendations. Not "their site looks nice" but "three of five competitors have implemented a size guide tool on product pages, which reduces returns by an average of 15-20% according to industry benchmarks — we should consider this for the build."
This research also informs the migration planning if the project involves moving from another platform. Understanding what competitors have done well helps us ensure the new Shopify store does not lose ground during the transition.
Phase 3: User research and persona development
The best ecommerce stores are built around customer behaviour, not internal assumptions. During discovery, we invest significant time understanding who your customers actually are and how they actually shop.
Our user research methodology includes:
Analytics review
If the brand has an existing store, we dive deep into the analytics. We look at traffic sources, device split, bounce rates by page, conversion funnels, cart abandonment patterns, and user flow data. This tells us what customers are actually doing, which often differs dramatically from what the team assumes they are doing.
We pay particular attention to mobile behaviour. In most ecommerce verticals, 65-80% of traffic comes from mobile devices, yet conversion rates on mobile are typically 40-60% lower than desktop. Understanding why — and designing specifically to address those mobile friction points — is a significant opportunity.
Customer feedback analysis
We review customer service tickets, product reviews, social media comments, and any survey data the brand has collected. This qualitative data reveals emotional drivers and friction points that analytics alone cannot surface.
Common themes we look for include complaints about navigation ("I could not find what I was looking for"), product information gaps ("I was not sure about sizing"), trust concerns ("I was not sure if the brand was legitimate"), and checkout friction ("The checkout process was too complicated").
Persona development
Based on the analytics and qualitative research, we develop two to four user personas that represent the brand's core customer segments. These are not fictional characters with arbitrary names. They are data-backed profiles that describe:
- Demographics and psychographics relevant to purchasing behaviour
- Primary motivations for shopping with the brand
- Common objections and concerns that need addressing
- Preferred browsing and purchasing patterns
- Device and channel preferences
- Price sensitivity and decision-making process
These personas become reference points throughout the build. When a design decision needs to be made — should we show reviews above or below the fold? Should the size guide be a modal or an inline element? — we refer back to the personas to guide the choice.
Phase 4: Technical scoping and architecture
With the business requirements and user needs defined, we move into technical scoping. This is where we translate what the store needs to do into how it will do it.
Platform assessment
For brands already committed to Shopify, we determine which plan is appropriate. Shopify Basic, Shopify, or Shopify Plus — the right choice depends on transaction volume, feature requirements, and growth trajectory. Getting this wrong can mean paying for features you do not need or, worse, lacking features you do need.
Integration mapping
Most ecommerce stores do not exist in isolation. They connect to ERPs, warehouse management systems, accounting software, CRM platforms, email marketing tools, and more. During discovery, we map every integration, evaluate the available APIs, and identify potential technical challenges.
This is where projects most commonly go wrong when discovery is skipped. "Oh, we also need to connect to our ERP" is a sentence that can add weeks to a timeline when it appears mid-build. During discovery, we identify these requirements, evaluate the complexity, and account for them in the project plan.
App evaluation
We take a deliberately conservative approach to Shopify apps. Every app adds JavaScript, increases page load time, and introduces a dependency on a third party. Our philosophy is to build custom functionality for anything critical to the business and only use apps for non-critical, commoditised features.
During discovery, we evaluate the functionality requirements against three options:
- Native Shopify: Can Shopify's built-in features handle this without any additions?
- Custom build: Is this critical enough to warrant bespoke development?
- App: Is there a well-maintained, performant app that handles this reliably?
This evaluation is documented in a technology stack recommendation that the client reviews and approves before we proceed.
Performance budgeting
We set performance targets during discovery, not after the build is complete. This means defining acceptable thresholds for Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, and overall PageSpeed scores. These targets inform every technical decision that follows — from image optimisation strategy to JavaScript loading approach to font selection.
If a feature request would push the store beyond its performance budget, we flag it immediately. There is always a trade-off between functionality and speed, and the right time to make that trade-off decision is during discovery, when the implications can be properly evaluated.
Phase 5: Wireframing and information architecture
Before any visual design work begins, we define the structural blueprint of the store. This phase determines what content appears on each page, in what order, and how users navigate between them.
Sitemap development
We create a comprehensive sitemap that defines every page, collection, and content section. For stores with large product catalogues, this includes the taxonomy structure — how products are categorised, tagged, and filtered. A well-structured taxonomy is essential for both user navigation and collection page SEO.
Wireframing key pages
We wireframe the critical pages that drive the majority of conversions:
- Homepage: Hero positioning, value proposition hierarchy, product showcase strategy, trust signals
- Collection pages: Filter and sort functionality, product card layout, pagination approach
- Product pages: Image gallery, product information architecture, variant selection, add-to-cart placement, social proof positioning
- Cart: Upsell and cross-sell strategy, shipping calculator placement, trust reassurance
- Navigation: Menu structure, mobile navigation patterns, search functionality
Wireframes are deliberately low-fidelity. They show layout and content hierarchy without visual design, so the conversation stays focused on structure and user experience rather than colour choices. This approach, applied consistently across every project we undertake as a web design agency, prevents the common trap of spending weeks debating aesthetics before the functional structure is right.
Content requirements
Discovery is also where we define what content the brand needs to prepare. Photography, copywriting, product descriptions, policy pages, FAQ content — all of this needs to be ready before development begins. Content delays are the single most common cause of project timeline slippage, and they are entirely preventable with proper planning.
We provide content briefs that specify exactly what is needed, in what format, and by what deadline. This includes image specifications (dimensions, file formats, resolution), copywriting guidelines (tone of voice, word counts, SEO requirements), and a content calendar tied to the project timeline.
Phase 6: The project brief and timeline
All of the discovery work culminates in a comprehensive project brief. This document is typically 15 to 30 pages and serves as the contract between expectations and delivery. It includes:
- Executive summary: Project objectives, success metrics, and key constraints
- Stakeholder alignment: Confirmed priorities, resolved conflicts, and decision-making authority
- User personas: Data-backed customer profiles that guide design decisions
- Competitor insights: Key findings and strategic recommendations
- Sitemap and wireframes: Structural blueprint for the entire store
- Technical specification: Platform configuration, integrations, custom development requirements
- Content requirements: What is needed, in what format, and when
- Project timeline: Phase-by-phase breakdown with milestones and review points
- Fixed-price quote: A detailed cost breakdown for the build phase
The brief is reviewed in a presentation meeting where we walk through every section, answer questions, and make adjustments. Once approved, it becomes the reference document for the entire project. Any requested changes during the build are evaluated against the brief — if it was in scope, it is included; if it is new, it is assessed and quoted separately.
This approach eliminates the ambiguity that causes disputes between agencies and clients. When QA testing the store before launch, we test against the specifications defined in the brief. There is no room for "I thought it would work differently" because the brief documents exactly how it will work.
What discovery prevents
The value of discovery is best understood through what it prevents. Here are the most common project failures that proper discovery eliminates:
Scope creep
Without clear documentation of what is in scope, every conversation becomes a negotiation. "Can we also add..." becomes a recurring theme, and the project balloons beyond its original timeline and budget. Discovery defines scope precisely, so everyone knows what is included and what constitutes a change request.
Misaligned expectations
The client pictures one thing, the designer envisions another, and the developer builds something different. Discovery aligns all parties around a shared vision, documented in wireframes and specifications that leave no room for misinterpretation.
Technical surprises
The integration that seemed straightforward turns out to require a custom middleware layer. The app that was supposed to handle subscriptions does not support the brand's specific billing model. These surprises are devastating mid-build but easily identified during discovery.
Content bottlenecks
Development is complete, but the store cannot launch because product photography is not ready, or product descriptions have not been written, or the returns policy has not been approved by legal. Discovery identifies all content requirements upfront and ties them to the project timeline.
Budget overruns
When a project is properly scoped during discovery, the quote is based on a detailed understanding of requirements. When discovery is skipped, the quote is based on assumptions — and assumptions are almost always wrong. The result is change orders, disputed invoices, and a damaged relationship.
We have written extensively about the importance of performance optimisation and SEO planning in the context of Shopify builds. Both are areas where discovery work directly prevents costly rework later in the project.
How discovery fits into the broader project
Discovery is not an isolated activity. It connects directly to every subsequent phase:
| Discovery output | How it informs the build |
|---|---|
| User personas | Guide design decisions, content tone, and UX priorities |
| Competitor audit | Informs feature prioritisation and differentiation strategy |
| Technical specification | Defines the development roadmap and technology choices |
| Wireframes | Serve as the blueprint for visual design and development |
| Content requirements | Enable parallel content production during the build phase |
| Performance budget | Sets measurable targets for the QA and testing phase |
Every phase builds on the foundation laid during discovery. Skip the foundation, and everything built on top is unstable.
When to invest more in discovery
Not every project requires the same depth of discovery. Here is a general guide:
- Light discovery (1 week): Theme customisations, minor redesigns, single-feature builds where the scope is clear and limited
- Standard discovery (2 weeks): Custom Shopify builds, new store launches, and projects with moderate integration requirements
- Deep discovery (3+ weeks): Platform migrations, Shopify Plus builds, complex multi-channel setups, and projects with enterprise-grade integration requirements
The investment in discovery always pays for itself. A £3,000 discovery phase on a £25,000 build routinely prevents £5,000 to £10,000 in rework costs. That is not a theoretical benefit — it is a pattern we have observed consistently across years of project delivery.
If you are evaluating agencies, ask them to walk you through their discovery process. The level of detail in their answer will tell you everything you need to know about their approach to project delivery. And if you would like to experience our discovery process first-hand, start a conversation with us. We will show you exactly what it looks like and how it sets your project up for success.