Introducing dialogues (Part 2/3)
A technique for delivering better government services
How do we use dialogues?
So how, where and when are dialogues used and what makes them powerful? Let’s look at our design process and see how they fit in and what role they play.
A first step in designing a service is to establish the ‘service essentials’ – the key properties to which the service should adhere. An example is ‘Be transparent and inclusive’. These essentials apply to all citizens. Furthermore, they are mandated at the European, national and departmental level and are formulated for specific projects.
Example of service essentials (Dutch)
Besides ones dictated from the outside, essentials can be sourced from research into citizens’ needs as well as (international) benchmarks and best practices. During design, service essentials function as heuristic principles and guidelines to decide which services, dialogues and touchpoints a government agency must deliver. Furthermore, service essentials support a shared understanding and commitment among all stakeholders. Service essentials are a tool to help designers to define the ‘irreducible core’ of a service.
The second step is to establish a deep understanding of users through research, and to capture these in citizen personas, a widely-used tool amongst service design practitioners. During research, these personas are used for encapsulating all relevant research data and for identifying all dialogues in the service. During design, they are used as a reference to identify which ones constitute the irreducible core of the service.
Personas and citizen journeys
The third step is to describe the service in a ‘service ecosystem.’ Based on work carried out with internal stakeholders and citizens, the multidisciplinary design team creates the citizen journeys and identifies their component phases.
A service ecosystem with the dialogue layer
This step allows designers to see which dialogues are supported by which touchpoints. An ecosystem depicts either state of a service: its current state or a future state. For the current state, dialogues are identifiable in the dialogue lane of the ecosystem, which shows their associations to phases and touchpoints.
With all the dialogues identified, the design team makes a distinction between primary and secondary dialogues. Some dialogues are indispensable and define the core of the service, whereas others enrich the service in various ways, but are not necessary per se. This identification activity is critical in defining the scope of the service, and – to use a motto of the UK government service design approach – “Government should only do what only government can do.” (GOV.uk)
Connecting service phases and dialogues
Designers can also identify dialogues that occur across multiple services. An example of such a dialogue is ‘Submit jobseeking activities’. The precise way in which it is instantiated depends on the specific service, the service phase, and the touchpoints involved. Designers and stakeholders use dialogues as externalised models of the services involved, building shared understanding, commitment and a common language. Stakeholders such as legislators, system architects and civil servants use dialogues to assess the impact on their domains, responsibilities and practices. With dialogues, stakeholders understand what must change in order to deliver the best services for citizens. Multidisciplinary teamwork is critical for successfully completing this step. This often means having at least one board-level manager who is a ‘digital believer’ and knowledgeable on citizen experience.
In the fifth step, the set of identified dialogues needs to be developed and shown at three levels of detail:
- All new dialogues in the phases of the ecosystem;
- All dialogues in a dialogue overview;
- Dialogue diagrams for individual dialogues.
A service ecosystem transforming to a future state
The first two visualisations are directed at top-level management so that they can understand the decisions to be made in implementing the service. The third visualisation is suited for system architects to understand the infrastructural requirements that they are going to be responsible for. Once all levels of detail are communicated throughout the organization, one or two rounds of thorough review and organization-wide agreement on the dialogues are necessary.
Once there is consensus on the core of the service and its dialogues, it must then be decided which touchpoints on which channels will be supported through dialogues. Once touchpoints and dialogues have been decided upon and specified, the prototyping process can start.
The channel and touchpoint relations
Continue reading part 3
Download reprint ~ Touchpoint 5.2, sep. 2013
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.
Public sector (7), Service design (42)
citizen experience, government