Доработка ортодонтического шаблона: 21 страница за 43 дня
Доработка ортодонтического шаблона на 21 страницу с постраничной дифференциацией иконок и цветов — 10 шаблонов, 51 раунд QA, 39 часов за 43 дня.
Скриншоты сделаны автоматическими инструментами — некоторые элементы могли не загрузиться полностью или перекрываться. Для наиболее точного представления открыть действующий сайт →
Переделать сайт на новом стеке. Реализовать по спецификации. Без импровизаций. Передать готовым к переходу.
Клиент (конечный пользователь): ABM Orthodontics — ортодонтическая клиника в Clearwater, FL
Формат сотрудничества: White-label доработка темы для маркетингового агентства из США
Сроки: декабрь 2025 · 43 дня · 39 часов · 21 URL · по графику
Подход к доработке темы
21 страница доработки ортодонтического шаблона на фирменном шаблоне агентства «Glowing» — 11 страниц услуг и лечения, каждая с уникальным набором иконок и трёхцветной комбинацией в Figma, 39 часов, 43 дня. Агентство своевременно указало, что стандартный набор иконок шаблона повторяется без изменений на каждой странице услуг; решением стала проработка каждого фрейма Figma постранично с применением требуемых дизайном иконок и цветовых вариаций.
Краткий обзор
| Параметр | Значение |
|---|---|
| Отрасль конечного клиента | Здравоохранение — ортодонтия |
| Конечный клиент | ABM Orthodontics (Clearwater, FL) |
| Формат сотрудничества | White-label доработка темы для маркетингового агентства из США, специализирующегося на сайтах для локального бизнеса |
| Тип проекта | Доработка темы WordPress (фирменный шаблон агентства + постраничный дизайн Figma на Kinsta) |
| Объём | 21 URL — главная, about, биография врача, 11 страниц услуг/лечения, страховка, финансирование, членство, контакты и политики |
| Сроки | 43 дня (18 ноя – 30 дек 2025), по графику |
| Трудоёмкость | 39 часов — разработка, итерации QA и управление проектом |
| Команда | 4 специалиста |
| Шаблоны | 10 фирменных шаблонов агентства, применены на 21 странице |
| Технологии | WordPress · Elementor · Kinsta · Gravity Forms · Rank Math · постраничный дизайн Figma · AutoQA агентства (Links / Email / Content AI / visual checks) · Site Checker (плагин QA xaverPRO) |
| Подход к QA | Более 470 отслеженных проблем SEO + CX, согласованных в журнале задач агентства, 78 пункта в контрольном списке запуска |
| Ритм взаимодействия | 3 задачи от агентства · 2 из 3 закрыты к моменту передачи |
| Раунды проверки | ≈5 раундов проверки за 43 календарных дня |
| Трудоёмкость на задачу | 81 внутренняя задача Redmine · медиана 15 мин / P75 24 мин на задачу |
| Контрольный список запуска | 78 пункта, согласован перед переключением |
Постановка задачи
Маркетинговое агентство из США передало нам макет Figma для ABM Orthodontics и цель развёртывания на своей фирменной системе шаблонов под Kinsta. Агентство уже выполнило подготовительную работу: аудит дизайна, согласование с клиентом, настройка хостинга, контент-план. Им нужна была команда разработчиков, которая добросовестно перенесёт Figma в шаблон через столько итераций доработки, сколько потребует дизайн.
Задача была чисто исполнительская. Figma — единственный источник истины. Доработать шаблон до соответствия страница за страницей, точка адаптации за точкой адаптации. Передавать результаты QA обратно агентству в общее рабочее пространство; не закрывать их без согласования с агентством.
Агентству нужно было обезопасить себя от подрядчика, который отнёсся бы к ортодонтической доработке шаблона как к массовому заполнению. Сайт ортодонтии с 11 различными страницами услуг и лечения — каждая описывает свою процедуру, каждая со своим фреймом Figma — не может выглядеть как копипаст. Когда один и тот же набор иконок повторяется на каждой странице услуг и одна цветовая палитра сливается в монотонность, клиника теряет визуальную убедительность, которую дизайн агентства был призван создать. Именно эту дисциплину агентство искало, и именно её проверял 51-раундовый цикл QA в этом проекте.
Контекст рисков. Компактный ортодонтический сайт на общем стоматологическом шаблоне сталкивается с риском визуальной унификации, которого нет у более крупного стоматологического сайта: когда одинаковые иконки и стандартные цветовые наборы повторяются на 11 страницах услуг и лечения, клиника выглядит шаблонной, а не доработанной. Figma в этом проекте задавала постраничную вариацию иконок — уникальные наборы и трёхцветные комбинации для каждой услуги, — поэтому цикл QA должен был проверять визуальную дифференциацию на уровне компонентов, а не только точность макета.
Команда, пропускающая этот шаг, сдаёт сайт, который воспринимается как взаимозаменяемый с любой другой клиникой на том же шаблоне, — а это противоположно тому, что задумывалось инвестициями агентства в дизайн. Дополнительным ограничением стала готовность контента: несколько страниц услуг были запущены с некликабельными заглушками кнопок, поскольку финальные тексты и интеграция записи агентства ещё не были готовы — это ограничение отслеживалось через BugHerd и было устранено в двух последующих раундах QA.
Как мы это сделали
1. Figma как контракт, шаблон как холст. Файл Figma был дизайн-спецификацией. Фирменный шаблон — базовой структурой страниц. Наша задача — согласовать их страница за страницей: где стандартный макет шаблона совпадал с Figma, мы его оставляли; где Figma требовал отклонения — дорабатывали. Никаких дизайн-решений с нашей стороны.
Мы выбрали строгое следование Figma вместо интерпретации дизайна относительно стандартных настроек шаблона, потому что постраничная палитра иконок и цветов была ключевым отличием на 11 страницах услуг — использование стандартного набора иконок шаблона привело бы к визуальной унификации всех страниц, что было прямо противоположно цели инвестиций агентства в постраничные фреймы Figma.
2. Цикл QA в масштабе доработки темы. Качественная доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, проверить, поправить, проверить, поправить». Из 81 задачи, отслеженных в этом проекте, 51 были итерациями QA — отдельные раунды, в которых агентство отмечало расхождения с дизайном, мы просматривали, исправляли и возвращали сборку на очередную проверку.
За этими раундами стояла гораздо более масштабная сверка: агентство отслеживало более 470 пунктов в двух журналах задач (235 находок SEO и 236 находок CX). Этот объём — не признак нестабильности; именно это отличает шаблонный сайт, выглядящий «приблизительно правильно», от сайта, точно соответствующего дизайну.
Принцип прост: в проекте по доработке темы ценность создаётся именно в цикле QA. Чем короче цикл QA — тем слабее соответствие дизайну, а не более быстрая передача.
3. Доработка без расхождения. За время проекта каждое изменение, которое мы вносили в фирменный шаблон — будь то макет страницы, компонент секции или токен стиля, — документировалось относительно Figma. Ни одна доработка не «просочилась» в общие компоненты шаблона, поэтому работа над этим проектом не ухудшила шаблон для следующего сайта, который будет его использовать.
4. Проверка на разных устройствах. Доработки проверялись в Chrome, Firefox, Safari и Edge на большом экране, планшете и мобильных устройствах — стандартный набор точек адаптации агентства. Каждый раунд QA охватывал страницы, затронутые расхождениями текущего раунда, а не весь сайт, — именно так доработка темы остаётся эффективной без потери покрытия.
51 раунд QA за 43 дня, каждый проверяющий постраничную точность иконок и цветов относительно фрейма Figma, а не трактующий страницы услуг как взаимозаменяемые. Такой темп — более одной итерации в календарный день в среднем — требовался спецификацией постраничной дифференциации; без него инвестиции агентства в 11 различных фреймов Figma остались бы невидимыми при запуске.
Контроль качества
QA перед сдачей в этом проекте было сосредоточено на двух категориях: расхождения визуальной точности (повторяющиеся наборы иконок на страницах услуг, где Figma задавал постраничную вариацию — Redmine #2121) и проверки SEO (неверное имя сайта в Rank Math — #2122); обе прошли через несколько раундов закрытия перед утверждением сборки.
QA перед сдачей проводилось через Site Checker — см. наш подход к QA для категорий и шлюза нулевых ошибок. Собственный слой QA агентства — их инструменты, их процесс — запускался после передачи и фиксировал замечания в общий журнал для нашего цикла исправлений до их согласования.
Доработки оставались в переопределениях для конкретного клиента; общие компоненты шаблона агентства не изменялись.
Результаты
| Метрика | Результат |
|---|---|
| URL доставлено | 21 — 1 главная, 1 about, 1 биография врача, 11 страниц услуг/лечения, 1 страховка, 1 финансирование, 1 членство, 1 контакты и 3 страницы политик |
| Применено шаблонов | 10 из 10 фирменных шаблонов агентства созданы и сопоставлены на 21 странице (главная, About Us, Doctor Page, Service Page, Services Lander, Insurance, Financing, Payment Plan / Membership, Practice Area Lander, Individ. Practice Area Page) |
| Контрольный список запуска | 78 пункта согласованы |
| Отслежено и решено проблем QA / SEO + CX | Более 470 пунктов, согласованных в двух журналах задач агентства (235 SEO + 236 CX) |
| Итераций QA в Redmine | 51 из 81 задачи (63%) отслежены на уровне итераций |
| Сроки | 43 дня, доставлено по графику |
| Трудоёмкость | 39 часов при оценке 39 часов — без перерасхода, без расширения объёма |
| Команда | 4 специалиста |
| Передача хостинга | Работает в среде шаблонов Kinsta агентства |
| Состояние страниц при передаче | 21 / 21 завершённых URL возвращали HTTP 200 в аудите карты сайта |
Если коротко: Figma агентства был реализован на их фирменном шаблоне на 21 странице и 10 шаблонах за 43 календарных дня в рамках оценки в 39 часов.
Процесс
| Этап | Длительность | Результат |
|---|---|---|
| Бриф и оценка | ~2 дня | Figma просмотрен, доступ к шаблону подтверждён, объём согласован |
| Разработка доработки | ~1 неделя | Постраничная доработка шаблона под Figma |
| Итерации QA (параллельно) | ~4 недели | 51 раунд QA; каждый закрыт только после согласования с агентством |
| Раунды правок | ~1 неделя | Коррекции после проверки, обновления иконок, уточнение отступов |
| Сдача проекта | Финальный день | Сайт запущен на Kinsta |
Разработка и QA выполнялись параллельно — это характерно для доработки темы, где «этап QA» не закрывается чисто; цикл идёт непрерывно до согласования с агентством.
Команда
Команда проекта
- Наталия Богатель — ведущий разработчик (доработка шаблона и перенос Figma в макет)
- Павел Сажин — итерации QA и правки
- Тимур Арбаев — итерации QA и поддержка разработчика
- Антон Херсун, xaverPRO — руководитель проекта (оценка, коммуникация с агентством, согласование)
Управление проектом, дизайн и коммуникация с клиентом оставались на стороне партнёрского агентства на всём протяжении. Наша команда была невидима для конечного клиента. Все запросы на доработку поступали через общий журнал задач агентства; ничего из сборки не было напрямую доступно конечному клиенту. Каждый раунд QA закрывался только после подтверждения рецензентом агентства, что расхождение устранено.
Агентствам с библиотекой шаблонов
На компактном ортодонтическом сайте на стоматологическом шаблоне главный риск — визуальная унификация. У этой практики — постраничная вариация иконок и трёхцветные комбинации; у многопрофильной стоматологии — единый набор блоков. Границу слоёв легко стереть: доработки в дочерней теме сломаются при обновлении шаблона, уникальные токены палитры не пробьются сквозь hardcoded fallback’и, редакторский интерфейс забьётся блоками автора.
Подрядчику стоит задавать не вопрос «соберёте ли страницы по шаблону?», а вопрос «как именно вы защитите доработки от обновлений авторского слоя?»
Пришлите исходник шаблона или его ID и макеты. Мы проверим, как бренд-токены пересекаются с авторскими слоями, оценим уязвимость к апдейтам и вернём фиксированную смету в часах. Аудит без оплаты, ответ в течение рабочего дня.
У вас ещё нет ТЗ? Пришлите описание в один абзац — мы вернёмся с вопросами, которые стоит задать. Прислать описание →
Site Checker запускается до того, как агентство что-либо видит.
Перед передачей каждый сборки в тестовой среде прогоняется через Site Checker — WordPress QA-плагин, который мы разработали и поддерживаем. Это шлюз с нулевой терпимостью к ошибкам: к агентству не уходит ничего с открытыми проблемами. Предупреждения рассматриваются и признаются некритическими; агентство получает чистый старт для своего слоя QA, а не тестовый сайт с известными проблемами в очереди.