Service Design is having its moment as businesses increasingly see the value of building innovative services that answer the needs of their customers. But behind the scenes, the tools of the trade are ready for a re-imagining.
To execute a Service Design project, multidisciplinary teams from business, design and engineering create a Service Blueprint to capture the relationships and high-level impacts between people, processes and systems. Then they go to work using Agile methods to project manage, collaborate, and bring a customer’s experience to life.
All sounds textbook perfect – what could be missing from this picture?
Missing: Context and Collaboration
The Service Blueprint is without match for getting everyone aligned on how the working parts come together to deliver the service. But when we use a Service Blueprint alone to support agile delivery, we notice a few gaps.
Service design tools simply aren’t optimised to manage the gritty technical and process complexities in the execution phase of an Agile project as they lack the functions to capture the level of detail that teams need to build and launch a new service. While Jira and its peers allow the team to work through discrete user stories, these stories often lack the holistic view that’s needed to keep everybody aligned towards the desired outcome. In addition, the relentless focus on the backlog inherent to Agile tends to push the Service Blueprint to the wayside, causing teams to lose sight of the project’s context and larger goals.
Yet, as teams delve into planning and execution, it’s important they stay connected to the bigger picture, including the hows and whys that underlie the new service they’re building. When people lose touch with this context, they are more prone to misinterpreting project requirements and wasting time.
The other missing link has to do with driving collaboration: building a complex service demands deep and continuous cross-disciplinary collaboration from idea to launch. The orchestration of new experiences requires contributions from all disciplines, and the service blueprint is a useful tool to enable that orchestration.
Yet, the reality is that people are scattered throughout the world and rarely in the same room at the same time. So how can Agile teams collaborate in a meaningful way through each phase of a Service Design project?
We believe the missing link between the Service Blueprint and Agile delivery can filled by rethinking the blueprint.
At Wipro Digital’s Dublin studio, we’re reimagining the Service Blueprint as the central artefact that can both keep context top-of-mind and drive continuous, real-time collaboration across teams. This is especially critical to complex digital transformation projects. Our approach to Service Blueprints is different in that it captures the technologies and systems enabling the new service, driving participation from everyone involved.
We start by making the Service Blueprint our focal point in a collaborative tapestry we call the Project Wall.
Created with an online whiteboarding tool called RealtimeBoard, this is a living ecosystem where we share everything we need to create the new service. We embed live Jira cards to add an Agile dimension to our shared workspace, allowing us to accurately plan and deliver the project.
Hosted online, the Project Wall now becomes a place where members located across the globe and in different disciplines share ideas, organize user stories, and link to supporting artefacts and resources. Within this framework, the Service Blueprint transforms from a high-level diagram into a complete map of the project including all the guts of the new service. It details user stories that the project will execute on, what the touchpoints look like, which data are needed, which APIs need to be built and so on. This level of detail will inspire insights and conversations that a high-level blueprint typically fails to generate.
When maintained throughout the project, the Project Wall provides the full context required by designers and engineers.
Whether project members are onsite or remote, their experience of the Project Wall is the same:
While the Project Wall doesn’t solve every challenge, we’ve seen some clear benefits by deploying it.
Easy communication for everyone
With the service blueprint at the heart of the Project Wall, it becomes easy and natural for people to discuss it and improve upon it. Regardless of people’s working style, or where they are in the world, everyone is on an equal footing to contribute because the Project Wall isn’t owned by a single office or team. This living ecosystem beckons participation and the diversity of perspectives inevitably leads to better solutions.
Transparency
Not only can everyone see the status of each user story and who is working on them, people can also freely raise issues and concerns. With full traceability of conversations and decisions, we foster an open and trusting environment for the team.
Efficient Collaboration
With a shared context to frame discussions, engineers and designers work tighter together. We know when and why a micro-service is needed, for example, and can trace it right back to the user need.
Accurate Planning and Effective Prioritisation
Instead of just working from a backlog, seeing user stories in their full context allows us to accurately plan and prioritise. It has also become a lot easier to identify gaps in our user stories before they become issues.
Closer Alignment
Team members are more engaged and aligned across locations.
Building the Project Wall
With the Service Blueprint at the centre of every Project Wall, we start by describing the main stages of the customer journey, identifying the touchpoints where a user interacts with the system. Next, our cross-functional team creates the blueprint together as follows:
1) People & Actions
First, we identify the people involved in the customer journey. We include both the customers and the employees who directly support their journey, providing detailed descriptions of all the actors’ interactions with the service at each touchpoint.
2) Touchpoints & Prototypes
As complex data relationships live under the hood of enterprise systems, user interactions need to be clearly defined and linked to the relevant underlying systems at the outset. So before we activate the Project Wall, we build a functional prototype that includes user-tested digital touchpoints, defining the service’s interactions, navigation, information architecture and functionalities. We map out each screen of the prototype to its corresponding point in the service journey; this mapping helps break down the project visually and shape the backlog.
3) System Functionality
On the system functionality layer, we describe the impact of each user action on its affected system. This layer also visualises the relationships and dependencies between the systems involved.
4) Data
Below the systems, we capture data requirements and API impacts as separate layers. On the data layer, we identify data sources and owners. Calling out these data requirements separately helps the team to figure out which API calls and microservices are required, and whether any new ones need to be created.
5) User Stories
While the journey and prototype drive the project backlog, we express functionality through epics and user stories for the front-end, back-end and service layers. As the project progresses, the team will replace text descriptions with user stories. Since we’ve integrated Jira into RealtimeBoard, stories are visually linked on the Project Wall and project members can create stories from Jira and add them to the Project Wall, or create them directly on the wall.
6) Issues or Challenges
We’ve designed the Project Wall to also capture issues which can be added to the backlog as a user story, spike or sub-task. Conversations are automatically logged, so it’s easy to go back and understand the rationale behind a decision.
7) Other Artefacts
As the project progresses, we continue to post relevant information on the Project Wall, such as edge cases and alternate flows which can be described as full vertical slices. We also add supporting artefacts such as process descriptions, architectural impacts, data field mapping, state diagrams and user support content.
Interesting in learning more? Get in touch.
Paul Harrison, UX Architect, Design Lead
UX Architect and Design Lead, part of a multi-disciplinary team of problem solvers across design, business strategy and innovation, who rethink and uncover opportunities, to help organisations develop meaningful solutions across all media types and touch-points.
Locations
