Доработка темы для стоматологической клиники — 42 страницы за 79 дней
Доработка темы по Figma: 42 страницы и 11 шаблонов для стоматологической практики — 120+ пунктов QA закрыто за 103 часа в ходе 7 раундов проверки.
Скриншоты сделаны автоматическими инструментами — некоторые элементы могли не загрузиться полностью или перекрываться. Для наиболее точного представления открыть действующий сайт →
Переделать сайт на новом стеке. Реализовать по спецификации. Без импровизаций. Передать готовым к переходу.
Клиент (конечный пользователь): Rivers Dentistry — стоматологическая практика в США
Формат сотрудничества: White-label доработка темы для маркетингового агентства из США
Сроки: ноябрь 2025 · 79 дней · 103 часа · 42 URL · в срок
Подход к доработке темы
42 страницы стоматологической практики в Colorado, собранных из фирменного шаблона dental-template12 агентства с четырьмя лицензированными гарнитурами — Helvetica Neue, Proxima Nova, Brandon Grotesque и Magister — которые пришлось найти до того, как сборка могла совпасть с Figma. QA-проход выявил контент из другой практики, оставшийся в шаблоне и обнаруженный на критичных для запуска страницах; очистка и закрытие 120 зафиксированных задач по 79-пунктному контрольному списку — вот что потребовало 79-дневного взаимодействия.
Шаблонная доработка даёт скорость и единообразие — но только при дисциплине. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля.
Краткий обзор
| Поле | Значение |
|---|---|
| Отрасль конечного клиента | Стоматология — общая практика |
| Конечный клиент | Rivers Dentistry (стоматологическая практика в США) |
| Формат сотрудничества | White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса |
| Тип проекта | Доработка WordPress-шаблона (фирменный шаблон агентства + дизайн по Figma для каждой страницы, на Kinsta) |
| Объём работ | 42 URL — главная, О нас, лендинг услуг, 23 страницы услуг, биография врача, контакты, лендинг блога + шаблон поста, галерея улыбок |
| Сроки | 79 дней (19 авг. – 6 нояб. 2025), в срок |
| Трудозатраты | 103 часа — 41 ч разработка · 43 ч QA-итерации · 15 ч PM · 4 ч правки |
| Команда | 4 специалиста |
| Шаблоны | 11 переиспользуемых шаблонов, предоставленных агентством, применены по всем 42 страницам |
| Технологический стек | WordPress · Elementor · Kinsta · дизайн по Figma для каждой страницы · AutoQA агентства (проверки ссылок / email / Content AI) · Site Checker (QA-плагин xaverPRO) |
| Подход к QA | 120+ отслеживаемых SEO + CX задач разобраны в очереди задач агентства по 79-пунктному контрольному списку запуска |
| Ритм взаимодействия | 120 задач, поставленных агентством · 118 из 120 закрыты к сдаче (активный период 18 дней: 12.10.2025 – 29.10.2025) |
| Раунды проверки | ≈7 раундов проверки за 79 календарных дней |
| Трудозатраты на задачу | 58 внутренних задач Redmine · медиана 28 мин / P75 50 мин на задачу |
| Контрольный список запуска | 79 пунктов, согласованы до переключения |
Постановка задачи
Маркетинговое агентство из США передало нам дизайн в Figma для Rivers Dentistry и цель развёртывания — их фирменную шаблонную систему на Kinsta. Агентство уже выполнило работу на предыдущих этапах: аудит дизайна, утверждение клиентом, настройка хостинга, план контента. Им нужна была команда разработчиков, которая точно наложит Figma на шаблон — через любое количество итераций доработки, какого потребует дизайн.
Задача была чисто исполнительская. Figma — единственный источник истины. Дорабатывать шаблон под Figma постранично, на каждой точке адаптации. Возвращать QA-замечания агентству в общий рабочий журнал; не закрывать их без согласования с агентством.
Риск, который агентство хотело исключить, — команда разработчиков, которая изменяет общие компоненты шаблона ради соблюдения срока. Такой обходной путь выглядит незаметным, пока агентство не обнаружит, что то же «исправление» деградировало сайт другого клиента, работающего на том же шаблоне. Стоматологический шаблон в активном использовании обслуживает несколько практик одновременно; доработка для одного проекта не может проникнуть в общий слой. Именно эту дисциплину нанимало агентство — и именно для её подтверждения был выстроен 41-раундовый QA-цикл в этом проекте.
Контекст рисков. Стоматологический шаблон, активно используемый несколькими клиентами, не принадлежит ни одному конкретному проекту. Команда разработчиков, изменяющая общий компонент ради соблюдения срока по Rivers Dentistry, поставляет не только проблему Rivers Dentistry — она поставляет тихую деградацию каждой другой практике, чей сайт наследует этот компонент.
Этот сбой не появляется в QA-проходе самого проекта; он появляется через несколько недель, на сайте другого клиента, когда агентство уже перешло к следующему. Держать доработки строго в пределах клиентских переопределений — единственный способ защитить и шаблонные инвестиции агентства, и клиентов, которые от них зависят.
Как мы это сделали
1. Figma как контракт, шаблон как канва. Файл Figma был спецификацией дизайна. Фирменный шаблон — базовой структурой страниц. Наша задача — свести их воедино страница за страницей: где стандартная вёрстка шаблона совпадала с Figma, мы её сохраняли; где Figma требовала отклонения — дорабатывали. Никакие дизайн-решения не принимались с нашей стороны. Мы использовали клиентские переопределения, не изменяя общие компоненты шаблона, — поскольку шаблон одновременно обслуживал несколько практик, изменение общего слоя распространялось бы незаметно на других клиентов того же шаблона.
2. QA-цикл на масштабе доработки темы. Чистая доработка темы — это не «собрал один раз, проверил один раз». Это «собрал, QA, поправил, QA, поправил». Из 58 задач, отслеживавшихся в этом проекте, 41 — QA-итерации: отдельные раунды, в которых агентство отмечало расхождения в дизайне, мы разбирали их, исправляли и возвращали сборку на следующую проверку. Такой объём — не признак нестабильности; именно это отличает шаблонный сайт, выглядящий «примерно правильно», от сайта, совпадающего с дизайном.
Принцип прост: при доработке темы ценность создаётся именно в QA-цикле. Более короткий QA-цикл — это более слабое совпадение с дизайном, а не более быстрая поставка. Обратная сторона — QA-часы могут превысить часы разработки: 43 из 103 часов проекта ушло на итерации — потому что каждое отклонение от общего шаблона требовало согласования агентства прежде, чем задача могла закрыться.
3. Доработка без дрейфа. На протяжении всего проекта каждое изменение, вносимое нами в фирменный шаблон — будь то вёрстка страницы, секционный компонент или стилевой токен — документировалось относительно референса в Figma. Ни одна доработка не «утекала» в общие компоненты шаблона, что означает: работа этого проекта не деградировала шаблон для следующего сайта, который будет на нём работать.
4. Проверка на разных устройствах. Доработки проверялись в Chrome, Firefox, Safari и Edge на компьютере, планшете и мобильных экранах — стандартный набор точек адаптации агентства. Каждый QA-раунд охватывал страницы, затронутые расхождениями данного раунда, а не весь сайт, — так доработка темы сохраняет эффективность, не теряя охвата.
Постраничный диф по Figma — вот что держало весь процесс вместе. Без него расхождения в дизайне накапливались бы за 41 раунд проверки, а не выявлялись на уровне страниц — и у агентства не было бы надёжного способа убедиться, что доработка не просочилась в общий слой шаблона.
Контроль качества
QA перед сдачей устранил два вида проблем: контентные заглушки (lorem-текст на /new-patients и /technology, а также общий для сайта пробел в замене изображений-заглушек на страницах услуг) и проход по завершающим слешам после обнаружения отсутствующих финальных слешей во внутренних ссылках на /about и /dr-connor-rivers (Redmine #1008: «Too many issues incl lorem placeholders and links too claude»); 99 из 120 пунктов очереди задач SEO закрыты к сдаче.
QA перед сдачей выполнялся через Site Checker — категории и принцип нулевого допуска по сбоям описаны в нашем подходе к QA. QA-слой агентства — их инструменты, их процесс — запускался после сдачи и вносил оставшиеся вопросы в общую очередь задач для нашего цикла правок вплоть до их согласования.
Доработки оставались в клиентских переопределениях; общие компоненты шаблона агентства не изменялись.
Результаты
| Метрика | Итог |
|---|---|
| Поставленные URL | 42 — 1 главная, 1 лендинг услуг, 23 страницы услуг, 1 биография врача, 1 О нас, 1 контакты и 14 вспомогательных страниц |
| Применённые шаблоны | 11 из 11 переиспользуемых шаблонов собраны и применены по 42 страницам |
| Контрольный список запуска | 79 пунктов согласованы |
| Зафиксированные и разобранные QA / SEO задачи | 120+ пунктов устранены по двум вкладкам очереди задач агентства (SEO и CX) |
| QA-итерации в Redmine | 41 из 58 задач (71%) отслеживались на уровне итерации |
| Сроки | 79 дней, поставлено в срок |
| Трудозатраты | 103 часа при оценке 103 часа — без перерасхода, без расширения объёма |
| Команда | 4 специалиста |
| Передача на хостинг | Запущено в шаблонном окружении Kinsta агентства |
| Состояние страниц при сдаче | 40 / 40 URL тестовой среды вернули HTTP 200 при аудите карты сайта |
Итог, без лишних слов: Figma агентства реализована по их фирменному шаблону на 42 страницах и 11 шаблонах за 79 календарных дней в рамках оценки в 103 часа.
Процесс
| Фаза | Продолжительность | Результат |
|---|---|---|
| Бриф и оценка | ~3 дня | Figma изучена, доступ к шаблону подтверждён, объём согласован |
| Разработка доработки | ~5 недель | Постраничная доработка шаблона по Figma |
| QA-итерации (непрерывные) | ~5 недель | 41 QA-раунд зафиксирован; каждый закрывался только по согласованию агентства |
| Раунды правок | ~1 неделя | 4 ч на постпроверочные исправления |
| Поставка | последний день | Сайт запущен на Kinsta |
Разработка и QA шли параллельно — это характерно для доработки темы, где «фаза QA» не закрывается чётко; цикл идёт непрерывно до тех пор, пока агентство не подпишет результат.
Команда
Команда проекта
- Никита Тумашевич — ведущий разработчик (доработка шаблона и наложение вёрстки по Figma)
- Павел Сажин — QA-итерации и правки
- Тимур Арбаев — поддержка разработки в поздних раундах доработки
- Антон Херсун, xaverPRO — руководитель проекта (оценка, коммуникация с агентством, согласование)
Управление проектом, дизайн и коммуникация с клиентом на стороне агентства оставались у партнёрского агентства на протяжении всего проекта. Наша команда оставалась невидимой для конечного клиента. Все запросы на доработку поступали через общую очередь задач агентства, и ничто из сборки не открывалось конечному клиенту напрямую. Каждый QA-раунд закрывался только после того, как проверяющий со стороны агентства подтверждал устранение расхождения.
Агентствам с библиотекой шаблонов
Работа со стоматологическим шаблоном на нескольких проектах скрывает структурный риск: изменения ради одного клиента незаметно деградируют остальные. У этой практики — версия шаблона для сети клиник с единым брендом; у других — отдельная сборка под одну клинику. Доработки сломаются при обновлении парент-шаблона, ACF-схема разойдётся между проектами, а редакторы не найдут нужные блоки из-за скрытой библиотеки.
Подрядчику стоит задавать не вопрос «сможете ли вы настроить шаблон под нас?», а вопрос «как именно вы изолируете эти настройки, чтобы они не сломались при следующем обновлении?»
Пришлите исходник шаблона или его ID и спецификацию бренда. Мы проверим, как изолированы клиентские переопределения, и покажем, какие доработки сломаются при первом же обновлении. Вернём фиксированную смету в часах.
У вас ещё нет ТЗ? Пришлите описание в один абзац — мы вернёмся с вопросами, которые стоит задать. Прислать описание →
Site Checker запускается до того, как агентство что-либо видит.
Перед передачей каждый сборки в тестовой среде прогоняется через Site Checker — WordPress QA-плагин, который мы разработали и поддерживаем. Это шлюз с нулевой терпимостью к ошибкам: к агентству не уходит ничего с открытыми проблемами. Предупреждения рассматриваются и признаются некритическими; агентство получает чистый старт для своего слоя QA, а не тестовый сайт с известными проблемами в очереди.