Доработка темы детской стоматологии: 47 страниц за 106 дней

Клиент (конечный пользователь): House of Smiles Pediatric Dentistry and Orthodontics — детская стоматологическая и ортодонтическая клиника в Cypress, Texas
Формат сотрудничества: White-label доработка темы для маркетингового агентства из США
Сроки: ноябрь 2025 · 106 дней · 74 часа · 47 URL · в срок

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

Клиника с двумя направлениями — 28 страниц услуг, разделённых между детской стоматологией и ортодонтией, — дорабатывалась на основе системы из 7 шаблонов Figma. Опечатка в номере телефона кочевала по тестовой среде с первого дня. Два расходящихся пути пациента на одном шаблоне — и каждая постраничная проверка становилась критической: аудит AutoQA выявил переставленную цифру (281-172-70511), разошедшуюся по всем 47 страницам, до согласования работы агентством.

Шаблонная доработка даёт скорость и единообразие — но только при дисциплине. Команда, которая вольно трактует Figma, пропускает этапы QA или отходит от дизайн-системы шаблона, — хуже, чем разработка с нуля.

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

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

Маркетинговое агентство из США передало нам дизайн Figma для House of Smiles и цель развёртывания на своей брендированной шаблонной системе под Kinsta. Агентство уже выполнило подготовительную работу: форму с требованиями клиента, аудит дизайна, настройку хостинга, контент-план и подготовку Google Docs для каждой страницы. Им нужна была команда разработчиков, которая точно перенесёт Figma на шаблон, пройдя через столько итераций доработки, сколько потребуется для соответствия дизайну.

Задача была чисто исполнительской — с педиатрической спецификой. Стоматологические и ортодонтические клиники ведут две отдельные ветви услуг на одном сайте: дерево общей детской стоматологии (чистка, герметизация, пульпотомия, неотложная помощь) и дерево ортодонтии (раннее лечение, традиционные и керамические брекеты, элайнеры, ретейнеры). Обе ветви должны быть доступны с одного шаблона, ни одна не должна перевешивать другую, и обе должны читаться как дружелюбные к детям, вызывающие доверие у родителей и профессионально убедительные — тональные решения, которые агентство уже приняло в Figma.

Риск, от которого агентство страховалось, особенно характерен для практик с двумя направлениями: шаблон страницы услуг используется 28 раз в обеих ветвях, а это значит, что строка CTA или метка формы, правильно применённая на стороне педиатрии, может незаметно перекочевать на сторону ортодонтии, если доработка неточна.

Кнопка «записаться на приём», появившаяся на странице ортодонтического лечения вместо «записаться на консультацию», — это не ошибка стилизации: она направляет неверный путь пациента в неверный момент конверсии. Такая ошибка в контенте не обнаруживается при визуальной проверке QA; она требует целенаправленной постраничной проверки каждого элемента шаблона, содержащего текст для пациента.

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

1. Figma как контракт, шаблон как холст. Файл Figma был спецификацией дизайна. Брендированный шаблон — базовой структурой страницы. Наша задача — согласовать их постранично: где шаблон совпадал с Figma, мы его оставляли; где Figma требовала отклонения — дорабатывали. Никакие дизайн-решения не принимались на нашей стороне. Для педиатрического сайта, который должен быть визуально тёплым, но не инфантильным, и ортодонтического сайта, который должен быть клинически убедительным, но не холодным, — это правило «без импровизации» было критичным: каждое тональное решение уже было принято в Figma.

2. Две ветви услуг, один набор шаблонов. Детская стоматология и ортодонтия получили свои поддеревья услуг под общим разделом услуг. Один и тот же шаблон страницы услуг использовался 28 раз в обеих ветвях — с адаптацией под специфику направления: текст, изображения и правильный CTA для следующего шага (страница герметизации ведёт к «записаться на приём»; страница ортодонтического лечения — к «записаться на консультацию»).

Правильно расставить эти CTA на 28 страницах — задача уровня QA по шаблону, а не деталь стилизации. Несколько позиций в очереди задач CX агентства были исправлениями неверных CTA; цикл QA существовал именно для их выявления.

3. Цикл QA в масштабе доработки темы. Чистая доработка темы — это не «собрать один раз, проверить один раз». Это «собрать, QA, поправить, QA, поправить». Из 24 задач, отслеженных в этом проекте, 14 были именованными итерациями QA (суффикс «-qa» в названии задачи) — отдельные раунды, в которых агентство отмечало расхождения с дизайном, мы проверяли, исправляли и возвращали сборку на новую проверку.

За этими раундами стояла гораздо более масштабная работа: агентство отследило более 175 позиций в трёх вкладках очереди задач (SEO, DEV и CX), крупнейшая из которых (DEV, 120 позиций) была проведена нами до завершения и QA.

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

4. Доработка без отклонений. Каждое изменение, которое мы вносили в брендированный шаблон — будь то макет страницы, компонент секции или стилевой токен, — документировалось относительно Figma. Ни одна доработка не «протекла» в общие компоненты шаблона, то есть работа над этим проектом не ухудшила шаблон для следующего сайта. Мы выбрали постраничные переопределения вместо изменения общих компонентов, потому что сохранение целостности шаблона для следующего клиента агентства было важнее маржинального выигрыша в скорости от правки базового слоя напрямую.

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

Цикл QA — вот что сделало соответствие Figma достижимым в масштабе 47 страниц. Четырнадцать именованных итераций — каждая требовала утверждения агентством перед переходом к следующей — удерживали сборку в соответствии с дизайном на каждом этапе, включая аудит номеров телефона, выявивший 281-172-70511, разошедшийся по всем 47 страницам до того, как агентство увидело финальную сборку в тестовой среде.

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

Site Checker выявил две проблемы с контентом до того, как агентство увидело финальную сборку: номер факса (281-727-0512) отображался вместо основного номера (281-727-0511) в нескольких блоках — обнаружено аудитом номеров — а кириллический текст из правки в середине сборки просочился на главную страницу рабочего сайта и потребовал очистки перед передачей.

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

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

Результаты

Результат, выраженный прямо: Figma агентства была реализована на их брендированном шаблоне на 47 страницах и 7 шаблонах за 106 календарных дней в рамках оценки в 74 часа.

Процесс

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

Команда

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

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

Партнёрское агентство вело управление проектом, контроль дизайна, сбор контента и отношения с конечным клиентом от начала до конца. House of Smiles никогда не взаимодействовали с нашей командой — сборка двигалась через общую очередь задач агентства, и каждый раунд переходил к следующему только после утверждения их проверяющим.

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