КЕЙС: РАЗРАБОТКА ИНДИВИДУАЛЬНОГО САЙТА НА БИТРИКС ДЛЯ СЕТИ СТОМАТОЛОГИЧЕСКИХ КЛИНИК "ДЕНТИКА"

Вводные

Клиника «Дентика» обратилась к нам с задачей редизайна и обновления корпоративного сайта.

Цели проекта были понятны и привычны: создать современный дизайн, улучшить структуру, сохранить привычную для клиента CMS, чтобы не менять процессы работы команды.

На старом сайте уже ощущалась устаревшая визуальная часть — это стало главным мотиватором для обновления.

Проект на старте выглядел как типовая задача по редизайну, но на практике оказался одним из самых сложных за последние годы — прежде всего из-за коммуникационных и технических факторов.

Разночтения в ожиданиях

На этапе предварительной оценки возникло неполное уточнение требований.

Мы ориентировались на разработку под CMS Bitrix;

Клиент предполагал продолжить работу с UMI, как и прежде.

Этот момент не был зафиксирован в явном виде на старте. В результате бюджет и сроки уже были согласованы, когда выяснилось расхождение по выбору платформы.

После обсуждения мы приняли решение работать на UMI, чтобы сохранить привычные для клиента процессы, несмотря на ограничения этой CMS.

Работа началась с поэтапного создания и согласования страниц:

1. Главная

2. Контакты

3. Акции

4. Цены

Затем должны были последовать разделы: О компании, Врачи, Портфолио, Блог и др.

Клиент настаивал на постраничном согласовании — каждая страница обсуждалась отдельно, проходила по нескольку раундов правок.

На этом этапе столкнулись с тем, что визуальные и UX-решения приходилось переделывать под вкусовые предпочтения, дизайнерские рекомендации почти не принимались.

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

Когда были готовы четыре страницы, клиент настоял на их внедрении прямо в текущий сайт. То есть предполагалось, что сайт будет частично старый, частично новый.

Мы резко выступили против, объясняя:

- дизайн и структура будут визуально разниться;

- могут возникнуть проблемы с навигацией и переходами;

- технически UMI не предназначена для «вшивания» новых модулей поверх старой версии;

- возможны конфликты в стилях, скриптах, логике форм и модулей.

Однако клиент жёстко настаивал:

«Сайт должен уже сейчас начать выглядеть по-новому. Нам не важно, как вам удобнее, нужен видимый результат». Мы пошли навстречу и попытались реализовать эту схему. Однако это привело к глобальным техническим сбоям.

Попытка внедрения четырёх новых страниц в существующий сайт клиента не увенчалась успехом. После первичной интеграции стало очевидно, что сайт начал «ломаться» в неожиданных местах. Было принято решение провести диагностику UMI-системы.

Проведённая диагностика показала:

- Сайт клиента был собран на версии UMI от 2018 года, которую ни разу не обновляли.

- В процессе интеграции новых страниц CMS была вынужденно обновлена до 2024 года.

В результате этого:

- перестал работать вход в админку,

- сломалась встроенная почта,

- частично исчезли страницы активности,

- интерфейс стал нестабильным.

Даже техническая поддержка UMI не смогла гарантировать восстановления, так как переход между такими удалёнными версиями официально не поддерживается.

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

После совещания с клиентом мы предложили единственно надёжный и масштабируемый вариант:

- Собрать новый сайт полностью, от первой до последней страницы,

- Протестировать его на тестовом домене,

- После финального согласования — полностью перенести его на основной домен,

- Заменить лицензионный ключ и запустить стабильную версию с нуля.

Мы открыто пояснили клиенту:

"Попытка совместить старое ядро и новый дизайн — это путь в никуда. Мы будем тратить время, силы и деньги, не приближаясь к финальному результату. Чтобы вы получили устойчивый, современный, рабочий сайт — необходимо идти до конца".

Клиент согласился.

Нельзя начинать оценку без изучения текущего состояния сайта, особенно если проект связан с редизайном/переносом.

CMS — критически важная часть ввода, и её нужно фиксировать письменно при брифинге.

Гибридные решения = двойная работа, особенно если речь идёт о системах с устаревшими версиями.

Постраничное согласование должно ограничиваться количеством раундов и включать UX/дизайн‑аргументацию.

Иногда жёсткий отказ — лучшая услуга для клиента. Нельзя идти на компромиссы, разрушающие архитектуру и стабильность.

Этап: Детские страницы и расширение зоны правок

После утверждения стратегии полного переноса и отказа от гибридного подхода, мы продолжили разработку остальных разделов сайта. Следующим этапом стала работа над детским направлением, которое изначально было спроектировано как одна отдельная страница.

Детская страница: визуальные качели

Изначально клиент предоставил цветовую палитру и стилистику для раздела «Детская стоматология». Дизайнер собрал макет, клиент утвердил направление и работа пошла в финализацию.

Однако через несколько дней после согласования клиент вернулся с просьбой:

«Мы передумали. Хочется другой визуал — давайте переделаем в другой цветовой гамме».

Мы пояснили, что изменение утверждённой палитры на этом этапе влечёт:

- дополнительное время на переработку дизайна,

- необходимость пересмотра уже созданных элементов,

- задержку верстки.

Тем не менее, по желанию клиента — работа была переделана. Вторая итерация была принята, но время было потеряно.

Палитра №1:

Палитра №2:

Следующий блок — страницы с услугами, включая взрослые и детские направления. Изначально по техническому заданию предполагался единый визуал, общий для всего сайта плюс одна общая страница, посвящённая детской стоматологии.

Однако уже в процессе работы с карточками услуг клиент снова изменил концепцию:

- В рамках детской части нужно было разработать сразу несколько отдельных услуг, каждая в «детском» стиле.

- Общая идея редизайна была фактически изменена: вместо одного детского блока — целая мини-система внутри сайта.

Эти изменения не были зафиксированы в начальном ТЗ. Однако команда пошла навстречу клиенту и включила новые страницы в план работ за отдельную стоимость, с учётом необходимости сохранить визуальную целостность и логику навигации.

Когда мы дошли до этапа разработки детских страниц (с отдельным дизайном, отличающимся от «взрослой» части сайта), разработчик столкнулся с техническим ограничением:

В текущей архитектуре Bitrix невозможно было интегрировать детские страницы в админку сайта, сохранив их уникальный дизайн и структуру, без полного пересмотра шаблонов и логики CMS.

Детские страницы требовали отдельного набора стилей, HTML-структуры и верстки, которые не укладывались в текущий шаблон Bitrix.

- Система была собрана по принципу одного глобального шаблона для всех страниц.

- Чтобы встроить детские страницы в админку, пришлось бы:

- писать отдельные шаблоны компонентов;

- создавать новые страницы-обёртки;

- переписывать часть ядра/модулей.

Это не только занимало бы много времени, но и создавало риск повредить существующую логику сайта. Чтобы не сорвать сроки и сохранить стабильность реализации, разработчик принял техническое решение:

Страницы детских услуг были выполнены в виде статичных блоков (а не в виде карточек/динамических сущностей).

Это позволило быстро сверстать и внедрить их, не затрагивая лишний раз архитектуру CMS.

Мы донесли до клиента, что текущая реализация — быстрое решение для визуальной задачи, но с ограниченной гибкостью.

Работа с детским направлением заняла в 3 раза больше времени, чем планировалось.

Изменения по ходу работы превысили первоначальные договорённости, но не были формализованы допсоглашениями.

Команда выдержала ритм, сохранив качество и стиль, несмотря на частую смену вводных и визуальных решений.

Решения принимались на грани между гибкостью и сохранением управляемости проекта.

После завершения главной и нескольких ключевых страниц, команда приступила к разработке страниц с услугами для «взрослой» аудитории клиники.

Изначально концепция была простой:

- использовать утверждённый «взрослый» визуальный стиль (цветовая палитра, типографика, элементы интерфейса)

- обеспечить единый шаблон для всех услуг, чтобы ускорить разработку и упростить дальнейшее наполнение сайта.

Мы подготовили дизайн, который:

- сочетался с главной страницей по цветам и структуре;

- имел блоки с описанием услуги, фото, ценой и формой записи;

- поддерживал адаптивность на всех устройствах;

- был легко масштабируем под будущие услуги.

Первая итерация взрослой подуслуги:

Утверждённый макет:

На этом этапе команда рассчитывала на быстрое согласование: дизайн был логично выстроен, соответствовал ТЗ и сохранял единый стиль.

Однако процесс пошёл по уже знакомому сценарию:

1. Множественные итерации правок

После каждого согласования появлялись новые корректировки — от замены фотографий до перестановки блоков.

2. Возврат к уже согласованным решениям

Некоторые правки противоречили ранее утверждённым макетам.

3. Эстетические правки «на глаз»

Изменения часто были не связаны с улучшением UX или брендинга, а отражали субъективные пожелания клиента («чуть светлее фон», «сместить кнопку», «добавить больше воздуха»).

- Запланированная быстрая отрисовка и верстка взрослых услуг превратилась в длительный цикл согласований.

- Из-за внесения правок уже на этапе вёрстки приходилось возвращаться к макетам, что увеличивало трудозатраты в 2–3 раза.

- Постоянные возвраты на предыдущие этапы сбивали команду с плана и сдвигали разработку следующих страниц.

Итог:

Хотя визуал взрослых услуг в итоге был реализован и соответствовал общей концепции сайта, постоянные правки и пересогласования сделали этот этап одним из самых трудозатратных в проекте.

1. Базовая архитектура сайта

Создан единый адаптивный шаблон для «взрослой» части сайта, интегрированный с админкой.

Реализована корректная работа меню, хлебных крошек и перелинковки между разделами.

2. Динамические разделы

Раздел “Акции” — управляемый через админку, с возможностью добавления, редактирования и архивации акций.

Скрин - редактирование элемента Акция в разделе Акции:

- Раздел “Цены” — с гибкой структурой прайс-листов, которые можно обновлять без помощи разработчика.

- Блог / Новости — с категоризацией, датами публикации и сортировкой.

- Врачи — отдельные карточки с фото, должностями, опытом работы и специализацией.

Скрин - корректировка элемента Врач в разделе Врачи:

Портфолио — возможность загружать и структурировать примеры работ.

3. Формы и функционал обратной связи

- Модуль записи на приём с привязкой к конкретной услуге или врачу.

- Обратная связь с защитой от спама.

- Интеграция форм с почтовыми уведомлениями.

4. Техническая оптимизация

- Настроено кеширование Bitrix для ускорения загрузки страниц.

- Подключены счетчики аналитики (Яндекс.Метрика, Google Analytics).

- Настроены человекопонятные URL (ЧПУ).

Одной из ключевых дополнительных задач проекта стала разработка функционала «Счастливые часы» — интерактивного блока для записи пациентов на свободные временные слоты со скидкой.

Чтобы обеспечить гибкость и не нагружать основную структуру сайта, был реализован отдельный модуль с собственной базой данных и административной панелью.

Визуал для пользователей:

Это позволило:

- управлять свободными слотами независимо от основного контента сайта;

- задавать дату и время;

- выбирать врача, который принимает в этот слот;

- привязывать акцию к конкретному филиалу.

- быстро добавлять и изменять предложения;

- собирать статистику по откликам пациентов на скидочные окна.

В результате клиника получила удобный инструмент для повышения заполняемости расписания врачей и стимулирования пациентов приходить в менее загруженные часы.

Вот вариант текста для блока «Выводы и уроки проекта», который аккуратно подводит итоги, показывает уроки и даёт рекомендации, не выставляя компанию в слишком негативном свете.

Выводы и уроки проекта

Проект показал, насколько важно заранее фиксировать все технические и организационные условия, чтобы минимизировать риски изменений и переделок в процессе работы»

Что можно было сделать лучше

На этапе оценки проекта уточнить все ключевые технические моменты, включая выбор CMS и ограничения платформы;

Внедрить формальные правила по работе с правками — какие изменения вносятся в дизайн, какие — только на этапе администрирования;

Ближе вовлекать технических специалистов на этапе согласования дизайна, чтобы сразу оценивать сложность реализации отдельных блоков.

Как избежать подобных ситуаций в будущем

Чётко фиксировать требования и согласованные CMS в документации ещё на старте;

Использовать поэтапное согласование макетов с ограничением количества правок после утверждения;

Применять отдельные тестовые среды для сложных функциональных блоков (например, «Счастливые часы»), чтобы минимизировать риск конфликтов с основной системой.