This three-parts article is about a new technique in design projects for citizen-centred government services: the ‘dialogue’. We will introduce dialogues to the service design community and share our lessons learned in using this technique. We also want to explore how dialogues create a shared understanding and commitment among designers and internal stakeholders.
[Reprint from Touchpoint Volume 5 no. 2, september 2013 ~ Designing citizen-centred public services]
Our article acknowledges the challenges many professionals in government services are facing and it details how the use of dialogues can be a successful response for design, technology and the client institution itself. Furthermore, we will explore how dialogues sit alongside other more familiar service design methods and tools, and how they are especially well-suited to the design of government services. To clarify our use of the term, we see ‘dialogues’ as a discrete set of interactions between a service provider and a service consumer, much in the way that ‘dialogue’ describes the conversational exchange specified in a screenplay or script. This is different to ‘dialog’, the user interface term.
[INSERT PIX]
Introducing dialogues: The UWV showcase
Through the government’s Uitvoeringsinstituut Werknemersverzekeringen (UWV) department, you can apply for unemployment benefits that provide financial support while you seek a new job in the Netherlands. The UWV is tasked with creating transparency in the labour market and bridging the gap between available jobs and jobseekers through (online) tools. Your unemployment money depends on using these tools properly. If you fail to demonstrate your jobseeking activity, the agency can curtail or revoke your right to the benefit. Reductions in staff, offices and budgets have led the UWV to move towards a service model that is increasingly digital. Citizens, however, have been vocal in their complaints about service quality.
Despite good intentions, the UWV can frustrate jobseekers who must depend on it in hard times. The transition of complex public services to digital channels and touchpoints has resulted in a confusing landscape of legacy portals. Furthermore, both jobseekers and job providers complain regularly about the UWV’s digital touchpoints having poor usability, usefulness and value. And, moreover, the users of its services – a cross-section of the entire Dutch population, whose interactions with the UWV are often triggered by unpleasant life events or circumstances – still expect the same level of service from governmental digital touchpoints as they’re getting elsewhere. These growing pains don’t just belong to the UWV: they are a typical challenge for most government agencies trying to redesign their services for digital infrastructures. Moving 20th-century bureaucracy to 21st-century infrastructure is a grand challenge. Over the last three years, we worked with various departments at the UWV to introduce service design as a way to design better online services.
And, although we are very positive about what service design brings about, we were also tested in our patience, perseverance and practical inventiveness to implement service design into the inner workings of the organization. In our experience, using dialogues as a technique for design, communication and decision-making made all the difference. And their value as a design tool – which we will now discuss – complements their value from a ‘business’ point of view as well: In a world of ever-increasing touchpoints, dialogue-based design delivers a consistent experience.
What are dialogues?
The origin of dialogues in service design is grounded in our design and development work in enterprise environments. We discovered that in order to orchestrate touchpoints in services, a specific layer of abstraction was necessary. Development teams in particular were already familiar with reusable patterns, templates and code snippets: dialogues share a certain level of abstraction with these elements. When breaking down events, we identified in the phases of citizen journeys, the most elementary units we found were dialogues. So we started to structure dialogues and put them into use.
[INSERT IMG Dialogue Profile]
“Dialogue profile”
[INSERT IMG Dialogue Diagram]
“Dialogue diagram”
The structure of dialogues
For the purpose of service design projects, dialogues have a structure, expressed in a diagram. The three recurring parts of a dialogue are its beginning (the necessary or helpful preconditions to be able to start and complete a dialogue), its flow (a sequence of actions and decisions made by participants, as the dialogue progresses) and its ending.
Within a dialogue, actions elicit reactions or responses from participants, which are called steps. Therefore, a dialogue is a logical sequence of steps taken, in this case, by a government service provider and a citizen. A dialogue has a profile that contains its identifier (a name phrased as a verb+noun pair, such as ‘Change Address’), the service phase it belongs to, and a description (formulated in natural language and part of the narrative structure of the service, such as ‘A person is moving to another house at a different postal address. Therefore, his/her address needs to be updated. The person submits the new postal address to the system.’).
In addition, dialogues have a diagram depicting the flow of actions and decisions made by participants. For communication and specification purposes, a dialogue diagram visualizes all steps, as well as user and system decisions, insofar as these decisions impact the perspective, experience, and behaviour of the user. Any government service can be broken down into a sequence of dialogues, logically structured into phases a citizen goes through. For example: ‘Orienting’, ‘Registering’, and ‘Using’.
Dialogues are therefore useful abstractions, used in understanding a service as being made of its component parts so that they may be better understood and designed. Initially, dialogues created during service design are just high level, serving the purpose of identification, description and orchestration. Over time, dialogues are further detailed, specified and enriched towards implementation. Like use cases in software engineering, dialogues have clear starting and ending points, and therefore have pre- and post-conditions. Pre-conditions outline requirements that must be met before the dialogue is started. For example, a newborn baby needs a name before a dialogue to register its birth can be initiated. Similarly, post-conditions describe the circumstances once the dialogue has been completed. For example, the situation of having received a registration confirmation.
The flow of a dialogue is the progression through actions and decision points by the participants. In designing with dialogues, actions are named, using a controlled vocabulary that improves consistency and communication among designers, developers and other stakeholders. In dialogues for person-to-system interactions, there are two kinds of actions: user actions and system actions. User actions are labeled with terms such as ‘Select’, ‘Enter’ or ‘Submit’. System actions are named with verbs like ‘Calculate’, ‘Delete’ or ‘Retrieve’. Each action in a dialogue is carried out by either the system or the user. More general actions that are not channel- or touchpoint-specific can belong to either participant, such as ‘Read’, ‘Write’ or ‘Wait’.
Decisions are an important part of dialogues. They are the outcome of rules applied at certain points within the dialogue. In the context of government services, identifying decision rules for the system comes from decisions made by the agency itself, whereas rules from citizens are derived from user research, insights and testing. Both for actions and decisions, their granularity is decided by a multidisciplinary design team through shared understanding and consensus. The combination of steps and decisions taken by the system and the citizen are their behaviors, and they make up the dialogue as a whole.
Dialogues, channels and touchpoints
How are dialogues connected to channels and touchpoints? Actually, they’re not: they are channel- and touchpoint-agnostic. They are, however, fundamental building blocks of the service.
[INSERT IMG Dialogue Channels]
“Dialogues can be supported on multiple channels”
In our process, we consider a channel as a medium of information, communication, and interaction. Channels, therefore, have unique characteristics, setting the design constraints and defining the design space of that channel. Dialogues are not directly connected to channels, but linked to them by means of the touchpoints in which they occur.
Examples of channels are print, a public website, a call centre and ‘face-to-face’. Designing dialogues for print implies making use of the medium’s portability, familiarity and availability. Designing dialogues for digital media uses characteristics such as connectivity, mobility and computation. Designing for face-to-face interactions harnesses their physicality, ambiance and accessibility.
In principle, one channel is not necessarily better than another. To determine which channel is the best in which to deliver dialogues, factors such as cost, feasibility and intended experience are analysed. Touchpoints emerge at the intersection of dialogues and channels. For us, a touchpoint is an embodiment of a dialogue being accessed through a specific channel. From the channels mentioned previously, examples of touchpoints are a paper form for requesting unemployment benefits, a native mobile app to submit an updated address or a service counter for checking in. Furthermore, a dialogue can only be completed on one touchpoint. Conversely, channels can facilitate one or more dialogues. For example, a service counter in a town hall can be used for multiple services, in the same way that a public website can be used for requesting a driver’s license or for making an appointment with a civil servant. Modelling dialogues as discrete units will make it easier to orchestrate touchpoints across channels, and sets the stage for consistent experiences across web, mobile and other touchpoints in the future.
Download reprint:
Touchpoint 5.2, sep. 2013 
1. Introducing dialogues
2. Using dialogues in service design
3. Benefits & challenges of dialogues
About the authors
Mark Fonds (a.k.a. @markafonds), a previous contributor to Touchpoint, has a background in design and psychology. Mark works as a service designer at Informaat where he is applying service design to help government agencies with their transition to a ‘digital by default’ government, improving service to its citizens.
Peter Bogaards (a.k.a. @BogieZero) has been an online content curator avant-la-lettre in various UX-related fields for almost two decades, choosing what he thinks is interesting, relevant or remarkable to share. Peter works as a curator, editor and coach at Informaat.
