Building an evidence-led foundation for a public energy platform

Between late 2025 and mid-2026, I helped LCCC’s Web Presence team move away from reactive web delivery and towards a more evidence-led product practice.

The organisation was entering a period of growth. Its public-facing estate already stretched across the corporate website, dashboards, registers, a Data Portal, allocation-round microsites and adjacent operational tools. At the same time, the business was exploring how digitalisation and AI could help it scale more effectively.

That created a broader design challenge than a website refresh.

The immediate need was to improve how people found information, understood complex services and moved between products. The longer-term opportunity was to make the estate more legible, measurable and governable, so that future AI-enabled experiences could be introduced with a clearer sense of purpose and a stronger basis for deciding where they would genuinely create value.

Rather than beginning with speculative AI features, I focused first on the conditions that would make AI useful.

I led a connected programme of work spanning audience discovery, user intent, content structure, critical journeys, information architecture, measurement, continuous discovery and design-system foundations. The result was not a single redesign. It was a stronger basis for deciding what to improve, how opportunities should be shaped and how the organisation could evolve its product estate without losing sight of the people using it.

LCCC operates at the centre of a rapidly evolving energy landscape.

Its role is not limited to a single scheme, technology or website. The organisation supports a widening portfolio that includes Contracts for Difference, the Capacity Market, carbon capture, low-carbon hydrogen, regulated infrastructure and emerging levy mechanisms.

The scale is substantial. In Allocation Round 7 and AR7a alone, LCCC signed more than 200 Contracts for Difference representing 14.7 GW of renewable electricity generation across fixed-bottom and floating offshore wind, onshore wind, solar and tidal-stream power. Those contracts will be managed over terms of 15–20 years.

The offshore-wind projects secured through the round were also reported to unlock an estimated £22 billion of private investment.
The public-facing estate reflects that complexity.

LCCC publishes role-based guidance, FAQs, official registers and a substantial set of interactive dashboards. The CfD dashboard area alone includes a dozen views covering allocation rounds, levy rates, historical data, operational costs, supplier payments, locations, determinations, in-period tracking, key dates and forecasts.

Alongside this, the Data Portal provides 38 public datasets, downloadable in CSV and JSON formats, with API access and update notifications for users who want to follow particular datasets or publishers. While some may see this as a conventional corporate website, It is a distributed information ecosystem supporting people with very different levels of knowledge, responsibility and intent at varying times.

A generator may need to understand an upcoming allocation round, then move through award, onboarding and long-term contractual obligations.
A supplier may need to interpret levy rates and forecast payments.
An analyst may move from a dashboard into a downloadable dataset.
A journalist or policy stakeholder may need an authoritative record.
A member of the public may simply be trying to understand what LCCC does and why it matters (because our work affects them).

The estate had grown organically over time. Content structures reflected BAU demand. Navigation often reflected internal ownership. Audience definitions varied across teams. Measurement was limited, and responsibilities were not always explicit.

The visible friction was fragmented journeys. The deeper issue was ambiguity.

Without a clearer understanding of audiences, needs and outcomes, trade-offs remained subjective. Navigation conversations could become preference-led. Requirements drifted. Delivery teams absorbed uncertainty. New ideas, including AI ideas, risked being framed around novelty rather than meaningful value.

My previous work on Zero and Settlements had already shown me the importance of baselining user experience in complex operational products. When I moved into Web Presence, I saw an opportunity to establish a comparable foundation across the wider public-facing estate.

Before redesigning navigation or refining components, I wanted the team to answer a simple question:

Who are we building for, and what are they trying to do?
I initiated Content Discovery across HR, CASE, Strategy, Analytics, Scheme Operations, Levy Operations, Policy and Data Engineering.
The aim was not to create a static set of personas or a large content inventory. It was to translate distributed organisational knowledge into a more useful product model.

I shaped the interview guides, recruitment materials, facilitation approach, synthesis structure, findings reports and stakeholder presentations. This gave us a clearer view of the audiences Web Presence served, the tasks they were trying to complete and the structural barriers getting in their way.

From broad business segments to useful product context

The organisation already had high-level audience categories. These were useful for strategic direction, but too broad for product decisions.

I developed a more granular working audience database that connected each segment to its parent business category, priority level, assumed needs, content types sought, relevant product touchpoints, related projects and confidence level. This made the estate easier to reason about.

It also exposed an important nuance: the same organisation could present different needs depending on the task at hand. A generator trying to confirm a compliance requirement is not performing the same job as an analyst looking for historic data, or a journalist seeking an authoritative statement.

From broad business segments to useful product context

The most persistent problems were structural rather than volumetric.
People needed to find current guidance, understand scheme rules, locate levy rates, access registers and data, verify official statements, understand LCCC’s role and identify the correct next step.

The recurring friction included scattered entry points, fragmented archives, unclear versioning, terminology barriers, over-reliance on PDFs and inconsistent navigation patterns.

That changed the nature of the conversation.

Instead of asking:

“What content should we publish next?”

we could ask:

“What structure, journey or reusable pattern will help this audience achieve its goal?”

I also used AI during parts of the discovery process to help organise and synthesise a large volume of inputs. It accelerated the work, but it did not replace judgement. The interpretation, prioritisation and decisions remained my own.

Why this mattered for AI

This was the first layer of AI preparedness.

AI cannot reliably support users, or internal teams, if the organisation cannot articulate who the audience is, what the user is trying to achieve, which information is authoritative, what a good outcome looks like and where risk exists.

The audience and content work created a more grounded opportunity lens for future AI exploration.

Once the audience baseline existed, I made a second decision.

I stopped treating Web Presence as a collection of separate websites and started modelling it as one connected service ecosystem.

I created a shared model for content and journeys

Web Presence did not own every part of the end-to-end experience. But it still shaped how users were prepared for an action, guided towards relevant information, handed into adjacent services and supported when something went wrong.

That included journeys moving between public-facing products and operational tools such as Zero.

Shared intent instead of dozens of disconnected journeys

The audience database contained many granular groups. Designing a bespoke journey for each one would have created more complexity, not less.

I therefore clustered needs around shared intents such as:

understanding schemes and policies
accessing operational guidance
verifying compliance and registers
accessing data and market insights
tracking official communications
understanding the organisation and careers

This produced a smaller set of critical journeys representing the tasks the wider ecosystem needed to support well.

The critical-journey framework also made prioritisation more explicit. A journey could be considered critical because of organisational importance, compliance dependency, scheme-participant need, behavioural evidence, cross-product complexity or public-value risk.

Mapping the CfD lifecycle

I also initiated a CfD lifecycle map spanning pre-allocation activity, application preparation, auction, award and contract creation, onboarding, milestone delivery, construction and operations, payments and compliance, and ongoing support.

The map connected those stages to the Corporate Website, CfD Allocation Site, Data Portal, Registers, Dashboards, Zero and related offline processes.

This changed the level at which design conversations could happen.

Instead of asking how an individual page should look, we could ask whether an audience had a clear entry point, whether hand-offs between products were intentional, what context was missing at a given milestone and where users were likely to lose confidence.

It also created a better frame for exploring where contextual assistance might add value, and where a deterministic interaction would remain safer.

This was the first layer of AI preparedness.

AI cannot reliably support users, or internal teams, if the organisation cannot articulate who the audience is, what the user is trying to achieve, which information is authoritative, what a good outcome looks like and where risk exists.

The audience and content work created a more grounded opportunity lens for future AI exploration.

Why this mattered for AI

The lifecycle model created a second layer of AI preparedness. AI should not be attached indiscriminately to pages. It should be considered within a real journey, with a clear audience, a clear task and a clear measure of success.

For example, a scheme participant may benefit from contextual guidance explaining where they are in a lifecycle, what matters at that stage, whether an action is required and which tool they need to use next.

That is a more credible front-stage opportunity than a generic chatbot.

The same journey context also exposes back-stage opportunities, such as helping teams identify relevant content, maintain consistency or support page creation against known patterns.

My third decision was to prevent the work ending as a static discovery report. This programme was intended to move the needle in the near term while creating a more coherent path into the future.

The discovery work shaped committed and emerging initiatives including Experience Uplift, landing-page signposting, navigation aligned to user intent, clearer access to data and registers, a Data Resource Centre, CfD timeline improvements, scheme-driven notifications, content clarity and trust signals, and a more consistent set of UI foundations.

Connecting strategy to delivery

I codified the emerging direction in a Web Presence UX Strategy.

The strategy defined five experience themes:

Finding and Navigating Information
Understanding Information
Understanding Data and Impact
Completing Tasks Across Services
Consistency Across the Platform

These themes connected the Product Vision to active and emerging initiatives such as IA Uplift, Data Resource Centre, Content Model v1, Design System and UI Foundations, Insights Experience and AI Knowledge Access.

Then I mapped this to the CfD Blueprint providing a meta lens within a Birds Eye lens.
This gave the team a clearer way to cluster requests, interpret BAU work as signals and decide which issues warranted deeper shaping.

Building a continuous
evidence loop

I then connected the strategy to a Continuous Discovery model

The model brought together Product Panel research, behavioural monitoring, engagement surveys, stakeholder feedback, critical-journey reviews, usability testing, Content Discovery findings and BAU ideas.

This created a route from evidence to roadmap decisions, while making it easier to challenge assumptions before they hardened into delivery work.

Introducing journey-level measurement

Existing NPS data offered a broad sentiment signal, but it could not explain where a journey was failing.

I began defining a more targeted approach based on CUJ’s, using event triggers; this would give us capabilities like journey-health monitoring, diagnostic analytics, Clarity (a tool for behavioural analytics) recordings, qualitative feedback and Product Panel validation.

For public-facing Web Presence experiences, HEART provides a useful default measurement lens.
For must-complete scheme-participant pathways, CASTLE-informed measures may also be appropriate where confidence, learnability, efficiency and task success matter more than generic engagement.

Because instrumentation was still being established, I treated the early work as baseline-building rather than evidence of long-term uplift. The value was not a prematurely claimed metric. It was the creation of a measurement model the team could continue using after I left.

Codifying design intent

I also began shaping a lean Design System MVP.

The immediate goal was practical: reduce design drift, improve accessibility, clarify responsive behaviour, reduce duplicated effort and make hand-offs more predictable.

The documentation separated WP-wide standards from product-specific standards and outlined a roadmap covering typography, semantic colour, spacing and layout, responsive behaviour, accessibility, UI patterns, content patterns, microcopy, data formatting, interaction states, components, UI kits and lightweight governance.

This wasn‘t simply a component-library exercise, It was a way of codifying what good looked like across the estate in the context of shared intent.

Why this mattered for AI

This created a third layer of AI preparedness. If AI is used to support page creation, content generation, design iteration or service operations, it needs curated context.

Without codified standards, AI can accelerate inconsistency. With them, AI-assisted workflows can be grounded in brand, accessibility, content structure, approved patterns, interaction behaviour, component constraints, governance, audience context and user intent.

The longer-term design-system roadmap was therefore not just about reusable components. It created the basis for AI-assisted workflows that could understand, recommend, validate and support design-system usage over time.

One potential application was page building. If CASE authors were supported by AI when creating or refining pages, the quality of that assistance would depend heavily on the system beneath it: approved templates, content rules, accessibility expectations, design patterns and clear boundaries around what could be generated safely.

That is the difference between using AI as a shortcut and preparing an organisation to use it well.

This programme was intended to move the needle in the near term while creating a more coherent path into the future.

The discovery work shaped committed and emerging initiatives including Experience Uplift, landing-page signposting, navigation aligned to user intent, clearer access to data and registers, a Data Resource Centre, CfD timeline improvements, scheme-driven notifications, content clarity and trust signals, and a more consistent set of UI foundations.

The CfD timeline and notification-wrapper concepts are especially relevant because they connect the strategic and interface layers.

They explore a practical question:

“How might we help scheme participants understand where they are, what matters now and where they need to act across a fragmented service ecosystem?“

This is also the kind of narrow AI-enabled opportunity that can be prototyped, tested and measured rather than assumed.

The Data Resource Centre creates a complementary opportunity. LCCC already publishes a significant amount of public data across dashboards, datasets, registers and APIs. The challenge is not simply to expose more information. It is to help different audiences understand what exists, find the right entry point and move between exploration, interpretation and action with less friction.