Phased approach

The audit catalogues 46 findings across 11 cross-page patterns and 35 page-specific issues. That's a lot to absorb at once. The right response isn't to tackle everything in parallel; it's to phase the work so it fits the realities of timing, technical risk, and what we don't yet know.

Two timing constraints worth knowing

Care UK is migrating from Kentico 13 to Xperience by Kentico in roughly 7 months. Most audit findings are front-end (CSS, components, content), but some touch CMS templates and would need to be redone after the migration. Investing in those now means doing them twice.

Some findings aren't design problems on their own. They raise content or IA questions that benefit from research and user testing rather than a quick design pass. Acting on them before the research is in is a guess.

Together, those two constraints break the work into three tracks. Cross-page findings sit at the top of each track because they propagate across templates, so a single fix touches multiple pages.

Phase 1 — Pre-migration quick wins

Front-end CSS or content changes that don't touch CMS templates. Low-risk to ship inside the 7-month window. Reduces visible problems on the live site without locking in any decisions the migration would un-do.

  • C-ALIGN.1
    Section components sit with inconsistent alignment to the page edges, breaking visual flow

    See the scope callout above. The CSS-only path is the assumed Phase 1 scope; the architectural path waits for migration.

  • C-FOOTER.1
    Eight footer navigation links sit below the WCAG AA tap minimum on every page

    The footer is rendered from a single shared component. A one-line line-height change in its stylesheet propagates to all 7 pages.

  • C-FONT.1
    11–14 px text used in 100+ places site-wide

    The 11/12/14 px instances are typography styles, not template structure. The existing body component sizes can replace them via a CSS sweep.

  • C-CAROUSEL.1
    Slick.js pagination dots are 20×20 px (sub WCAG AA touch minimum)

    Slick.js dots are styled by the carousel library's stylesheet. A single CSS rule fixes every instance, no underlying carousel logic touched.

  • C-CHAT.1
    Two persistent bottom-anchored widgets compound on every screen

    Olark is configured externally; Recently Viewed is bespoke JS. Rationalising which one shows when is a config and CSS conversation, not a CMS one.

  • F1.2
    Duplicate H2 "Abney Court" 70 px below the hero ribbon

    The duplicate H2 is an editorial duplication, not a template constraint. Removing it is a single edit on the Care Home Detail page.

  • F1.7
    Slick.js carousel pagination dots, 15+ instances at 20×20 px

    Same fix as C-CAROUSEL.1, applied to the specific carousel instances on this page.

  • F1.9
    Map directions overlay links sub-AA

    The map overlay's tap targets are sized via component CSS. No underlying map integration touched.

  • F00.1
    "Welcome to Care UK" appears as both an H2 and an H3

    Renaming the video card label to remove the duplicate heading is a single content / string change on the home page CMS entry.

Phase 2 — Post-migration structural changes

Findings that touch CMS templates, shared components, or page architecture. These will be redone if attempted before migration, so they're better landed alongside the Xperience by Kentico build. Some of these will also benefit from research-track input (see below).

  • C-PANEL.1
    Inverse-purple section-intro panels are used heavily across the page

    Reducing 8 panels to 1 or 2 isn't a CSS change, it's an editorial decision about which sections deserve the heavy treatment. The content model on the new platform is the right place to constrain this (see content-modelling notes below).

  • C-PANEL.2
    "At a glance" / "Job at a glance", long table-like metadata block

    Splitting all-in-one metadata blocks into 'summary fact + accordion' needs both component changes and content-model support so editors fill in what's promoted vs what's hidden.

  • C-CARD-LIST.1
    Care-home result card is heavy on mobile (around 770–970 px tall per card)

    The result card is the entire weight of the care-home list page. Rebuilding it is a search-results-template change, better aligned with the migration than retrofitted now.

  • C-CARD-LIST.2
    Care-type matrix gives offered and not-offered services the same visual weight

    Whether the care-type matrix becomes labelled icons, an accordion, or stays as a matrix depends on the research track. Structural either way.

  • C-IMG.1
    71% of images across the audit are missing width / height / aspect-ratio

    Touches every image render across every template. Xperience by Kentico templates may already ship with explicit dimensions by default, worth verifying with engineering before scheduling.

  • C-NAV.1
    Top utility tab bar consumes ~50 logical px on every page

    The team is already planning navigation user-testing post-migration. Collapsing the utility tab bar should be informed by that work, not done in isolation now.

  • F2.1
    Result-list cards are the entire weight of this page

    The result list is built entirely from the cards in C-CARD-LIST.1; rebuilding the cards rebuilds this finding.

Most of the page-specific findings (F1.x through F6.x) follow the same pattern as the cross-page findings they reference, and would phase the same way. They're not listed individually here so the page stays scannable.

Research and user-testing track

Some findings raise questions that design alone can't answer. Running these in parallel with Phase 1 means Phase 2 lands on a research-informed brief rather than a designer's best guess.

  • F00.2
    The home page does more than orient the visitor

    Whether the home page is doing too much depends on what users actually expect from it. The team's planned navigation user-testing is a natural place to fold this in, the home page is the entry point into nav.

  • F1.3
    "Meet our team" introduces the section but only shows one person

    Whether 'Meet our team' should preview the team or signpost to a dedicated page depends on what families actually want to know at this point in the journey. Test before redesigning.

Two of the cross-page findings also have a research angle worth running alongside this track: C-PANEL.1 (is the section-intro panel doing wayfinding work, or is it heading-as-design?) and C-CARD-LIST.2 (does the care-type matrix help users compare homes, or does it inflate the card without changing decisions?).

Internal Pre-verification. Not for client share until each item below has been confirmed against the Kentico 13 admin / templates by the dev team.

Content-modelling notes for the migration

Some patterns from the audit suggest improvements in how content is structured in the CMS, not just how it's rendered. These items are inferences from observed front-end behaviour, not from CMS inspection. They're a working list for the dev team to verify against the live Kentico 13 admin and templates before any of them moves into the migration brief. Getting the content model right in Xperience by Kentico means several Phase 2 findings could resolve as side-effects of the migration rather than as bespoke fixes after it.

  1. Section-intro panels as a typed block

    The Care Home Detail page carries 8 dark-purple intro panels (C-PANEL.1) because the current content model lets every section render its own. There's no editorial constraint stopping a page from accumulating panels. A typed section-intro block in the new model could enforce a sensible cap (one or two emphasis panels per page) and define when the heavy treatment is appropriate vs when a lighter pattern fits.

  2. At-a-glance metadata as fields with disclosure rules

    The "At a glance" / "Job at a glance" blocks (C-PANEL.2) show every metadata row at once because the CMS treats them as one block. If each fact is its own field with a "promote to summary" boolean, the template can render the 1-2 summary facts inline and tuck the rest into an accordion. The editor fills in fields; the template handles disclosure.

  3. Care types as a structured taxonomy

    The 7 care types per home (C-CARD-LIST.2) currently render as a matrix because that matches how they're stored. Modelled as a taxonomy with a boolean "offered" per home, the front-end can present them as a matrix, accordion, or labelled icons, whichever the research track lands on, without changing the underlying data. The editorial decision (which care types) and the presentation decision (how to render them) become independent.

  4. Image dimensions as required fields

    C-IMG.1 (71% of images miss explicit dimensions) suggests the current model treats width and height as optional. Making them required (or auto-deriving them on upload) means every front-end render emits explicit dimensions, which resolves CLS by default rather than as a per-template fix.

  5. Typed page sections with limits

    The home page (F00.2 — eleven distinct content blocks below the hero) drifted into "do everything" territory partly because the content model lets editors keep adding sections. Typing each section (hero, intro, care signpost, news, careers signpost) and limiting how many of each can appear on one page constrains the page model without restricting the editorial team where they need flexibility.

  6. Navigation as a content model in its own right

    Worth raising as the team takes nav into user testing post-migration. The primary site navigation and the utility tab bar (CAREERS / CARE HOMES / CUSTOMERS) are structurally different things, the latter is a sister-site / audience switcher rather than primary nav, and modelling them separately makes the eventual nav change easier to land. Hierarchy, link metadata, and audience attribution are all candidates for explicit fields rather than implicit conventions.

  7. Hero with structured promo / offer slots

    Aligned with the hero redesign already in flight. A hero content type with structured fields for primary CTA, secondary CTA, and optional promo / offer slots lets the design system render those signals consistently across pages without bespoke template work per instance. Editors fill in slot data; the template handles when and how it surfaces.

Notes on phasing

  • These groupings are starting points for discussion, not committed plans. Some Phase 2 items might prove to be Phase 1 if they reduce to a CSS-only fix on the existing CMS. Some Phase 1 items might want to wait if engineering bandwidth is constrained ahead of migration.
  • Phase 1 is intentionally short and front-end-only. The point is to land visible improvements ahead of migration without piling work on a team that's about to undertake a CMS migration.
  • Phase 2 isn't a redesign brief on its own. The audit's per-page directions give one half of the picture; the research track gives the other.
  • C-IMG.1 (CLS / image-jump) is worth a conversation with engineering before scheduling. Xperience by Kentico templates may already ship with explicit image dimensions by default, which would resolve it as a side-effect of the migration.
  • C-ALIGN.1 sits in Phase 1 with a scope flag, see the callout under that phase. The CSS-only path is the assumed scope; the architectural path is a separate conversation.