Services page design: where inquiries are lost and why
A visitor comes to the services page from search or advertising with a specific task and an almost-ready decision.
The first screen, which answers not their question but talks about us and our values, triggers the first drop-off point: the person returns to the search results and leaves to compare further.
We analyze such points not by taste but by behavior — where exactly reading breaks off and at which step the inquiry is lost.
The structure of the services page most often breaks in one place: the service description runs as a wall of text, and the next step is hidden at the very end. The client sees the scope of work but does not see how to move from it to a conversation.
The sections formally exist, but the path to an inquiry stretches across six or seven screens — and at each next one, some people drop out before reaching the form.
The second most common reason is hidden terms. If the format of work, timelines, and boundaries of responsibility are not stated where the reader is already thinking about them, they fill them in themselves, usually not in our favor, and leave.
An honest framing, on the contrary, retains: it filters out those with whom the work won't work out and keeps those who need exactly this scope.
Drop-off points are a measurable thing: a click map and scroll depth show at which block the share of those reaching the bottom falls most sharply.
Services page design in this sense is not decoration but a sequence of decisions: what the person sees first, what confirms their choice, and at which step they are offered to leave a request. Below we analyze how this is closed at the level of structure, visuals, and calls to action.
What changes after redesign: inquiries, trust, bounces
We do not evaluate redesign by "it became prettier." Before edits, we take baseline snapshots in Yandex Metrica: scroll depth on the services page, bounce rate, number of transitions before first contact, share of repeat visits.
After — we compare the same metrics on comparable traffic broken down by source: otherwise growth in inquiries can easily be attributed to seasonality.
The first noticeable shift is the path to first contact. When the first screen shows who the service is addressed to, what the work consists of, and what the client gets at the end, the decision is made in two or three screens instead of ten.
The inquiry button stands after the block with the scope of work and removed risks, not in the header: those who already understand the subject leave a request, so the share of identical questions in correspondence drops sharply.
What measurements show
The bounce rate on the services page falls by one and a half to two times — people leave not because of the design but because they don't understand the next step.
The read-through rate grows along with repeat visits: the page is saved and returned to when budget and timelines become relevant.
Trust in the contractor grows from the verifiable: the set of stages, area of responsibility, limitations, what exactly is not included in the work.
The page stops promising and starts showing — and inquiries increase not through new traffic but through those who already visited and did not dare write.
Comparison of approaches: template, custom layout, revision
An approach is chosen not by taste but by the number of services in the section, the frequency of content edits, and what already works on the domain.
A services page template is justified when there are many services and they are typical: the block structure repeats, launch is fast, but a non-standard sales scenario will require edits in the template code.
A custom layout for the section is needed where the decision is made over a long time and by several criteria — then the order of blocks is designed for the logic of choice, not for the capabilities of a ready-made theme.
| Option | When it fits | Limitations |
|---|---|---|
| Services page template | A catalog of a dozen typical services, fast launch needed | Repeating block structure, non-standard scenario requires template refinement |
| Custom section layout | Expensive service, long decision cycle, several audience segments | Longer approval, structure is fixed before markup |
| Landing page for one service | One service and one traffic source, precise presentation needed | Blocks are duplicated between pages, services section lives separately |
| Refinement of an existing page | The section already collects traffic, but there are few requests | Freedom is limited by the current markup framework and block markup |
How to choose
Look at two signs: how many different services should live in the section and how often their description changes. If edits are rare and services are similar in structure — a template and refinement give results in fewer iterations.
If there are few services, but each is sold by its own logic, a custom section layout or a separate landing page is more advantageous: they allow leading the visitor through one scenario and not diluting the presentation. A mixed option also works: typical services in a template, the flagship one on its own layout.
Stages of work: task analysis, design, build, verification, handoff
We work on the section in two-to-three-day iterations: each design development stage ends with an artifact that can be opened and challenged, not a promise to "show everything at the end." The order is fixed — audit, block scheme, rendering, testing on live scenarios, handoff. Below is a breakdown of each step.
- Audit and scenarios. We analyze the current services page: what blocks exist, where the visitor comes from, at which step they leave. Output — a scenario map: what the person is looking for and where they make the decision.
- Services page prototype. A framework without visuals: block order, priority of offers, form touchpoints. We run the prototype entirely on clicks — from the first screen to the request, before rendering.
- Work plan for the section. We fix the set of blocks, number of states (default, hover, focus, disabled), number of responsive breakpoints, and approval points. Scope does not grow along the way.
- Layout rendering. We assemble visuals on a unified grid and spacing scale so blocks do not fall apart when transferred to markup. We separately define button and field states and the behavior of long headings.
- Testing on live scenarios. We insert real texts, long service names, and empty states. We check that the path to the form is not broken on mobile, tablet, and desktop.
- Layout acceptance. We go through the checklist: blocks, states, responsive, placeholder texts, links. We collect comments in one list, fix and close them — without a back-and-forth of "draw another option."
- Handoff. We provide source files, component specifications, and a block map, and have a call with the client's team. After that, the build is done according to the document, not from memory.
Handoff package: structure, layouts, texts, guidelines
Handoff is not a folder with images but a set with which markup and subsequent edits can be done without the layout author.
We assemble it so that a person who did not participate in the project can open the materials and understand where to change a section heading, how to add a service card, and why the button is in exactly this place. Below is what remains with the client after delivery.
- Section structure diagram — a tree of blocks with order, notes "can be reordered" and "tied to page logic," plus points where forms and transitions are connected.
- Source layout file — a file with layers, grid, repeating components, and states of buttons, fields, and hints: hover, pressed, error, disabled. No flattened raster images.
- Section styling guide — typographic scale, spacing step, rules for color combinations and text behavior on overflow, boundaries of responsive transitions.
- Text block templates — templates for a heading, service description, benefits list, and FAQ block, with line length limits so a new page does not break layout.
- Editing instructions — what changes without a designer (text, card order, image replacement) and what requires rebuilding a component; with before-and-after examples.
- Review guidelines — a short list of what we check before publication: contrast, size of interactive areas, correctness of links and headings.
- List of open decisions — places where we intentionally left options for the future, with an explanation of what to consider when choosing.
The package is stored in one place and versioned: an edit can be rolled back rather than restored from memory. We verify handoff simply — using the materials, we build a new services page without asking the layout author questions.
Case study: section redesign and inquiry growth
The client's services section has six areas, each with its own audience and its own decision timeline. Traffic to the page was steady, but there were almost no inquiries from the section: the visitor read through the wall of text and left.
Formally, the task sounded like a services page development case; in essence, each branch needed to bring the person to a conversation.
What it was before redesign
All areas lay in one wall: equal-weight blocks, generic wording, not a single action until the very bottom of the page. The user could not quickly identify which area their task belonged to, and there was only one contact point. On mobile, the list stretched across several screens, and about 4% of visits reached the form.
What changed and how it was measured
The section was split by area: each has its own first screen, its own task indicators, and its own inquiry button within the visible area. Further down the page we left proof: scope of work, limitations, examples.
We measured not by views but by events in Yandex Metrica — we tracked transition to the form, start of filling, and submission, separately for each area.
The metrics shifted in the first observation cycle. The share of section visits ending in an inquiry rose from 4% to 11%; the share of started and abandoned forms fell by half.
Requests almost always indicate the area — managers stopped clarifying it in correspondence, and the time to first substantive response decreased.
How a landing page differs from a catalog section
A landing page answers one question and leads to one action: one entry route, one offer, linear block order. A catalog section solves the opposite task — to arrange areas so that in two or three clicks a person finds theirs and does not leave to search elsewhere.
Hence the difference in structure: the former has no alternative paths; for the latter, they are the essence of the page.
At the markup level this is immediately visible: a landing page has one URL, no filters or pagination, and breadcrumbs lead to the root. A catalog has nested URLs, cards from one template, separate rules for empty filter selections, canonical URLs, list markup.
If the formats are confused, search engines begin to see competition between their own URLs, and traffic is diluted between pages with the same meaning.
A separate landing page is created when an area has its own demand and its own scenario: its own questions, its own timelines, its own set of proof. Then the page gets an independent structure and does not share attention with neighbors.
A sign that this is not needed: little demand, the service composition matches a catalog card, and the page differs from it only by the heading — the result will be a thin duplicate that does not win a single query.
The structure of an areas catalog is built from the logic of choice, not from markup convenience: an overview list with brief cards and an area page with the same set of blocks — what is included, how the work proceeds, limitations, FAQ.
A single template gives predictability: layout edits reach all pages, and comparison of areas remains fair. From an export from Yandex Metrica you can see which cards gain clicks and which sit idle.
Practical order: first an organized section, then landing pages for areas that have proven demand.
Common concerns: edits, timelines, repeat iterations
Concerns about services page design rarely relate to taste — more often they are questions about the scope of work after delivery, the number of iterations, and the fate of the section in six months.
Below is what clients clarify before the start so as not to figure it out in the middle of the project.
How many edits are included after layout handoff?
Two rounds of edits at the layout stage are included: texts, button states, block order. Edits after handoff vary by cost of change — replacing content and images takes hours, while restructuring a section is a separate task because it affects markup and responsive grids.
How many design iterations are actually needed?
Usually two or three iterations for key screens are enough. The fourth and fifth blur approved decisions rather than improve them — so we lock structure and texts before visuals, not during discussion.
The section is already coded — do we redo everything?
First we look at the current markup: if the block structure matches, we change styles and components while preserving the markup. If the grid is different — we migrate the section by sections, and the page remains functional.
When migrating to another platform, the order is the same: first markup and content, then the visual layer.
How is the layout handed off to developers and what happens after launch?
We hand off the layout with components, hover and error states, responsive grids, and a description of interactive element behavior, plus hold a walkthrough with the team.
After launch, the section lives in a shared design system: content edits and block updates do not require rebuilding the layout.
Let's discuss the task: we'll come back with an estimate and work plan
To discuss the section task concretely, no ready document is needed — input is enough. Send a link to the current services page, a brief list of services noting which bring the main revenue, and access to analytics if it is collected.
The more specific the initial data, the more accurate the page design estimate and the fewer iterations for approval.
- Link to the current services page and to two or three examples in your industry that you consider successful.
- List of services: what we sell first and what we support.
- Constraints: site management system and templating engine, brand book or design system, marketing requirements.
- Analytics data: visitor path, drop-off points, share of mobile traffic.
- Deadlines and events the launch is needed for.
In response we return not a general estimate, but a work plan and stages with artifacts at each step. The scope estimate is calculated by the number of blocks and states, so it is visible and can be checked against your expectations.
- Structure: block logic, section order, scenarios for moving to a request.
- Visuals: two directions on your real texts.
- Build: responsive, form states, testing on real devices.
- Approvals: edit guidelines and acceptance points by stage.
The handoff package — prototype, layouts, markup, and brief editing instructions; repository access remains with you. Approvals go in waves, one stage at a time, so edits do not spread across the entire page. Describe the task in free form — we will come back with an estimate and a stage scheme.
