The handover is the enemy of holistic digital service design
Check before reading: in this post we are writing about an organization where design is already a part of normal digital service development. We are writing for a context where organizations are already investing in customer experience by utilizing service design professionals, and where software development teams include UX designers as a matter of fact. We welcome you to read on even if this is not the case where you currently work, but keep in mind that the solutions we discuss might not currently be relevant for you.
The horror story
Pretty much everyone working in digital service development has a horror story about a handover between people responsible for service design, concepting or similar need-finding activity, and the people responsible for creating and delivering the technical artefacts that make up the eventual digital service. We at Nitor definitely have our share of bad experiences from both sides, but we’ve recently started thinking about the problem more systematically: Is there a possibility that everyone involved in these horror stories is actually competent even though the end result is worse to use and costs more than it should?
Let’s break the horror story into three steps that usually follow each other. First, a client hires internal or external service designers to interact with current and potential users to come up with an entirely new service or a way of improving the current offering. The result of the service designers’ work is a concept which is often documented in presentations and design artefacts. The client takes the design documentation and approves the service designers’ work as completed.
In the second step, the client takes the design documentation and creates a separate specification for delivering the digital touchpoints such as websites, apps and related systems. The specification is usually produced even if the development is internal, since a “business organization” will often see themselves as being the ones who order work from a separate IT organization that does as they are told.
Third, the development team delivers the touchpoints described by the specifications, interacting with the client and the users within the constraints of their assignment. By this time, the development team almost never has access to the original service designers, the concept they created, or the full documentation delivered to the client.
So, what are the problems in this set-up that we see repeated across industries, clients and teams?
Service designers feel that the delivery does not provide the value potential of their concept, blaming the technical implementation for sub-par delivery. As a result, service designers distrust developers, focus on honing their own craft, and de-value service implentation compared to great research or inventive design.
Development team, consisting of UX design and software development, feels that the specifications they receive from the client don’t make sense and can’t be implemented without redesigning the concept, for which there usually isn’t time or budget. The development team blames the service designers for not being interested in getting services to the users, and the client for not knowing what they really want. As a result, the development team distrust both service designers and clients, and focus on involving users in the touchpoint delivery and creating the specific features asked for in the specifications.
Users (alternatively also customers/citizens/purchasers/etc.) don’t see or care how a digital service was produced — they just feel that the service is bad or irrelevant. As a result, the users think that the client organization isn’t interested in customer experience and doesn’t invest in good service.
Client, as in the party that holds the business need for the service and makes the decision to produce it, feels they aren’t getting what they ordered despite investing in digital service design and delivery. Not understanding what causes the problem, the client concludes that service design, Agile, Lean, user-centered design or any other current paradigm simply doesn’t work, and tries to get more control with more detaield specifications and contracts.
So, how is it possible for everyone to be good at what they do while the end result still fails to impress? Is it possible that the set-up itself is responsible for some of the failures in creating great digital services?
Root causes of service design handover failure
1. Purchasing and budgeting models
The first and foremost obstacle to an effective handover is that service design is separated from touchpoint delivery by splitting them into different projects, often done by completely different agencies that never get to collaborate, yet alone iterate on the concept together. The reason is usually that the client hires an internal or external design agency to come up with one or more concept within a fixed timeframe and budget, and then makes decisions about executing on the concepts in a budgeting committee before any implementation can be discussed. By the time a decision is made to implement the concept, the service designers are long gone, working on other concepts.
Another barrier for bringing service design and touchpoint delivery closer together is that the budgeting practices are often very different for service design and touchpoint delivery. Service design projects are budgeted by project and organized into deadlines for presenting the final design documentation to the client. In contrast, touchpoint delivery starts from a given specification that is either used to ask for proposals from agencies or handed as-is to internal development teams.
2. Organizational boundaries
The most pressing reason we find ourselves in assignments that are highly dependent on previous work we don’t have access to is that the design and delivery work is owned and ordered by different parts of the client organization. In many places, we see a “business organization” owning all concept-level work and completing concepting work with agencies without any connection to the people responsible for touchpoint delivery. Often these business organizations then turn around and order an IT organization to implement the concept, leaving the IT organization to scramble internal and external development teams to deliver on the specification given to them by the business organization.
3. Disciplinary boundaries
The reason we see organizational boundaries — or as they are derogatively called, silos — is that people of all professions naturally divide themselves into groups by discipline out of convenience and synergy. Business development, product management, designers and software developers all have distinct professional identities, practices, expectations and vocabulary that make it natural to form organizational units along those lines as soon as the organization has grown large enough to accommodate it. Just go look at startups that have reached ten employees: we bet you’ll see an organization forming along disciplinary lines such as sales, customer support, R&D, etc.
4. Plan/do dichotomy
Ultimately, despite our aspirations to be agile, the IT sector is still entrenched in the thinking that one set of people first decides what to do, after which another group then does the thing. The dichotomy has many names — plan/do, analyze/execute, design/implement, waterfall, traditional project — but the result is that interactions between people involved in service design and touchpoint delivery is minimal, and when some occurs, it is done through the roles of people who give out instructions and people who follow them. Needless to say this is not a good way to think about work if you want to iterate quickly and maximize learning while implementing a digital service.
Toward a continuous and holistic digital service design cycle
Based on the four perspectives, we see that we can’t really fix the problems with handovers — it’s the handovers that are the problem. They are not in the scope of service design or delivery projects, they are not budgeted, and no party is taking responsibility for them, especially from the client side. If you want to get rid of problematic handovers, you can start with a few simple modifications to your ways of working:
- Have at least some overlap between service design and implementation, where people from both are working on the service at the same time.
- Talk about one team that exists from early research all the way to maintenance, even if people change over time.
- Establish a shared goal of creating the best possible service for the users.
- Make sure you have transparent documentation and ways of working across people of different backgrounds.
The way we are currently tackling service design handovers is by organizing digital service development into the Digital Service Design Cycle (DSDC) which can have members from as many organizations as necessary. In DSDC, we bring all the relevant professions into one team without organizational boundaries that works in a continuous and efficient process from research to maintenance without distinctions between planners and doers. Even though people on the team might change throughout the service design lifecycle, e.g. focusing on more on concepting and architecture in the beginning, there are no hard handovers from one discipline to another, and new members are brought into the team to help the team move forward together. This enables faster cross-disciplinary learning, helping both the people and the service improve faster.
The four activities of the DSDC — plan, build, test and learn — naturally lead into each other in a continuous loop as the concept is defined, implemented and tested one part at a time in the order that helps the team learn as much as possible as soon as possible. In practice, a team following the cycle can look very different in different phases of developing a digital service: in the early phases the team will mostly build and test different types of user flows and prototypes to figure out the overall needs of the users, while in the later parts the need-finding will give way for implementing the service into production piece by piece while still adjusting the concept as new insights are gained. The key insight of the DSDC is that digital service design is never done: the focus of the work only shifts from figuring out the concept to iterating the final touchpoints without stopping either of them.
Moving from a disciplinary way of working based on handovers to a holistic digital service design cycle is not easy for anyone, but it resolves many of the problems people participating in digital service development are currently facing. Service designers get to see the services they design reach the hands of real users and gain insights to their own designs throughout the implementation process. The development team understands the thinking behind the concept they are implementing and can contribute to the concept with their own special expertise. Users get to enjoy more thought-out and consistently delivered digital services, and the client will not pay for work that will not be fully utilized in the delivery of the touchpoints.
Getting rid of handovers will require real changes to the way you think, purchase and organize projects, but the end result is a very tangible improvement in both user experience and employee experience.
