This SOP governs how Hardt Web Studio implements designs in Kadence — from the first Customizer setting to the final QA pass. The goal is not literally "pixel perfect" but design-faithful and intentionally consistent: typography, spacing, colors, proportions, and component behavior that are deliberate and repeatable across every page and screen size.
The three-layer mental model
Every Kadence build has three layers. Work top-down through them — never skip to layer three. Layer 1: Global design tokens (colors, fonts, spacing). Layer 2: Component library (reusable block patterns). Layer 3: Page-level assembly. Skipping layers 1 and 2 and going straight to page building is the source of 90% of inconsistency problems in Kadence sites.
Common failure mode
Styling elements one at a time instead of setting global tokens first, then building components, then assembling pages. This produces sites that look inconsistent and require hours of manual correction.
If working from a Figma mockup or reference design, extract all design values before touching Kadence. This document becomes your build spec and prevents ad-hoc decisions during the build.
A
Colors — extract every hex value
List every color used anywhere in the design: primary, secondary, accent, text, background, border, error, success. A well-designed site has 6–12 colors total. Write down the exact hex codes. Name them semantically (Primary, Text Dark, Background, Border) not by appearance ("the blue one").
B
Typography — font families and type scale
Record: font families (typically 1–2), sizes for H1–H6 and body, line heights, letter spacing for headings and body. Most professional designs use a base unit (8px or 4px) scaled up: 16, 24, 32, 48, 64px. Identify the scale in use.
C
Spacing scale — the repeating unit
Identify the consistent spacing values: section padding, column gap, heading-to-paragraph margin. Common scales: 8, 16, 24, 32, 48, 64, 96px. Write these down — you will use them on every block's padding and margin settings.
D
Border radius, shadows, dividers
Are buttons and cards square, slightly rounded (4–6px), or pill-shaped (24px+)? Is there a box shadow on cards? What is the exact value? Are section dividers used — and if so, are they rules, gradients, or diagonal cuts?
Map your extracted colors to Kadence's named palette slots. Name them semantically. Once set, every block references these slots — change a color once and it updates everywhere.
Recommended slot naming:
- Palette 1: Primary brand color
- Palette 2: Secondary / accent
- Palette 3: Dark text color
- Palette 4: Body text
- Palette 5: Muted / secondary text
- Palette 6: Background
- Palette 7: Surface / card background
- Palette 8: Border color
- Palette 9: White
Set font families, sizes, weights, line heights, and letter spacing for H1–H6 and body text. Kadence connects directly to Google Fonts. Set the base body font size — use 16–18px minimum for medical and nonprofit clients who often serve older populations.
3
Container width and global spacing
Set Container Width (typically 1200–1280px for modern designs). This controls the maximum content width on all pages. Set once, never touch per-page.
In Customizer → Buttons, set primary and secondary button styles: background color, text color, border radius, padding, font size, font weight, hover state. Every button block on the site inherits these styles. Never style individual button blocks unless there is a specific semantic reason.
5
Header and footer builders
Build header and footer before any page content. They appear consistently on every page automatically once built. For medical clients: sticky header, click-to-call button, booking CTA visible in the header. For nonprofits and churches: donate button and service times prominent.
Rule: No page content is built until all five global settings above are configured. The global settings are the foundation. Building pages before setting globals is like framing walls before pouring the foundation.
Before building any client page, build a blank unpublished page called "[ClientName] — Design System". On this page, build one polished example of every component that will repeat across the site. Save each as a Kadence Block Pattern. From this point forward, you insert patterns — you never build a component from scratch twice.
→
Standard components to build for every medical / nonprofit site
- Full-width hero — heading, subheading, CTA button, optional background image
- Two-column feature section — icon/image left, text right
- Three-column service or program card grid
- Testimonial / impact story section
- Team member or staff grid
- Stats or impact numbers section
- CTA banner — full-width, single action
- Contact form section
- Donate section (nonprofits) or Booking section (medical)
- FAQ accordion section
- News / blog post grid
How to save a pattern: Select all blocks in the component → click the three-dot menu in the toolbar → "Create pattern" → name it with a prefix (e.g. HWS — Hero Full Width). To insert on any page: open the block inserter → Patterns tab → find by name.
| Element | Desktop value | Mobile value | Notes |
| Full section padding | 80px top/bottom | 48px top/bottom | Hero and major content sections |
| Compact section padding | 48px top/bottom | 32px top/bottom | Secondary content, form sections |
| Hero section padding | 120px top/bottom | 64px top/bottom | Homepage hero only |
| Column gap | 32–40px | 24px | Gap between columns in Row block |
| Heading → paragraph | 16–24px | 16px | Margin-bottom on heading block |
| Before new subheading | 32–48px | 24px | Space before a new H2/H3 in a section |
| Card inner padding | 24–32px | 20px | Padding inside testimonial or feature cards |
Never use arbitrary spacing values. Pick from your spacing scale (multiples of 8px) and use them consistently. A section with 83px padding next to one with 80px padding looks identical in the builder but creates subtle visual noise that makes a site feel unpolished.
Advanced: CSS custom properties for spacing. Define your spacing scale as CSS variables in Customizer → Additional CSS, then reference them in block settings.
Additional CSS — spacing scale
:root {
--space-xs: 8px;
--space-sm: 16px;
--space-md: 24px;
--space-lg: 32px;
--space-xl: 48px;
--space-2xl: 64px;
--space-3xl: 80px;
--space-4xl: 120px;
}
✓
Use heading levels — not size overrides
Always set the heading level (H1, H2, H3) in the block and let global typography control the size. If every H2 uses a custom per-block size, changing the design later means touching every single block. Use global styles — override per-block only for deliberate exceptions.
✓
Body text — never override per paragraph
Set body copy at the paragraph block level using the global size. Resist making individual paragraphs larger or smaller unless there is a specific semantic reason (e.g. a legal disclaimer at 11px).
✓
Buttons — global styles only
Primary and secondary button styles are set globally in the Customizer. Every button block inherits those styles. Never customize individual button blocks — if you find yourself doing this, that is a signal to update the global button style instead.
✓
Minimum body font size for medical / nonprofit
Use 16–18px body text minimum. Medical clients and nonprofits frequently serve older populations. Readability is a mission issue as much as a design issue. Never go below 16px for body copy on these sites.
| Scope | Where to add | Use for |
| Global styles | Customizer → Additional CSS | Spacing variables, global hover states, link colors, font overrides |
| Page-specific | Kadence Page Settings → CSS tab | One-off layout adjustments specific to a single page |
| Block-specific | Block → Advanced → Additional CSS Class + global CSS | Targeting a single instance of a component that needs a variation |
The DevTools workflow. Right-click any element on the staging site → Inspect → identify the exact Kadence CSS class applied → modify the value in DevTools to confirm the fix visually → copy the CSS to Additional CSS.
CSS you will write most often on Kadence builds:
- Hover states on buttons and cards that Kadence does not expose in the UI
- Fine-tuning mobile typography sizes when global responsive settings are not granular enough
- Adding a border or subtle divider between sections
- Overriding Kadence's default link underline behavior
- Controlling exact column width when the percentage slider does not hit precisely
- Custom focus states for accessibility compliance
- Adjusting the z-index of a sticky header in edge cases
Example — custom hover state on a card component
.hws-service-card {
transition: box-shadow 0.2s ease, transform 0.2s ease;
}
.hws-service-card:hover {
box-shadow: 0 8px 32px rgba(0,0,0,0.10);
transform: translateY(-2px);
}
Avoid CSS debt. If you find yourself writing more than 50 lines of custom CSS to make something work, that is a signal you are fighting the framework. Step back and reconsider the approach — either use a different Kadence block, restructure the layout, or accept a slight design deviation rather than accumulating brittle CSS overrides.
→
Responsive discipline — the per-section habit
After building each section at desktop, immediately switch to tablet view in the block editor and check it, then check mobile. Fix responsive issues per section as you go — not at the end of the project. Responsive debt compounds.
Common responsive adjustments:
- Reduce section padding from 80px to 40–48px on mobile
- Reduce heading sizes if they wrap awkwardly at small widths
- Check multi-column layouts stack in correct reading order
- Verify CTAs and phone numbers are tap-sized (minimum 44px touch target)
- Check that hero text is still legible over background images on mobile
→
Show/hide by device — use deliberately
Kadence Blocks Pro's show/hide by device feature is powerful but easy to abuse. Use it for elements that genuinely should not appear at certain sizes — a decorative large background element, a desktop sidebar — not as a way to avoid making something responsive. Hidden elements still load — they just do not display.
→
Test on real devices before delivery
Chrome's mobile simulator is useful but not definitive. Before any client delivery, test the staging URL on: a real iPhone (Safari), an Android device (Chrome), and desktop Chrome. BrowserStack free tier covers edge cases. Common simulator failures: font rendering differences, tap target sizes, scroll behavior on iOS.
Kadence starter templates are scaffolding — use them for structural bones, then replace everything visible to the user. After these five moves, the template origin is invisible and the site reads as a custom build.
Go to Customizer → Typography and replace all font families with the client's brand fonts. Nothing says "starter template" more than the default Kadence font pairing still showing up on a client's live site.
2
Replace the entire color palette
Go to Customizer → Colors and update every palette slot with the client's actual brand colors. Do not keep any default template colors, even ones that happen to be similar — use the exact client hex values.
Remove every section from the template that you are not using. Do not just hide it or leave it with placeholder text — delete it. Unused sections add page weight, create confusion during handoff, and occasionally appear accidentally.
4
Rebuild the hero from scratch
Use the template's hero layout as a reference for proportion and structure, but delete the blocks and rebuild with entirely new content, images, and spacing values. The hero is the first impression — it must not look like any other site using the same template.
5
Add one section type not in the original template
Build at least one section that does not appear in the original starter template. This breaks the template fingerprint entirely. For medical sites: an insurance/credentials section. For nonprofits: an impact numbers section or a board member grid.
Open the staging site on your phone and scroll every page top to bottom. You are looking for design-system consistency — not individual errors. Ask: does every section feel like it belongs to the same site?
- Spacing rhythm is consistent — no section noticeably tighter or looser than its neighbors
- All headings use global styles — no manually-sized heading blocks
- All buttons use global button styles — no individually-styled button blocks
- All colors reference palette slots — no hard-coded hex values in individual blocks
- Typography is consistent across all pages — no rogue font families or sizes
- Mobile layout checked on real device — not just Chrome simulator
- Hero text legible on mobile over any background image
- All CTAs are above fold on mobile without scrolling
- Phone numbers are tap-to-call links on all instances
- All images have alt text — run WAVE to confirm
- Color contrast passes 4.5:1 on body text — check with WebAIM
- PageSpeed 90+ on mobile — test homepage and one key service/program page
- All forms tested — submission received, confirmation email sent
- No placeholder text or template copy remaining anywhere
- All external links open in new tab where appropriate
- Footer copyright year is current
- No broken images — check on mobile where paths sometimes resolve differently
- Favicon is set and correct
- Browser tab title shows correct page title on every page
- Custom CSS file reviewed — no debug/test code left in
The phone scroll test. The fastest way to catch inconsistencies is a slow phone scroll through every page. Your eye notices rhythm breaks faster on a small screen than on a large monitor. Do this last, after everything else — it catches what the builder does not surface.