This document provides practical guidance for the service design practice.
It is split into five main sections, covering:
Selected content of this document is examinable as a part of the following syllabus:
Please refer to the respective syllabus document for details.
Key message
The purpose of the service design practice is to design products and services that are fit for purpose and use, and that can be delivered by the organization and its ecosystem. This includes planning and organizing people, partners and suppliers, information, communication, technology, and practices for new or changed products and services, and the interaction between the organization and its customers.
If products and services, or practices are not designed properly, they will not necessarily fulfil customer needs or facilitate value creation. If they evolve without proper architecture, interfaces or controls, they are less able to deliver the overall vision and needs of the organization and its internal and external customers.
Even when a product or service is well designed, delivering a solution that addresses the needs of both the organization and customer in a cost-effective and resilient way can be difficult. Therefore, it is important to consider iterative and incremental approaches to service design, which can ensure that products and services introduced to live operation can continually adapt in alignment with the evolving needs of the organization and its customers.
If service design is not formed, products and services can be quite expensive to run and prone to failure; this results in wasted resources and the product or service not being customer-centred or designed holistically. Without service design, it is extremely hard to achieve the needs and expectations of customers.
It is important that a holistic, results-driven approach to all aspects of service design is adopted, and that when changing or amending any of the individual elements of a service design, all other aspects are considered. Therefore, the coordination aspect of service design with the whole organization’s service value system (SVS) is essential.
Designing a new or changed product or service should not be done in isolation, but should consider the impact it will have on:
Considering these factors will not only ensure that the design addresses the functional elements of the service, but also that the management and operational requirements are regarded as a fundamental part of the design, not added as an afterthought.
Service design should also be used when the product or service is changing due to its retirement. Unless the retirement of a product/service is carefully planned, it could cause unexpected negative effects on customers or the organization.
Not every change to a product or service will require the same level of service design activity. Every change, no matter how small, will need some degree of design work, but the scale of the activity necessary to ensure success will vary greatly from one change type to another.
Organizations must define what level of design activity is required for each category of change and ensure that everyone within the organization is clear on this criteria.
Service design ensures that the products and services created:
With many pressures on the organization, there can be a temptation to ‘cut corners’ on the coordination of practices and relevant parties for service design activities, or to ignore them completely. This should be avoided, as integration and coordination are essential to the overall quality of the products and services that are delivered.
Design thinking
Design thinking is a practical and human-centred approach that accelerates innovation. It is used by product and service designers as well as organizations to solve complex problems and find practical, creative solutions that meet the needs of the organization and its customers.
Design thinking can be viewed as a complementary approach to Lean and Agile methodologies. It draws upon logic, imagination, intuition, and system thinking to explore possibilities and to create desired outcomes that benefit customers.
Design thinking includes an iterative approach to a variety of activities, such as:
Design thinking is best applied by multi-disciplinary teams; because it balances the perspectives of customers, technology, the organization, partners, and suppliers, it is highly integrative, aligns well with the organization’s SVS, and can be a key enabler of digital transformation.
| Customer and user experience |
| Customer experience (CX) is the sum of functional and emotional interactions with a service and service provider as perceived by a customer |
| User experience (UX) is the sum of functional and emotional interactions with a service and service provider as perceived by a user |
The CX and UX aspects of service design are essential to ensure products and services deliver the desired value for customers and the organization. CX design is focused on managing every aspect of the complete CX, including time, quality, cost, reliability, and effectiveness. UX looks specifically at the ease of use of the product or service and how the user interacts with it.
Service experience refers to the recognition that service consumers value a service that is based on a combination of the ‘technical’ output of the service and how it is perceived from a human perspective. This means that the service provider has to be increasingly aware of the consumers’ requirements, and the ‘resources’ that they have at their disposal to cocreate value. Service is not passively received: it also requires effort from the consumer. The service provider has to dynamically respond to the consumers’ behaviour and accommodate ‘exceptions’ as best as possible. The same applies to the consumer.
Lean user experience (Lean UX) design is a mindset, a culture, and a process that embraces Lean– Agile methods. It implements functionality in minimum viable increments and determines success by measuring results against an outcome hypothesis. Lean UX is incredibly useful when working on projects where Agile development methods are used. The core objective is to focus on obtaining feedback as early as possible so that it can be used to make quick decisions.
Typical questions for Lean UX might include the following:
There may be more than one answer to each question, which creates a greater number of assumptions than it might be practical to handle. The team will then prioritize these assumptions by the risks they represent to the organization and its customers.
Service Design Package
Service Design document(s) defining all aspects of an IT Service and its Requirements through each stage of its Lifecycle.
A service design package (SDP) may be produced for each new IT Service, and updated periodically, or during major changes and IT Service Retirement.
Service design packages are delivered through interaction between service management practices and the customer. The aim of the service design package is to ensure all aspects of the service have been considered and documented.
The concept of SDPs is not new to ITIL. However, the importance is significantly raised when viewed from the perspective of value streams. An SDP connects demand to value, regardless of delivery methodology or scope of service provision. Its purpose is to provide a clear statement of ‘what good looks like’ to designers and similar consumers; it must be used in conjunction with risk modelling of IT services as the best SDPs are flexible and adaptable depending on various criteria.
For an SDP to be effective, it should address all four dimensions of the service and be focused on customer and user experience. This is shown in figure 2.1.
Old focus
New focus
What percentage of availability is needed?
What is the organization trying to achieve?
For example, business objectives, what good looks like.
What is the target service restoration time?
Is this a fundamental business activity?
For example , one of the top business processes.
When can maintenance be done?
What elements of the business activity would stop if IT was not available?
For example, if the financial ledger was unavailable, no new contracts could be opened.
What data loss can be sustained?
What would be the impact to the organization if the data was leaked, corrupted, or unavailable?
The following questions should be considered in this case:
Service design orchestration
Service design orchestration ensures all resources required to achieve the outcome, including suppliers, information, technology, people, processes and operating models, are considered when designing and transitioning IT services.
Service design orchestration utilizes the principles of service integration and management to ensure the level of risk posed to the organization is managed appropriately by:
Service integration and management
Service integration and management is an approach to manage multiple suppliers of services (business services as well as information technology services) and integrating them to provide a single business-facing IT organization.
When selecting new service providers, the service design package for the service needs to form part of the requirements. Any discussions with third party suppliers need to ensure that those requirements are met, or at least mitigated. Where multiple service providers are engaged to provide the service, an operating model needs to be in place to determine roles and responsibilities, and how those providers will work together in pursuit of a seamless provision.
When there is a hybrid model, the complexity of the operating model will be increased (providers includes both in-house teams and third parties). This needs to be considered when documenting roles and responsibilities, escalations, and major incident handling.
Service design orchestration will also include logging and managing service design waivers and dispensations, where the performance of in-house and/or third parties does not meet the requirements stipulated by the service design matrix. In this case, mitigations need to be documented. It is recommended that in all cases, a date is agreed by which funding and other resources will be in place to remove the waiver/dispensation. Whilst it is possible to have an enduring waiver or dispensation, this is not advised. If a milestone date is not agreed, the risk will perpetuate and may increase risk exposure over time. The only time where a milestone date may be irrelevant, is where business operations accept the potential level of risk exposure but want to proceed in any case.
The role of orchestration is often supported by artefacts such as a continual improvement register. This could include items such as identified improvements, approved waivers, and dispensations.
How an organization uses this artefact will depend on what they want to manage. The existence of a service improvement register is highly recommended for any organization; this ensures that all parties are aware of what changes are in the pipeline in the pursuit of mitigating risk exposure.
An additional method is to track performance against a service design package. This is different to acceptance into service. Performance against service design packages requires the architects involved in the design and build of the IT service to verify the service through their analysis and decision-making tools. This approach can be used for single services, a group of services, or an end-to-end view.
A service design consultant would orchestrate the design of services either by ensuring the identified capabilities are being implemented appropriately and successfully, or by engaging directly with change initiatives across an organization. Typically, specialists involved in service introduction, or business analysts would promote the use of these capabilities through requirements gathering, test outcomes, and readiness monitoring.
Table 2.2 below shows some examples of considerations.
Operating model considerations
IT service design considerations
Roles and responsibilities in maintaining and managing the service
Scalability and the ability to respond to flexing demand
Availability, capacity, and performance needs
Incident handling and escalation
What management information is needed and what needs to be monitored?
Modelling risk involves both the service design practice and the risk management practice. There should be several elements involved in risk modelling:
Risk modelling can and should be done at different levels of service. The reasons are detailed below:
These three levels may legitimately have different risk profiles. An example is shown below in figure 2.2.
Figure 2.2 Example of risk profiles
Opening a new leasing contract is viewed as a critical business service line for the organization and is rated tier 1. Supporting the business service line are two customer journeys, both of which directly support the service line and are considered tier 1. When the IT Service layer is unravelled, whilst the leasing contract tool itself is part of the service, business continuity measures are in place to take information manually and input later. It is therefore rated a tier 2 service. However, without the CRM and ledger tools, the business would not be able to open a new leasing contract. They are tier 1.
Essentially, it is important to look for the critical path within a service and identify would stop the consumer from completing the task they wish to perform. Where IT services would stop those tasks, the consumer is directly affected; where they would add delay, the consumer is less affected (if at all).
It is important to identify that the service level management structure should mirror the levels of risk profiling; so profile service lines are risked, customer journeys in addition to IT services, service line and customer journey SLAs will also be needed.
The scope of the service design practice includes:
There are several activities and areas of responsibility that are not included in the service design practice, although they are still closely related to service design. These are listed in Table 2.3 along with references to the practices in which they can be found. It is important to remember that ITIL practices are merely tools to use in the context of value streams; they should be combined as necessary depending on the situation.
Activity
Practice guide
