GOV.UK’s Service Manual sets out the roles a service team must have: product manager, service owner, delivery manager, user researcher, content designer, designer and developer, with business analysts, performance analysts, technical architects, DevOps engineers, quality assurers and technical writers added as services grow more complex (GOV.UK, 2023). Each role carries a distinct mandate: the product manager balances user needs against organisational priorities, the service owner holds decision-making authority end-to-end, and the user researcher supplies evidence about real behaviour. None of these mandates overlaps neatly with another, which is precisely the point.
The Government Digital and Data Profession Capability Framework shows how much wider this picture becomes: across architecture, data, IT operations, product and delivery, quality assurance, software development and user-centred design it lists 48 distinct roles (GOV.UK, 2026). The service designer sits inside just one of these families, depending on entirely different professions, policy, technology and operations to make a service real. The Service Designer standard reflects this directly: it lists other business areas and professions involved in designing services, including research, UX, technology, policy and delivery, as knowledge a service designer must hold, alongside working within wider multidisciplinary teams that may include marketing, finance, communications, logistics, project management and HR (Skills England, 2023).
Where does the service designer fit among all this? Writing from inside the Home Office’s digital team, Tarling describes service designers as pairing with policy makers, user researchers and data specialists depending on the size of the service, and as playing a boundary-spanning role: visualising problems so that policy colleagues, senior stakeholders and technical leads can understand and act on them together (Tarling, 2016). This is closer to translation than authorship. The service designer’s distinct contribution is often not a decision but a shared understanding that lets other professions decide well.
Brown’s concept of the T-shaped person, developed at the design consultancy IDEO, describes what this translation demands of individuals: deep expertise in one discipline, paired with enough understanding of adjacent professions to collaborate across them rather than simply hand work over the wall (Brown, 2009). Teams built from narrowly specialised, I-shaped individuals tend to defend their own function’s version of the problem; teams with enough T-shaped members can hold several professional perspectives in view at once.
This matters because interfaces between professions, not the professions themselves, are where services most often fail users. A policy intent can be sound, a piece of technology well built and a piece of content well-written, and the service can still feel broken if the handoff between the professions responsible was never designed. Responsibility for a user’s experience routinely crosses departmental lines that were never drawn with that journey in mind, and each crossing is a point where information, ownership or tone can be lost. For anyone sponsoring or reviewing service work, the practical shift is to treat the map of roles and professions as seriously as the map of the user journey itself, and every handoff between professions as a design decision in its own right.
Action Point
List every profession currently involved in shaping one service you know well, not just the people with a design job title. Then identify one point where responsibility passes between two of them. Is it clear who owns what happens at that handoff, and would a user notice if it went wrong?