A website project does not start with choosing a colour or installing a theme. It starts with turning a vague request such as “we want a corporate site” into a list of decisions someone can approve. When the team writes down the audience, the job, the page, the content, the owner and the success metric before anything is built, most of the expensive back-and-forth disappears.
What should the initial request produce?
Define one landing page per service — a page that answers the customer’s main question and carries the next action. If the landing page and its success event are not written in a single sentence, the project becomes a collection of personal tastes from day one. Record it before choosing a colour, a theme or a plugin, because each of those choices creates a cost of reversal later.
The six-column page matrix
Do not start the sitemap from the manager’s mental menu list. Start from the paths a visitor walks to reach contact, purchase or information. This does not cut the page count on purpose; it draws a line between what a visitor needs and what the company likes to show. A good roadmap can still end with one extra page — if that page unblocks a decision point.
Content first or looks first?
Gather the real copy before you design the blocks. Service name lengths, credentials and the answers to customer questions routinely change the first draft. View the actual text of every section on a small phone before signing it off. Service titles, city names, people’s names and long addresses rarely look short in a mockup, but on a real site they break the layout.
The two-week schedule
Every page needs a named owner, otherwise later updates slip and the page becomes an old brochure. A page owner is not just a writer. Whoever can answer customer questions, supply trust evidence or approve a price change has to appear in the matrix — or the review date means nothing.
The launch gate
Decide one success event before you launch: a form submission, a call, a file download or a view of the services page. Do not mistake a single feature for the finish line of version one. Version one is ready when a visitor can arrive, understand the offer, see the evidence and complete the intended action with a clear confirmation.
When the roadmap fails
Version one does not need every feature, but it must show one complete path from arrival to action with no dead end. Hold the roadmap approval meeting around the matrix rather than the colour mockups. That moves the discussion to audience, content, responsibility and outcome.
Split the 14-day plan in three: five days of discovery and content, five days of design and testing, four days of fixes and launch preparation. After launch, do not throw the matrix away. The same document is where a hypothesis gets marked confirmed or rejected; otherwise next month’s revision starts from guesswork again.
Any decision justified only by “this is what I like” has to become a testable hypothesis. These steps work for small sites too. The difference between a small business and a large project is the number of rows, not the need for a landing page, a clear message and a way to measure.
Sample service-page matrix
| Job | Evidence | Action | Owner | Metric |
|---|---|---|---|---|
| Judge the fit | Method and example | Consultation | Sales | Form submitted |
To turn the map into a plan, track every page as its own card. On the card: the proposed URL, the primary audience, the first question, the evidence required, the action and the owner. Cards that share one message can merge; cards with a different audience or a different decision must stay separate.
A simple pre-design test is to ask someone outside the team what they expect to find once they read the page name. If their answer diverges sharply from the planned content, the name or the structure of the page is not precise yet.
The six-column matrix for a services page reads like this: job — “judge whether this service fits”, evidence — “method and worked example”, action — “request a consultation”, owner — “sales”, metric — “form submitted successfully”, plus a review date. Those same six columns are what stop a beautifully written page with no purpose from shipping.
Order matters: business goal first, then the user’s job, then content, then structure, then appearance, then technology last. Reversing that order usually lets a theme or a tool dictate the business answer.
In a 14-day project the early days should go to collecting the questions real customers ask. The middle days are for arranging content and testing the path. The final days should only fix problems the testing actually showed, not absorb new, unprioritised wishes.
The classic roadmap risk is adding a feature for every internal opinion. Each new request has to be written next to the metric column. If it is unclear which job it improves, it does not enter the current version.
Once you are live, do not read the data as pageviews alone. A page with many views and few actions may carry the wrong message, too little evidence or an unclear route to contact. A qualitative review of the calls and questions you receive is the companion to the numeric report.
This article has one concrete conclusion: before design, you must be able to say for each page who arrives with what question, which evidence answers it, and what event should happen after they read. If those three answers are missing, no visual design will fix the problem.
Two questions to settle before starting
What gets cut when the budget is small?
Cut secondary features, never the complete decision path. Make one service right from message to action, then expand.
When should the theme be chosen?
After content, structure, speed and required accessibility are clear. A theme is an implementation constraint, not a business plan.
A deliverable outcome
Each page gets exactly one primary job and one success event; launching is only allowed once both are recorded in the page matrix. That same matrix should live next to the design file and the release plan.
How do you run a discovery meeting?
A discovery meeting does not open with “which pages do you want?”. First ask sales or support for three repeated customer questions and three reasons deals were lost. Those six items are the input to the content structure. Then decide, for each question, whether the answer belongs on the home page, the service page, the FAQ or the contact flow. The output should be a decision table, not a list of ideas.
Do not hide technical dependencies inside the map
The request form may depend on email, a CRM, SMS or a consultation calendar. Write those dependencies beside the page itself, because after launch “the form does not work” can come from SMTP settings, an API permission or an auto-responder. For each dependency, name an owner and a test to run before release.
What moves from content into the wireframe?
Every heading, piece of evidence and action in the matrix must have an assigned place in the wireframe. If a design stage produces a block whose reason for existing is unclear, go back to the matrix; adding it just to fill space is not acceptable. That single link is what closes the gap between content strategy and visual design.
The 30-day review
After a month, walk the pages against the questions received, the exit paths, the incomplete requests and the event data. A page that drives people to contact without resolving one question may be attracting the wrong audience. The next decision should trace back to a specific row in the matrix, not to redesigning the whole site.
A worked decision about the pricing page
Suppose the manager wants to hide prices and show only the consultation form. The matrix should test what decision the user actually makes: if their real question is the cost range, hiding it completely usually increases unqualified contact. The answer can be a range, the factors that move the price and an invitation to get a precise quote. The right decision comes from understanding the user’s job, not from a standing rule about publishing prices.
Defining a releasable version
The final launch check should cover links, the form, image alt text, the mobile view, page titles and the error return path. It is not only technical: someone outside the team should be able to state the page’s message and next action in under a minute. If they cannot, the page is complete from the organisation’s point of view but not from the visitor’s.
In the end, sign the roadmap with the decision-maker’s name and the review date. That small step turns the next argument about why something was chosen into a document anyone can consult.
Sources
- https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Website_security
- https://www.w3.org/WAI/tips/designing/
Omid Bodagh
I am an SEO specialist who likes helping businesses get seen on Google. From WordPress to SEO, whatever an online business needs to grow, I can help with it.