What is expected from a Service Designer in Beta

During the Beta, the focus is on reducing risk while refining and optimising the service to better meet the needs of users and stakeholders.

Beta focuses on the service moving from ideas and prototypes into a working, usable product. It builds on what was learned in Discovery and Alpha and prepares the service for real‑world use and eventual Live release.

There are two phases within beta:

• private beta, being a limited release to a sample group of real users to test the service in a controlled way
• public beta, being open to the public, often promoted more widely to get broader user feedback

Service design involvement

As a Service Designer, you might be involved in:

• taking the service design you’ve agreed on and working with the service team in testing it with a small, controlled group of users to understand how it works and remove any risks before live
• working collaboratively with the team to decide whether identified issues require further testing or can be safely released and measured, considering risk, delivery impact, user satisfaction, accessibility and inclusivity requirements, assisted digital needs, and cost
• ensuring solutions are inclusive and accessible to everyone, offering both digital and offline routes, and meeting all user needs identified through research
• ensuring that interaction design solutions meet the latest published WCAG standard to ‘AA’ standard
• contributing and sharing blueprints to the wider DDaT library
• observing user research and contributing to the analysis of key success metrics such as Google Analytics data and customer satisfaction (CSAT) scores
• maintaining a design history or log to document how the service evolves over time, capturing what was created, why decisions were made, and how changes responded to user and business needs
• working with other departments such as technical and procedural, comms, contact centre, print services and online teams to understand the capability and constraints of the ask as well as assessing needs of all parties for successful delivery of the service
• actively contributing reusable processes and operational best practice that can be adopted across BSA and shared across government

What outputs are expected from an Service Designer in Beta

Service Designer outputs should include the design artefacts appropriate to the phase and needs of the service, for example:

• to-be blueprints maps – illustrating proposed end‑to‑end experiences across channels showing actors, touchpoints, channels, and dependencies and opportunity areas – where change could have the biggest impact
• ecosystem or stakeholder maps – organisations, teams, suppliers, and relationships
• empathy mapping – to help the team move beyond what users do, to understand why they do it, grounding service design decisions in real user insight rather than assumptions
• policy and legislative constraints summary – what shapes or limits the service
• to-be focused user journey – identifying touch points, pain and gain points

---

Improve the playbook

If you spot anything factually incorrect with this page or have ideas for improvement, please share your suggestions.

Before you start, you will need a GitHub account. Github is an open forum where we collect feedback.