26-Page Dental Template Customisation

Client (end user): SmilePro Dental — a US dental practice in Dearborn, Michigan
Engagement: White-label template customisation for a US marketing agency
Delivered: June 2025 · 59 days · 69 hours · 26 URLs · on schedule

The Craft of Template Customisation

26 pages of a dental practice template customisation across 10 Luminous-template page types — 13 service pages across cosmetic and family care tracks, two doctor bios, smile gallery, and supporting pages — all built to a per-page Figma spec on WP Engine. The agency sourced content per page from the practice’s live site and newly prepared material; the discipline was holding the Figma layout on both service tracks without letting content-sourcing decisions drift the structure.

The value is speed with consistency — but only if the customisation is disciplined. A dev team that “interprets” the Figma, skips QA rounds, or deviates from the template’s design system is worse than starting from scratch.

This case study is a record of a template customisation where an existing dental practice’s service architecture — split across cosmetic and family care tracks — required careful content sourcing from the live site while new Figma-designed pages were built in parallel.

Snapshot

The Brief

A US marketing agency delivered a Figma design for SmilePro Dental and access to their branded WP Engine template system. The agency had sourced the sitemap from their SEO team, worked with the client to define a fresh design direction using the Luminous template, and built content documentation per page. Our task was to take that Figma as the authoritative design spec and customise the template to match it — across a 26-page build where some pages had content pulled from the existing live site and others were designed with entirely new content from the ground up.

The agency’s ask was focused on execution discipline. Apply the template to each page’s Figma frame precisely, flag any content gaps rather than bridging them with guesswork, and sustain the fix loop until every backlog item was reconciled.

The agency’s content documentation did not always align with the Figma block structure — a section designed as a map-and-contact block was delivered with long-form copy under different headings, and some content blocks appearing on staging had no equivalent in the template or the Figma file. Each such gap had to be flagged and resolved through the agency’s shared backlog rather than interpreted on our side.

What the agency was guarding against was a content-sourcing problem that can silently degrade a template build’s consistency. SmilePro Dental had an active site with content organised around its original navigation structure — cosmetic care, family care, and dental services. The new Figma reorganised that content across the agency’s template system with new page structures and a different visual hierarchy. A dev team that migrates content from the old site into new template blocks without checking against the Figma risks embedding structural mismatches that only surface in QA. On a build where the end client had indicated specific imagery from their own archive and had an existing patient gallery, the content mapping discipline was not a preliminary task — it ran in parallel with the customisation through every fix round.

How We Did It

1. Figma-as-contract, template-as-canvas. The Figma file was the design spec. The branded template was the underlying page structure. Our job was to reconcile the two page by page — where the template’s default layout matched the Figma, we kept it; where the Figma required a deviation, we customised. No design decisions originated on our side.

2. Content-source mapping before building. SmilePro Dental’s service pages fell into two categories: pages with content coming from the agency’s structured per-page documents, and pages where the source was the practice’s existing live site. Before building, the content lineage for each page was confirmed — existing page content was reviewed against the Figma block structure for fit, and gaps were flagged to the agency rather than silently filled from the template’s default copy. The cosmetic-versus-family-care split in the practice’s service taxonomy drove this: a content block that worked on a cosmetic care service page (veneers, implants, whitening) would not carry the right framing to a family care page (crowns, bridges, endodontic care) if lifted without review.

3. QA cycle across cosmetic and family tracks. The agency’s shared issue backlog accumulated 78+ items across SEO and CX categories, reconciled against a 39-item launch checklist. Post-handoff agency QA flagged meta, imagery, and content-block issues across both service tracks; each round was closed only after the agency-side reviewer confirmed the delta was resolved. The two-track service structure meant that a fix applied to one cosmetic care page needed to be checked for consistency across all pages in that track — a regression that is easy to miss when a build has 13 service pages of two distinct flavours.

4. Customisation without drift. Every change we made to the branded template — layout, section component, style token — was applied within the per-client override layer. The agency’s shared Luminous template was not modified. This matters on a WP Engine multi-tenant template environment where other practices build on the same base: SmilePro Dental’s two-track service customisation did not propagate into the template shared components.

5. Cross-device verification. Customisations were QA’d against Chrome, Firefox, Safari, and Edge on desktop, tablet, and mobile viewports — the standard agency breakpoint set. Each round covered only the pages affected by that round’s deltas, which kept iteration cycles tight even as the agency backlog worked through its full list.

The recurring tension in this engagement was content that arrived structured differently from the Figma — a map-and-contact block where the agency’s documents sent long-form copy, a FAQ section that had to be stripped mid-build. Flagging each gap to the shared backlog rather than interpreting it on our side was what kept the cosmetic and family tracks consistent with each other through five QA rounds.

Operational Integrity at handoff

The map-and-contact block on the staging build held long-form copy where the Figma showed a CTA — built to the agency’s own content documents, so the mismatch surfaced at first QA pass rather than slipping into handoff; the SEO QA task also flagged a duplicate-URL ambiguity on row 9 of the shared backlog that required agency clarification before our team could close it. Pre-handoff QA ran through Site Checker — see our QA discipline for the categories and the fail-zero gate. The agency’s own QA layer — their tools, their process — ran post-handoff and surfaced issues into the shared backlog for our fix loop until they signed off.

Customisations stayed in the per-client overrides; the agency’s shared template components were not modified.

Results

The outcome, restated plainly: the agency’s Figma was implemented against their branded template across 26 pages and 10 templates, over 59 calendar days, inside the 69-hour estimate.

Process

Development and QA ran concurrently — this is characteristic of template-customisation work, where no “QA phase” closes cleanly; the loop runs continuously until the agency signs off.

Team

Delivery team

• Nikita Tumasevic — lead developer (template customisation and Figma-to-layout mapping)
• Pavel Sazhin — QA lead (backlog review, agency coordination)
• Anna Polunina — template customisation support and QA
• Evgeniy Karpov — developer (SEO QA resolution, post-handoff CX fixes)
• Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)

The agency held the end-client relationship throughout. All customisation requests arrived through the agency’s shared backlog; SmilePro Dental did not interact with our team directly. Each fix round was released only once the agency-side reviewer confirmed the changes were resolved to spec.

For agencies with a branded template system