Starting from someone else's model
This week I began work on what is called the 'registration' part of the NHS Secure Data Environment service. The first thing I inherited was a business process model, produced by a colleague, mapping the steps involved. The second thing I inherited was a confusion.
The word 'registration' suggests something familiar: a user signs up for a service. They provide their details, perhaps verify their identity, and gain access. This is not what 'registration' means here. The actual onboarding - the part where a user applies for and is granted permission to access NHS data - is handled by an entirely separate service, the Data Access Request Service (DARS). What is called 'registration' in the SDE context is something more like user role allocation, nominated user identification, and backend provisioning of cloud infrastructure. It is an administrative and technical process that happens after the user has already been approved elsewhere.
This is a naming problem, and naming problems in services are never just naming problems.
Bad services are nouns
Lou Downe's (2020) well-known heuristic - "good services are verbs, bad services are nouns" - applies here in a specific way. 'Registration' is a noun. It describes an organisational process, not a user goal. Nobody wakes up wanting to 'register'; they want to access data, or set up their research environment, or get their team connected to the platform. The name 'registration' tells you how the organisation has categorised this chunk of work internally. It tells you nothing about what the user is trying to accomplish or what value they receive.
Kate Tarling (2023) makes a related point in The Service Organization: "organizations don't see themselves in terms of services as their customers and users would think of them". She recommends writing service names "as if they were a verb" and warns that "an internal view will creep back into a list of service names over time if that is not carefully guarded against". The SDE 'registration' is a textbook case. At some point, a team needed a label for this part of the process, and the label they chose reflected the provider's view - what the system does (registers a user, provisions resources) - rather than the user's view of what they are trying to achieve.
This matters beyond naming. When a process is labelled from the provider's perspective, it tends to be designed from the provider's perspective too. The business process model I inherited described the steps in terms of system actions, backend triggers, and administrative approvals. It was accurate and thorough. What it didn't foreground was the user's experience of those steps - what they see, what they understand about what is happening, what they need to do and when, what they are waiting for and why.
Two ways of seeing the same process
This gets at a genuine tension between business process analysis and service design that I've been thinking about since starting this piece of work.
Business process modelling, as Embley and Thalheim (2012) describe it, is "the activity of capturing and representing all required information about an enterprise's business process". The perspective is organisational: what happens, in what order, who is responsible, what systems are involved. It is invaluable for understanding how things work internally, and the model my colleague produced gave me a map of the process that would have taken weeks to piece together otherwise.
Service design takes a different starting point. As Overkamp (2019) puts it, service designers "typically apply an outside-in perspective and design the service from the perspective of the service user". The question is not "what does the organisation do?" but "what does the user experience?" These are not the same question, and they do not produce the same representations.
Hewing (2013) has proposed merging the two approaches - combining business process modelling notation with the 'lines' from service blueprinting (line of visibility, line of interaction, line of internal interaction) to create what he calls Business Process Blueprinting. The idea is that you can retain the rigour and completeness of process modelling whilst overlaying the customer-facing perspective that service blueprinting provides. Whether or not you adopt their specific method, the underlying insight is sound: process models and service design representations are looking at the same reality from different vantage points, and you need both views to understand what is actually going on.
In practice, what this has meant for my work this week is starting from the process model and layering questions on top of it. At each step: what does the user see? What do they understand? What are they waiting for? Is the language the system uses the language the user would use? Where are the handoffs between DARS and SDE, and are they visible to the user or hidden behind system-to-system integrations?
The seam between services
The diagram above illustrates something important: the DARS application process and the SDE registration/provisioning process are treated as separate workflows with a handoff between them. From the organisation's perspective, these are two distinct services owned by different teams. From the user's perspective, they are trying to do one thing - get access to data - and the boundary between DARS and SDE is an organisational artefact, not a meaningful distinction in their journey.
Downe (2020) is direct about this: "Services in the internet age don't obey organisational boundaries. In a world where users hit Google looking for a service that meets their needs, it doesn't matter which organisation, department or team provides that service". The gap between DARS and SDE is precisely this kind of boundary - real to the organisation, invisible (or worse, confusing) to the user.
As I noted in the previous weeknote, the fact that these two services emerged from separate silos during the pandemic - DARS as a bottom-up data request management tool, the SDE as a top-down response to the Goldacre Review - explains why the boundary exists. It doesn't excuse the user having to navigate it. The design challenge going forward is working out how to make this seam less visible, or ideally invisible, to users - whilst operating within the organisational reality that these are, for now, separately governed and separately built systems.
What I'm taking forward
The business process model gave me the what. The service design questions I am now layering on top of it will, I hope, surface the why and the for whom. Next week I'll be modelling the data flows in more detail, trying to build a single source of truth for the logic across both services - work that, looks like it, will involve quite a lot of reverse engineering from prototypes and staging servers, because the documentation for much of this logic doesn't exist in any other form.
References
- Downe, L. (2020). Good Services: How to Design Services That Work. BIS Publishers.
- Embley, D. & Thalheim, B. (Eds.) (2012). Handbook of Conceptual Modeling: Theory, Practice, and Research Challenges. Springer.
- Hewing, M. (2013). Business Process Blueprinting. Springer.
- Morelli, N. (2020). Service Design Capabilities, Springer Nature
- Overkamp, T. (2019). How Service Ideas Are Implemented. Linköping University.
- Tarling, K. (2023). The Service Organization. Crown House Publishing.