Доработка стоматологической темы — 39 дней, поэтапный запуск в Joplin MO

Клиент (конечный пользователь): Northside Family Dentistry — стоматологическая клиника общего профиля, Joplin, Missouri
Формат сотрудничества: White-label доработка темы для маркетингового агентства из США
Сроки: январь 2026 · 39 дней · 40 часов · поэтапный предрелизный набор · в срок

Подход к доработке темы

19 страниц из 84-URL стоматологической карты сайта, доработанные по шаблону «Glowing» агентства на Kinsta, с указанным в Figma шрифтом Adobe Typekit (EB Garamond), интеграция которого не была предусмотрена в ТЗ — решено в первую неделю до начала доработки страниц. Остальные 65 URL карты сайта остаются собираемыми на том же фундаменте, потому что каждое изменение в предрелизном наборе находится внутри слоя переопределений клиента, без модификаций общих компонентов шаблона агентства.

Краткий обзор

Постановка задачи

Маркетинговое агентство из США передало нам макет Figma для Northside Family Dentistry — частной клиники общего профиля в Joplin, Missouri — вместе с правами развёртывания на их брендированном стоматологическом шаблоне на Kinsta. Агентство уже выполнило подготовительную работу: исследование клиента, утверждение дизайна, контент-план, настройку хостинга и 84-URL карту сайта, отражающую полное запланированное веб-присутствие клиники. Что агентству требовалось от нас — доработка для запуска предрелизного набора с сохранением структуры сайта, изначально спроектированной для расширения.

Задача состояла из двух частей. Первая: взять Figma агентства и стоматологический шаблон «Glowing» и согласовать их постранично для подмножества страниц, отмеченных агентством и клиентом для первого релиза. Вторая: сделать это, не затронув шаблон таким образом, чтобы потребовалась переделка при добавлении оставшихся 65 страниц. Предрелизный набор — не упрощённая версия полной разработки; это дисциплина полной разработки, применённая к меньшему объёму, с дополнительным ограничением: всё, что осталось за рамками, должно без проблем достраиваться на том же фундаменте.

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

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

Как мы это сделали

1. Figma как контракт, шаблон как холст. Файл Figma был спецификацией дизайна. Стоматологический шаблон «Glowing» — каркасом страницы. Для каждой страницы предрелизного объёма мы сравнивали Figma со стандартным выводом шаблона и дорабатывали только там, где они расходились — каждое изменение внутри слоя переопределений клиента, ничего в общих компонентах шаблона.

Никакие дизайн-решения не исходили от нас. Там, где Figma задавала элементы макета, не поддерживаемые напрямую существующим набором компонентов шаблона — например, нестандартные структуры Hero-секций — мы выбирали чистую разметку Elementor вместо шаблонных или ACF-полей, чтобы доработка оставалась внутри слоя переопределений без изменения общих компонентов шаблона агентства.

2. Разрешение шрифта и ресурсов на старте. Дизайн в Figma использовал лицензированный шрифт Adobe Typekit (EB Garamond), не входивший в стандартную поставку шаблона. До начала доработки мы решили вопрос встраивания шрифта — запросили CSS-код Typekit у агентства и подтвердили доступность полного набора начертаний, требуемых дизайном. Начать доработку до подтверждения шрифта означало бы протащить визуальное расхождение через все последующие раунды QA. Решение вопроса в первые дни сжало цикл итераций.

3. Цикл QA в масштабе доработки темы. Чистая доработка не делается по принципу «собрал один раз, проверил один раз». Это «собрал, проверил, поправил, проверил, поправил». Агентство отслеживало 45+ отдельных замечаний QA в общей очереди задач — детальные проблемы: от связанных кнопок и выравнивания макета до точности meta-title и мобильной адаптивности — каждый пункт требовал исправления, размещения на стенде и нового подтверждения агентства перед закрытием. За этими 45 пунктами стояли 40 подзадач QA-итераций, отслеживаемых в Redmine. Объём — свидетельство точности, а не нестабильности.

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

4. Доработка без дрейфа. Каждое отклонение от стандарта шаблона — макеты страниц, компоненты секций, токены стилей, встраивание шрифтов, варианты кнопок — укладывалось строго в слой переопределений клиента. Общие компоненты шаблона «Glowing» агентства не модифицировались. Предрелизный сайт и страницы второй фазы расширения будут использовать один и тот же фундамент шаблона, потому что ни одно упрощение в фазе один его не затронуло.

5. Проверка на разных устройствах. Доработки проверялись на большом экране, планшете и мобильных устройствах. Мобильные проблемы — включая регрессию кнопочного макета на узких экранах, потребовавшую точечного CSS-исправления — были выявлены и устранены в цикле QA до передачи. Каждый раунд QA охватывал страницы, затронутые изменениями этого раунда, а не весь сайт; именно так поэтапная сборка остаётся эффективной без потери покрытия.

Шрифт нужно было подтвердить в первую очередь. Встраивание Adobe Typekit отсутствовало и в Figma, и в ТЗ — разрешение в первые дни означало, что каждый последующий раунд QA проверял фактический дизайн, а не визуальную замену. С подтверждённым фундаментом 40 раундов QA за 39 дней фиксировали каждое изменение чисто в слое переопределений шаблона «Glowing», без касания общих компонентов.

Контроль качества

Hero-секции были построены без ACF-полей шаблона — решение принято в первые дни разработки, чтобы изолировать переопределения клиента от общих компонентов шаблона «Glowing»; мобильная регрессия кнопки («Button looks OFF on mobile», задача #3025) была выявлена и устранена в финальном раунде QA перед передачей.

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

Доработки оставались в переопределениях клиента; общие компоненты шаблона агентства не модифицировались.

Результаты

Итог, простыми словами: Figma агентства была реализована на стоматологическом шаблоне «Glowing» для предрелизного набора страниц за 39 календарных дней, в рамках оценки 40 часов — при этом 65-страничное расширение фазы два остаётся собираемым с того же чистого фундамента.

Процесс

Разработка и QA выполнялись параллельно — это характерно для доработки тем, где ни одна «фаза QA» не закрывается чисто; цикл идёт непрерывно до согласования агентством.

Команда

Команда проекта

• Наталия Богатель — ведущий разработчик (доработка шаблона и приведение макетов Figma)
• Тимур Арбаев — QA и поддержка разработчика в раундах доработки
• Павел Сажин — итерации QA и коммуникация по проекту
• Антон Херсун, xaverPRO — руководитель проекта (оценка, коммуникация с агентством, согласование)

Агентство управляло отношениями с конечным клиентом, дизайном в Figma, контент-планом и хостингом. Наша команда работала полностью «за кулисами» агентства — запросы на доработку поступали через общую очередь задач, Northside Family Dentistry не имела информации о нашей работе, и каждая итерация закрывалась только после того, как проверяющий со стороны агентства подтверждал, что исправление выполнено по спецификации.

Агентствам с библиотекой шаблонов