Type at least 3 letters to search

The Website Design Process Most Agencies Show You Is Wrong

Yevhen Borovoi

Founder | CEO

LinkedIn Facebook Instagram Behance

Chapters

    Website design process: UX, data, SEO and CRM decided together in one architecture before design

    UX is decided long before the first screen is drawn.

    THE DIAGRAM

    Five Boxes and Four Arrows

    Open the process page of almost any web studio and you will find the same diagram: analysis, design, coding, development, SEO. The colours and icons change, the sequence rarely does. It reassures clients because it makes a complicated project look orderly: first we think, then we draw, then we build, and finally we promote.

    There is nothing wrong with having stages. Research takes time, design needs a direction and a site can't launch before it is built. The trouble starts when the diagram suggests that each stage owns its decisions and can hand them over without affecting the work that follows. A designer approves a catalogue page before anyone has confirmed what data powers its filters. An SEO specialist arrives after launch and finds that every filter combination has created another URL. The CRM gets connected at the end, when forms and WhatsApp already scatter one customer's history across different places.

    The issue is not the order in which people work. It is the order in which decisions are made. Some decisions touch design, data, development, search and sales from day one, whether the project plan admits it or not.

    We saw this clearly while planning the new website for Schoeffel, the pearl house founded in 1921. Below I use that project to answer the questions a client usually has when ordering a website: what to order first, what you should receive at each step, what the agency will need from you, and how to check an agency's process before you sign.

    In short

    • Order decisions before pictures. The first thing to buy is a conversation about the business, then an architecture where UX, data, SEO, the CRM and analytics are decided together.
    • Before any visual design you should see the site map and URL rules, wireframes of every template, the states nobody likes to draw (empty results, sold out, no delivery) and a list of data the agency needs from you.
    • SEO starts at the architecture stage, not after launch. URL structure, locales and which pages get indexed shape the templates themselves.
    • Design comes last, and every choice in it should have a stated reason.
    • The depth scales with the project: a five-page site may need one session and a few pages of decisions, a multi-market catalogue needs much more.

    HANDOFFS

    What Gets Lost Between Stages

    Imagine a luxury jewellery catalogue with a restrained grid, an elegant filter panel and beautifully shot product cards. The client approves it because it looks right. The questions appear only when development starts. Where does each filter value come from? What happens when a combination returns nothing, when one size is sold out, or when the customer is in a country you don't ship to?

    If nobody considered those states, somebody improvises. The developer guesses, the designer redraws approved screens, or the team discovers that the product data can't support what the mockup promised. The expense comes from asking these questions after the design has made them costly to answer.

    The same happens outside the interface. If filter combinations generate URLs without an indexing strategy, a catalogue can produce a vast number of near-identical pages. Google describes this in its guidance on faceted navigation: filter combinations can create enormous URL spaces and use up crawling resources. Fixing that after the templates are approved means touching them again.

    The CRM is usually considered last of all. A form sends an email, WhatsApp chats stay on a manager's phone, appointments live in another system. The business knows that someone made contact, but not that the same person spent twenty minutes comparing pearl sizes the day before asking about a high jewellery piece.

    The expense comes from asking the questions after the design.

    SCHOEFFEL

    One Architecture Instead of Five Deliverables

    For Schoeffel we wrote a working specification of 108 pages: 13 page templates and 61 blocks. Each block is described the same way: what it contains, how it behaves, which states it has, what data it needs and what the decision is based on. The document doesn't get filed away when design begins. Designers, developers, the SEO specialist and whoever sets up the CRM work from the same pages.

    The first wireframes were deliberately plain: grey shapes, real English labels, no brand colours or fonts. Colour at that stage would have made the pages look more finished than the decisions behind them. The design direction, the design system and the home page in design came later, in the same document, after the structure was agreed.

    What matters for the client is that every discipline sees the same decision in context. The developer doesn't have to guess what a filter means from a mockup. The SEO rules sit next to the template they affect. The CRM fields are described inside the form that collects them, together with what happens if sending fails.

    Not every project needs 108 pages. An international store with several markets, three price tiers and a high jewellery line has far more dependencies than a brochure site for a local firm. The document should fit the project, but the principle stays: decide how the site works before deciding how it looks.

    MILLIMETRES

    One Finding, Four Decisions

    Before drawing the catalogue, we reviewed thirteen jewellery and luxury websites, five of them pearl specialists: Mikimoto, TASAKI, Paspaley, Yoko London and Kamoka. For those five we built a matrix of 24 possible ways into a pearl catalogue, from product type and pearl type to colour, occasion, bridal, gifts by price and made to order. Mikimoto covered 17 of them, Paspaley 14, Yoko London 13, Kamoka 12 and TASAKI 10. Those numbers describe our matrix, not a ranking of the brands.

    One entry was missing from all five: filtering by pearl size in millimetres. That gap mattered for Schoeffel. Buyers who know pearls think in sizes, and the difference between a 6.5 mm and an 8 mm strand changes how it looks and what it costs. Size is only one of the factors behind a pearl's value (GIA also lists shape, colour, lustre, surface, nacre and matching), but it is the one a buyer can use to narrow a search.

    So size became the main facet of the filter: steps of 0.5 mm up to 9 mm, which is how Akoya pearls are bought, and 1 mm above that for South Sea pearls. Next to it we planned a small "What size suits me?" helper that shows pearls at life size on most screens, so a less experienced buyer doesn't need the terminology to begin.

    That one finding immediately became four decisions. A data decision: every product variant needs a minimum and maximum pearl size in the catalogue. A development decision: facets combine with AND between them and OR inside one, and a product with several variants matches when any one variant fits all selected facets. An SEO decision: each way into the catalogue is a landing page with its own title and introduction. And a business dependency, written plainly in the document: if Schoeffel can't provide the size for every variant by launch, the millimetre filter doesn't launch. That beats approving a beautiful filter and discovering months later that the catalogue can't feed it.

    One research finding became a feature, a data rule and a launch condition.

    ZERO RESULTS

    The States Nobody Draws

    The most useful sentence in the Schoeffel specification is a short one: zero results is not an acceptable state. In most catalogues an empty result gets a stock illustration and the words "No products found". For a jewellery house, that page belongs to a customer who has just told you exactly what they want.

    So the filter hides any value that would lead to nothing with the current selection. If a customer picks Akoya and 7.5 to 8.5 mm, Tahitian disappears from the list. A value the customer has already chosen is never hidden, because that would feel like the site arguing with them.

    If an empty result happens anyway, the page suggests the nearest ranges with their counts and offers a specialist. The WhatsApp message is pre-filled from the filters, for example "Looking for: Akoya, 7.5–8.0 mm, Opera length", and the request reaches the CRM with those parameters. An analytics event called zero_results records the combination, and over time those records become a list of what the assortment is missing.

    The same care goes into a sold-out variant, a country without delivery, or a piece whose price moves it into the high jewellery tier while it sits in someone's bag. Each state has its own text and behaviour in the document. As a client, ask to see these states before development starts: they show whether the agency has thought past the happy path.

    SEO AND AI

    SEO and AI Answers Belong in the Architecture

    In the familiar diagram SEO comes after development, as if it were a layer added to a finished site. Content, monitoring and improvements do happen later. But URL structure, locale rules and indexability shape the templates themselves.

    In the Schoeffel document the URL section comes before navigation and before any template. Each market and language has its own prefix, such as /us-en/ and /gb-en/. Each locale carries a canonical link to itself and hreflang links to the others, because the text is the same and only prices differ; Google explains the mechanics in its notes on localized versions and canonical URLs. Filter and sort URLs are noindex, follow, with a canonical link to the clean category, and the parameter order is normalised so one selection always has one address.

    Some rules sit right on the border between SEO and the catalogue. A combination page such as "Akoya necklaces" is indexed only when it holds at least six products, so thin pages don't appear by accident. A product keeps one URL however the customer reached it. Product names are generated from the catalogue fields, so the specification in the name is identical everywhere and changes when the customer picks another variant.

    The same architecture serves AI answers. Knowledge pages answer questions people actually ask in WhatsApp and forms: how to choose a strand, how Akoya differs from South Sea and Tahitian pearls, what size suits me, how often a strand should be restrung. Each has a named author. Their metric is written down too: visits from search, clicks through to products and a repeated check of visibility in AI answers. The research also shaped what we left out. Lustre and surface matter a great deal in pearls, but they aren't filters, because people don't filter by a word they don't yet understand. They learn it on the product card and a separate quality scale page. We wrote more about this approach in SEO, AEO and GEO: Amplifiers, Not Engines.

    ONE CUSTOMER

    The CRM Comes Before the Screens

    A customer may ask a question from a product card, book an appointment, contact a specialist about a high jewellery piece, write in WhatsApp from a knowledge page or reach out after an empty filter. These are different moments of one journey and should end up in one customer record.

    For each channel the Schoeffel specification lists what the customer types and what the site adds: the product and variant, the page, and the campaign, market and language of the visit. A specialist then sees that someone first compared 8 mm strands, then asked about a high jewellery piece and later booked a viewing.

    Planning this early changes the interface. Every WhatsApp button carries a prepared message with the page and product, each form asks only for the fields its purpose needs, and a failed submission has a defined fallback. We describe the same logic for internal systems in The Software Should Fit the Business.

    LABELS

    Observation, Hypothesis, Decision

    Research produces knowledge of different strength, and the Schoeffel document says which is which. Every decision carries a label:

    LabelWhat it means
    ObservationSeen on a competitor's site, most of it checked in the browser
    HypothesisAn assumption about the buyer, to be checked with analytics after launch
    Client decisionApproved by Schoeffel: terms, prices, assortment
    Agency decisionOur design decision, open to challenge until design starts
    Add-onOutside phase 1, waiting for data or a separate agreement

    This saves arguments. When a client disagrees with a block, everyone can see whether the discussion is about a fact, a bet or a preference. A hypothesis gets an analytics event and a review date instead of a debate: six to eight weeks after launch we will decide from the data whether small categories need product counts, whether a colour facet is worth adding and whether the size ranges are too fine.

    Every template also has the same short passport: why the page exists, where people come from, what they should do, where they go next and how we measure it. As a client, you can judge the design against that passport rather than against taste.

    WAITING

    The Hardest Part Is Waiting

    There is a reason the five-box diagram survives: clients want to see something. They have signed a contract and paid an advance, and for weeks the agency sends questions, research notes and grey wireframes. A polished mockup feels like progress in a way a data model never does.

    That wish is fair, and no client should trust a black box for weeks. The answer is to show real work early: the competitor review, the navigation options, the wireframes of every template, and a working prototype once the structure is agreed. On Schoeffel the home page was designed only after that, when the team could explain what each block was for.

    A mockup drawn before the decisions is a promise the build may not keep. It shows a filter the data can't support, a product card with no sold-out state, a home page whose blocks have no clear role. When the constraints surface, the approved design has to change, and normal discovery starts to look like the agency going back on its word.

    THEN DESIGN

    Design Comes Last and Explains Itself

    The design direction for Schoeffel is quiet luxury: a white field, pearls in studio light and blue only in details, continuing the brand's existing landing page. The system has practical rules, such as one piece per screen with no sliders, and millimetres, years and prices set large because that is what this buyer reads first. It also lists what to avoid, including blue fills across whole sections and pill-shaped buttons as the main call to action outside transactions.

    Visual judgement still matters, and a weak design can ruin a strong architecture. The difference is that the design has something to respond to. We also record what changed between wireframe and design, and why. The first screen moved from a single product to a campaign, because the campaign sets the tone of the house and the products follow right below. The home page entries were split by intention (type of piece, collection, rarity) so each leads into its own scenario. The service block became a strip available on every screen, so help is never at the bottom of a long page.

    Design like this can be challenged, because every choice has a reason, and it survives development better, because the people who build it were involved before it was approved. We wrote about the same idea from the visitor's side in Design You Don't Notice.

    WHAT TO ORDER

    What to Order, and in What Order

    Drawn honestly, the process is a loop rather than a line. Research feeds one architecture where UX, data, SEO, the CRM and analytics are decided together. Wireframes come out of it, design comes out of the wireframes, development builds what has been agreed, and after launch the analytics check the hypotheses and feed the next round.

    Two ways to draw a website processTHE USUAL DIAGRAMAnalysisDesignCodingDevelopmentSEOEach step waits for the previous one. SEO and the CRM arrive when the templates are already approved.HOW THE DECISIONS ACTUALLY GET MADEResearchbusiness, buyer, marketOne architecturedecided together, before designUX, scenarios and statesData and catalog logicURLs, SEO and AI visibilityCRM and requestsAnalytics eventsWireframesstructureDesignwith reasonsBuildno guessingMeasureafter launchhypotheses go back into the architectureDevelopment and SEO take part in every decision from the first week.

    For a client, that turns into a practical sequence. Each step has a deliverable you can hold the agency to, and a part that depends on you.

    StepWhat you should receiveWhat you decide or provide
    1. Strategy conversationGoals, audience, markets, competitors, scope and a rough budget for each stepBusiness goals, who buys and why, what success looks like
    2. ArchitectureSite map and URL rules, every template with its purpose and metric, states, data requirements, request and CRM flows, analytics eventsProduct data, markets and currencies, who answers requests
    3. Wireframes and prototypeGrey layouts of every template and a clickable prototype of the structureApproval of structure and content before any colour
    4. DesignA design system, key screens, and a note of what changed from the wireframes and whyBrand assets, photography, final texts
    5. DevelopmentA working site built to the agreed rules, tested on real dataContent entry or migration, access to accounts and integrations
    6. Launch and measurementAnalytics, the first review of hypotheses after six to eight weeksDecisions on what to change based on the data

    The scale changes with the project. A five-page service site may cover steps 1 and 2 in a single strategic session and a few pages of decisions. A multi-market catalogue with price tiers and complex variants needs a full specification. Either way, the order of decisions is the same, and it is also how we run our UI/UX design work. For an existing site the first step is different: watch what people actually do before changing anything, as we describe in Do You Need a Website Redesign?

    FROM YOU

    What the Agency Will Need From You

    The last section of the Schoeffel specification is a table of what we need from the client, where each input is used, and what happens if it isn't ready by launch. It is one of the most useful pages for the client, because it turns vague dependencies into dates and consequences. For most websites the list looks similar:

    • Product or service data in a consistent structure. On Schoeffel, without the size of every variant there is no millimetre filter.
    • People and hours. Who answers WhatsApp and forms, in which time zone and how fast. Without that, requests go unanswered.
    • Markets, currencies and languages. If they aren't decided, the site launches with one locale.
    • Photography and texts. Without them the design is tested on placeholders.
    • Brand decisions such as the logo, which affect the header, footer and packaging.
    • Platform choices: payment provider, calendar for bookings, the CRM itself.

    Ask your agency for this list early. A good one will give it to you during the architecture stage, with a fallback for each item, so a missing input delays one feature rather than the whole launch.

    BEFORE YOU SIGN

    Questions to Ask an Agency Before You Sign

    Most process pages look alike, so the useful test is how an agency answers specific questions. Here are the ones I would ask, with what a good answer sounds like.

    • When do you decide URL structure and SEO rules? Good answer: during the architecture, before design.
    • Who designs the empty, error and sold-out states? Good answer: they are part of the specification, with their own text.
    • What will you show us before the visual design? Good answer: research, wireframes of every template and a prototype.
    • What data do you need from us, and by when? Good answer: a written list with dates and fallbacks.
    • How will requests from forms and WhatsApp reach our CRM? Good answer: one customer record, with the page and product attached.
    • How will we know the design works? Good answer: each template has a purpose and a metric, and hypotheses are reviewed after launch.
    • What happens after launch? Good answer: a review date, analytics events and a plan for the first round of changes.

    If the answers all point to "later" or "the designer will handle it", you are buying the five-box diagram.

    Decide how it works before you decide how it looks.

    FAQ

    Frequently Asked Questions

    What should I order first when building a website?

    A conversation about the business, its customers and its markets, followed by the architecture: site map, URL rules, templates, data and request flows. Visual design comes after those are agreed.

    Can I order only the design?

    You can, but then someone else has to make the architecture decisions, and the design may need changes once they are made. If you already have a clear specification from another team, design-only work makes sense.

    Is an architecture stage worth paying for on a small site?

    For a small site it can be one working session and a few pages of decisions. It usually costs less than redrawing approved screens or rewriting templates later.

    When should SEO start on a new website?

    At the architecture stage, because URL patterns, locales, indexability and the purpose of landing pages shape the templates. Content and promotion can come later.

    Sources

    Planning a new website? Let's start with how it should work.

    Book a Strategic Session

    UI/UX Design