From investigation to delivery:
building a scalable component library

The business had a content problem disguised as a design problem. Every campaign needed a custom layout. Publishing anything took a week. I was brought in to design the adviser platform — but fixing the platform without fixing the publishing infrastructure would have collapsed inside six months. I solved both.

I audited from both ends at once — how advisers used the platform, and how editors maintained it. The hypothesis was that both groups were working around the same structural problems. It was right: the navigation that confused advisers was the same architecture that forced editors to build one-off templates every time a page didn't fit.

Eight stakeholder groups across product, engineering, content, legal, and regional teams — each with different definitions of success. The design had to satisfy all of them without becoming a compromise.

The two users the design had to serve simultaneously

• Publishing was slowed by repeat decisions. Editors had to re-think hierarchy and layout each time, instead of composing with known blocks.
• Consistency broke at template boundaries. Similar content looked and behaved differently depending on where it lived.
• Unclear rules reduced confidence. Without component constraints, teams relied on workarounds.
• "What can I build?" wasn't obvious. The system needed visible options and examples to guide creation.

I built each component around a content failure I'd observed in the audit — not around a theoretical page type. If I'd never seen an editor work around it, it didn't get a component. That constraint kept the system from becoming a theoretical framework and made it something the team could actually use from day one.

Design principles

• Composable by default: pages built from blocks, not one-off layouts.
• Flexible with guardrails: editors can customise content, not structure.
• Defined states: empty, error, and loading states considered from the start.
• Recognition over recall: named variants and documentation make options visible without memorising rules.

01 — Navigation & structure

A consistent system users don't have to learn twice

Global navigation, section headers, and breadcrumbs follow the same structural logic across every page. Advisers navigating from a fund article to a document download to a CTA block should never need to reorient themselves.

Editorial rule: Navigation labels are locked — editors can add sections but cannot rename primary nav items without a design review. Consistency here directly affects adviser confidence in the platform.

02 — Page hero module

One component, three valid configurations

The hero module covers the three real-world cases: image-led editorial pages, copy-led insight pages, and utility pages that need minimal decoration. Each variant has defined field rules and CTA behaviour so editors can't break the layout.

Design decision: Early versions had five hero variants. Testing with content editors showed they couldn't reliably distinguish when to use which. Consolidating to three — with clear labels — eliminated the most common editorial error.

03 — Mega tabs

Breaking dense content into navigable chunks

Advisers often need to cross-reference fund data — switching between performance, charges, and documents without losing their place. Mega tabs give each content type its own clearly labelled surface while keeping the page context intact.

Constraint navigated: The client wanted all content on a single long page. Usability testing showed advisers lost orientation on scroll-heavy pages. Tabbed structure tested significantly better for orientation and task completion.

04 — CTA blocks

Conversion without visual noise

CTA blocks cover the four real use cases: single primary action, primary + secondary, with supporting copy, and within a grid of peer options. Constrained layouts mean editors can't produce the misaligned or typographically broken CTAs that plagued the previous system.

Editorial guardrail: CTA label length is capped at 40 characters with a CMS field validator. This prevented the broken-wrap CTAs that appeared on 30% of pages in the legacy system.

05 — Document list

Resources that advisers can actually find and trust

The document list handles single downloads, curated lists, and mixed resource sets — all with the same visual structure and defined metadata fields. Advisers know exactly what they're downloading before they click.

Research finding: Advisers cited missing publication dates and unclear document types as reasons for not trusting downloads. Both are now required fields — the CMS won't publish a document card without them.

06 — News block

Insight content that scans, not just reads

The news block is the workhorse of the insight hub — used for market commentary, fund updates, and editorial pieces. Card hierarchy (category → headline → date → summary) was tested with advisers to confirm scanning order matched how they evaluated whether to click.

Consistency principle: The news block and document list share the same card hierarchy intentionally. Advisers only need to learn the pattern once — it works whether the content is an article or a PDF.

The product worked. But the outcome that changed how the team operated was publishing independence — getting to a state where content teams no longer raised a ticket for every new page. That happened within weeks of launch.

• Design for real workflows, not page views. Advisers think in tasks and conversations, not URLs — experiences should reflect how they actually work across tools and providers.
• Turn events into digital assets. Treat every live event as a source of ongoing articles, tools, and artefacts that extend its value long after it's finished.
• Brand story and UX are inseparable. Without a clear narrative about who you are, information architecture and content will always feel fragmented.
• Research is a powerful alignment tool. Bringing stakeholders around a shared view of users and journeys can unlock momentum far beyond a single project.