Roles and responsibilities

I’m off next week for some rest and relaxation. I’m going to miss a session where the Personalised prevention services leadership are talking about their roles and responsibilities. Because I’m going to miss it I’ve summarised my role and my needs for the team.

Current role

Service design lead – not attached to leadership team or any of the delivery teams.

How I work

Working style, I like:

  • to work collaboratively – with people and across teams
  • time to process and plan (half day to few days depending on complexity)
  • detailed, crafted work
  • to think visually
  • move between big picture and detail
  • shaping our strategy and how we communicate it

My working principles are, to:

  • help us all use and follow design and accessibility standards
  • prototype in code and anything that supports quick iterative development
  • work ethically
  • deliver value early

My role involves:

  • strategic coordination across prevention services and the NHS
  • mapping to show how systems and services connect
  • visualising to help support shared understanding
  • working closely with product, research, and BA cluster leads
  • shared ownership of UCD community with research cluster lead
  • leading strategy development (with product and delivery) with input from all roles
  • ensuring the right conditions and environment for effective design work across our teams (processes, tools, support)

What I need from SLT

  • senior leadership priorities for mid to long‑term
  • clear role definitions for all team members
  • clear planning and coordination processes (especially for cross‑portfolio work)
  • clear expectations and regular feedback loops
  • authority to make design‑direction decisions
  • ongoing opportunities to shape strategy and service design direction

Has it got legs?

a pile of stickers with the the words ‘has it got legs?’, the words have legs

In this early phase of work for Personalised prevention services, our focus is on behaviour change. It’s not possible to test behaviour change without real world users. So we’re planning a number of pilots.

As part of our strategy, Irina Pencheva and I wrote a some definitions to help make it easier for teams and stakeholders to use the same language. We were using ’pilot’ and ‘MVP’ interchangeably in planning sessions, which meant we were making different assumptions about timescales, standards, and what success looked like.

Our definitions:

Prototype

Tools for exploring and testing design concepts before committing to building anything.

Characteristics:

  • use fake data and simulated interactions
  • test assumptions about user needs and design approaches
  • range from quick sketches to coded experiences
  • help teams learn and communicate ideas

Proof of concept

Demonstrates that a technical approach is feasible before scaled development. Reduces technical risk by testing specific technology questions.

Characteristics:

  • focuses on technical feasibility, not user experience
  • has minimal or no user interface
  • uses real or fake data depending on what needs testing
  • built for learning, not scaling – no production assurance

Pilot

Working services tested with a limited group of real users for a defined period.

Characteristics:

  • not built to become scaled services
  • users can complete the full service independently without support or observation
  • limited to invited participants, not public
  • built-in evaluation with clear success and failure criteria
  • set timeframe with decision point at the end

Minimum viable product (MVP)

The simplest possible service that meets core user needs for a specific user group.

MVPs can handle real NHS data and integrate with NHS systems. Unlike pilots, MVPs must meet full NHS standards and are accessed through established channels like the NHS app.

Characteristics:

  • built for quick release and iteration
  • meets core user needs for one user group, not all users
  • meets accessibility, clinical and information governance standards
  • designed with scale in mind

Experiment

Experiments happen throughout a service’s life. They can be small tests of new features or large-scale pilots. Both nudging and pilots are types of experiments.

Characteristics:

  • set timeframe with a decision point
  • built-in evaluation methodology with clear success and failure criteria
  • documented results that scale to the wider service if successful

Nudges

Techniques that guide people toward healthier decisions without limiting their freedom of choice.

Characteristics:

  • encourages behaviour but does not mandate
  • helps make the healthy choice easier to do at the right time
  • based on real data about how users behave
  • improves health outcomes or service use in a positive way