Using Customer Questions to Shape Your Website's Information Architecture
Most websites are built around what the business wants to say, not what customers actually ask. That gap is where good information architecture (IA) goes wrong. At design-logix.co.uk, we start every structural review with one question: what are people really typing into the contact form, the live chat, and the search bar? Those raw enquiries are free research. Map them onto your site structure, and answers become easy to find.

Start With the Questions Customers Already Ask
Pull ninety days of enquiries from your inbox, CRM, and phone notes. Group them by intent, not by department. You will usually find the same ten or twelve themes repeating: pricing, delivery times, returns, suitability, and support. These themes are your real site sections, even if your current menu says otherwise.
Write each question in the customer's own words. "Will this fit a narrow hallway?" is more useful than "Product dimensions." The language people use should appear in your navigation labels, page titles, and headings so search and scanning both work in your favour.
Turn Question Groups Into Navigation
Once you have clusters, allocate one primary destination per cluster. If several questions share one answer, they belong on one page with clear anchor links, not scattered across the site. This reduces duplication and stops visitors bouncing between pages that each answer half the query.
- Pricing and quotes: one page with bands, examples, and a clear next step.
- Delivery and lead times: one page covering regions, costs, and tracking.
- Returns and guarantees: one page with the policy in plain language.
- Product or service fit: one page per use case, not per internal team.
A simple test: can a first-time visitor answer their top question within two clicks from the homepage? If not, the IA is still business-shaped rather than customer-shaped.
Where FAQ Pages Fail
Dumping every question onto a single FAQ page feels efficient but performs poorly. It hides the answer inside a long list, weakens topical relevance, and creates a page nobody links to directly. Use FAQs as support, not as the main structure.
"The best FAQ is the one you no longer need, because the answer already lives on the right page."
Instead, place each answer where the question arises. A sizing question belongs beside the sizing guide, not three clicks away. A returns question belongs next to the checkout reassurance. Context beats volume.
Map, Test, and Refine
Build a simple mapping table before you touch the design. It forces honest decisions about what goes where and exposes gaps you can fix with content rather than more menus.
| Customer question | Intent | Page destination | Format |
|---|---|---|---|
| How much does it cost? | Pricing | /pricing | Table plus quote form |
| How long is delivery? | Logistics | /delivery | Timeline plus map |
| Can I return it? | Risk | /returns | Steps plus policy |
Then test with real tasks. Ask five customers to find the answer to their own question and watch where they hesitate. Adjust labels, reorder sections, and repeat. IA is not a one-off diagram; it is a living map of what people need.
Make Answers Findable, Not Just Present
Structure only works when it is visible. Use descriptive page titles, breadcrumbs, and internal links written as questions. Add search that suggests top queries. Keep mobile menus shallow, since deep nesting hides answers on small screens.
Finally, review enquiry logs each quarter. New questions reveal new intents, and your IA should shift with them. When your site structure mirrors real customer questions, support tickets drop, trust rises, and visitors find what they came for without asking twice.
