Каждый сайт стоматологии в рунете выглядит одинаково: голубой фон, фото улыбающейся женщины с белыми зубами, таблица услуг с ценами, телефон в подвале. Я сделал концепт, который ломает этот шаблон — и хочу разобрать, какие решения там работают на запись, а какие — декор.

Пациент заходит на сайт клиники с одной задачей: понять, можно ли сюда записаться без звонка. Если ответа нет — он уходит на 2ГИС, где запись делается в 2 клика.

Дальше пациент проверяет: кто врачи (лица, образование, стаж), цены (без «уточняйте по телефону»), отзывы (не «Иван И., 5 звёзд», а с фото и историей), адрес (близко ли, парковка, метро).

Сайт-визитка с прайс-таблицей в Excel-стиле эту работу не делает. Поэтому я в концепте Dental Pro сделал всё наоборот.

Главный экран → большая кнопка «Записаться» → форма из трёх шагов: 1) выбор услуги — 4 карточки с иконками (первичный осмотр, профгигиена, лечение кариеса, другое), активная подсвечивается мятной рамкой; 2) дата + врач + время — нативный input type="date", селект врачей, время — chip-кнопки; 3) контакты — имя, телефон, опциональный комментарий.

После «Записаться» кнопка морфит в зелёную «✓ Запись подтверждена» — пользователь сразу видит, что заявка ушла.

Почему это работает: длинная анкета из 8 полей пугает. А три коротких шага с прогресс-баром создают ощущение «я уже почти на месте». Это известный паттерн из UX-исследований: пользователь, заполнивший хотя бы 2 шага из 3, доводит форму до конца в 80% случаев против 40% у одностраничных длинных форм.

Что внутри технически: одна страница, состояние через data-step на контейнере, переключение CSS-классами. Заявка летит на бэкенд (или в Telegram администратора, если бэка пока нет). Никаких React/Vue — ванильный JS, ~10 КБ.

Блок «12 лет на рынке / 8500+ пациентов / 12 врачей / 78+ сертификатов» — числа считаются от 0 до целевого значения с easing 1 - (1-t)³. Анимация запускается единожды, когда блок попадает в viewport.

Почему это работает не так очевидно, как кажется. Сами по себе цифры — это не доказательство, а заявление. Никто не проверит, действительно ли 8500 пациентов. Но анимированные счётчики работают на двух уровнях: внимание (глаз цепляется за движение — на статичные числа человек смотрит 0.5 секунды, на анимированные — 2-3 секунды) и доверие через вовлечение (чем дольше пользователь смотрит на цифры, тем больше склонен в них верить — эффект «иллюзорной правды»).

Реализация: отдельный IntersectionObserver с порогом 0.5, чтобы счётчик начал считать только когда блок реально виден. Если анимировать на DOMContentLoaded — пользователь промотает блок до того, как начнётся анимация, и эффект не сработает.

6 карточек врачей в сетке 3×2. У каждой — портрет 4:5, имя, специализация, ВУЗ, сертификаты, CTA «Записаться». Три из шести имеют бейдж «🟢 Принимает сегодня».

Почему это работает: срочность. Когда пациент видит «принимает сегодня», у него в голове появляется конкретный сценарий: «вот сейчас в 8 вечера и пойду». Без бейджа — абстрактное «когда-нибудь запишусь». Конверсия с конкретного сценария в 3-5 раз выше.

Подводный камень: бейдж должен быть реальным. Если показывать «принимает сегодня» у врача, который в отпуске, — это потерянное доверие на всю клинику. Поэтому в реальном проекте бейдж дёргается из расписания CRM (IDENT, Medesk, Dental4Windows), а не задаётся вручную.

5 вопросов через <details>/<summary>. Работает без JS. Стрелка expand_more поворачивается на 180° через [open] CSS-селектор.

Почему это работает (и почему я не люблю JS-аккордеоны): accessibility «из коробки» — screen reader сам прочитает «свёрнуто/развёрнуто»; 0 байт JS — ничего не ломается на медленном соединении; корректно индексируется поисковиками — контент внутри <details> отдаётся в HTML и попадает в FAQ-разметку. JS-аккордеоны в 2026 — это карго-культ. Никаких преимуществ перед нативным <details> нет.

Заголовок «Здоровая улыбка / начинается здесь» собирается побуквенно с задержкой 70 мс между символами. Первая строка — синяя, вторая — мятная.

А вот это уже спорное решение. Побуквенное появление — приём с двух сторон. Плюс: глаз цепляется, hero видят все, и здесь это работает. Минус: замедляет восприятие — пока буквы прыгают, пользователь не может прочитать смысл. В концепте я оставил, потому что задержка короткая (~1.5 секунды на всю фразу). Если бы заголовок был длиннее 6-7 слов — отключал бы. Это та граница, где «вау-эффект» начинает мешать конверсии.

3D-сцены и WebGL-эффекты. В лендингах окей, в медицине — нет. Стоматология продаёт доверие и серьёзность, а не «вау». Лишний WebGL весит много, грузит мобилу, отвлекает от формы.

Карусели с автопрокруткой отзывов — никто не успевает прочитать. Лучше grid из 6-9 отзывов с фото. Чат-боты с автоприветствием — раздражают; если уж делать чат — то по клику пользователя. Видео-фоны в hero — грузят 2-5 МБ, на мобиле это секунды загрузки. Лучше большое статичное фото.

HTML5 + Tailwind CSS (CDN, без сборки) + Vanilla JS — концепт быстро прототипировать, проще передать клиенту. CSS-анимации (blob pulse, floatY, fadeUp), IntersectionObserver для scroll reveal и stats counter. Plus Jakarta Sans (заголовки) + Inter (текст), Material Symbols (иконки). Дизайн-система «Clinical Excellence» — палитра, типографика, тени, скругления, spacing. Под каждый бренд адаптируется без редизайна с нуля. Хостинг — свой VPS, Nginx + Let's Encrypt.

Сайт стоматологии — это не про красивый дизайн. Это про трение между «зашёл на сайт» и «записался». Каждое UX-решение должно либо снимать возражение (врачи, отзывы, сертификаты), либо упрощать действие (короткая форма, кнопка «записаться» везде).

Концепт Dental Pro показывает, как это можно собрать без раздутого стека и сторонних SaaS-плагинов — на ванильном HTML/CSS/JS за 2-3 недели. Под реальную клинику адаптируется быстрее: бренд, фото врачей, интеграция с CRM (1С:Стоматология, IDENT, Medesk).

Посмотреть концепт: https://dental.nazarov-evgeniy.pro/

Кейс с разбором всех UX-решений: https://nazarov-evgeniy.pro/portfolio/dental-pro/

Под реальную клинику делаю за 2-3 недели от 60 000 ₽: https://nazarov-evgeniy.pro/razrabotka-sayta-dlya-stomatologii/