Summary of the project

The client

RSA Ireland is a public service. According to their website, they are the Irish “national agency responsible for improving road safety and reducing deaths and injuries on Irish roads.” They are also the providers of drivers licenses for cars, trucks and motorcycles.

The problem

Excessive number of calls to the Customer Care Center regarding long waiting time to schedule a driver’s test led the client to ask for support to understand what was preventing the customers to complete the digital journey originally planned by their newly implemented digital strategy.

The design team’s objectives

Assess and propose solution to waiting list problem at the driver’s test scheduling through As-Is and Future-State Service Blueprinting.

Skills used

Design Research; Product Analysis; Service Design; Business Analysis.

The design’s team approach

We started by seeking to gain as much insight and clarity on what was the current status of the RSA’s service in its entirety. We wanted to have a good understanding of what was the client’s approach towards their digital journey and towards their clients. We also sought to identify incongruous systems and potential human errors in their processes.

Therefore, we opted for a research first approach, which prompted me, as the research lead in the team, to evaluate a large number of documents, systems and businesses operations that had been provided by the client previously.

The design process

The Research Plan

The design team received a large volume of documentation from RSA’s team, which included multiple cloud services containing various data formats, such as texts, workflows, business processes diagrams, User Personas, digital strategy and common complaints.

As the research leader, I outlined a research process in three overarching stages:

1. Assessing what had been produced up to that point so that I could create a Research Plan to fill any gaps or assumptions that had not been validated previously; this stage included many interviews with members of different teams involved in the service provision;
2. Analyzing what was already published and in operation within the scope of the Learner Driver’s journey as well as interviewing the users;
3. Compiling the research findings in a “palatable” way, which included a document with a framework on how to later implement and manage the Future State Service Blueprint.

Research: Stage 1 – “Let’s try to not reinvent the wheel, guys”

I started by creating a Mural board in which I essentially dumped all my doubts and findings as I dove into the client’s documentation. My goal, as suggested by the title, was to not end up doing redundant work or something inconsistent with the client’s needs and vision for their service.

In this process, I was able to answer some of my research questions about the business and the service, but not so much about the users. In this case, I identified two major users: RSA’s workers and the Learner Driver. I called the RSA’s workers “the inner user”. I did that because it is not possible to provide a great service without enabling the workers to do it, so I made sure to include them as an integral and fundamental part of the Service provision and quality.

In the documentation, I found an attempt to understand who the Learner Drivers were in the format of a big number of proto-personas and their respective User Journeys. That was in important effort from RSA’s team in their quest to provide better services.

However, due to the complexity of the Service and the multitude of motivations and demographics that people who seek a driver’s license have, the persona approach to building a User Journey quickly became difficult to manage and, as a result, nobody from the team seemed to want to use it.

Similarly, I was not able to fully understand what systems had to be mobilized internally in RSA to provide the full service for the Learner Driver. In further conversations with the RSA’s teams, I found out that some of the processes were new and improvised after the digital service went live.

On that note, it’s important to mention that the digital system had to go live before the expected because of the Covid-19 pandemic, which forced many public services worldwide to de-materialize their activities in order to continue operating.

Because of premature “go-live”, RSA’s teams also did not have the opportunity to learn thoroughly how the digital journey should work and, hence, was not able to provide proper guidance for the user in the FAQ section of the website.

As a result, the Customer Care Centre (CCC) witnessed a significant increase in their calls requesting support for multiple problems with the Learner Driver’s journey.

Those observations were insights that the RSA’s workers shared with me during their interviews, in which I mainly targeted to understand their different businesses processes and how the workers performed their tasks. The interviews also included questions regarding their perception on the service and what they thought was the actual root of the problems that RSA was facing regarding the Learner Driver’s journey.

So, the analysis of the client’s documentation provided a good contextualization to how the service was historically provided, as well as important insights on the status of their digital transformation and service de-materialization.

However, at the end of this process, it became apparent that the client had more than one problem and was struggling to define which one had priority in the service provision. In the same vein, the service itself was built of many “moving parts” that not always communicated properly, which created some of the blockages the Learner Driver faced in their journey.

Based on that, I was able to formulate some Research Questions to be answered in the next stages. The main ones were:

1. How does the Learner Driver know what documents they need to get a driver’s license?
2. What was the desired unique User Journey for all users and what is the real User Journey at the moment?
3. Why is the desired unique User Journey, if it exists, not working properly?
4. Are the workers enabled to perform the activities needed to provide the multiple services required for the Learner Driver to complete the journey towards a driver’s license?
5. Are there integration problems that could be preventing the systems to function properly? This includes physical integrations, legacy systems, cloud services, government data and privacy limitations, etc.

To answer that, we needed to experience ourselves the Learner Driver’s journey, as it was operating at that time. We also scheduled to interview real recent users, so that we could better understand what exactly they were trying to do when applying for a Driver’s License.

Research: Stage 2 – “Who are the users and what are they trying to do?”

In the second stage of the Research, we sought to answer the three first questions:

1. How does the Learner Driver know what documents they need to get a driver’s license?
2. What was the desired unique User Journey for all users and what is the real User Journey at the moment?
3. Why is the desired unique User Journey, if it exists, not working properly?

The first question was answered by the User Interviews we performed with recent Learner Drivers. Our questions encompassed aspects regarding finding information about the service, finding a driving instructor, how they knew their process was complete and where do they go for support.

From the interviews, we were able to assess that the majority of the Learner Drivers used the website very little, if at all. Most of the people were getting the information they needed either from friend or family or by calling the Customer Care Center. Both of those were very incongruent with the business goals for the digital strategy.

As a result of the User Interviews, which showed how diverse the Learner Drivers’ background were, the design team proposed the use of Jobs-to-be-done approach instead of personas, which significantly changed the direction RSA’s efforts in understanding their users.

In turn, Question 2 was answered when the design team realized that, because so many journeys had been created for different personas and because there was no unique Service Vision, the business could not have agreed on an unique journey for their users.

Question 3 was answered by analyzing important technical aspects of the service provision. To do so, me and my team started with some basic UX evaluations in their websites, such as heuristics, usability and accessibility analysis, which provided important insights and actionable activities (which we called “quick wins”) that could immediately improve the Learner Driver’s experience.

We also analyzed technical aspects of the User Interface design, such as if the coding was done on premise or if the client opted for a ready framework such as vue.js or similar. The purpose of such analysis was to determine there was any system integration problem, since it had been reported previously that the customers had been having problems with when paying for the service at the end of their journey.

At this stage, we had been able to amass a large amount of information and insight. To make it more “digestible” and also to start gearing the teams towards a unified Service Vision across the business, I created a sketch of an As-Is Service Blueprint.

Simultaneously, I created also the As-Is Service Blueprint and validated it with the client’s team through workshops that were conducted online.

One very important part of my work was to create devices that helped to align the different teams towards a unique service vision. Besides the the sketch of As-Is Service blueprint (Figure 2), I also created many other visual pieces to help bringing the Service Vision to life in a more tangible way for the client. One of those was a “One Stop Shop” mock-up that presented all the services involved in the process of obtaining a driver’s license in Ireland in a unified dashboard (Figure 3).

The last two questions were answered in the final stage of the Research, which was focused on the Contextual Inquiry.

Research: Stage 3 – Contextual Inquiry: Revealing the backend

As mentioned, all my work was oriented by the Research Questions. In the Contextual Inquiry, I wanted to answer questions related to the inside (or back-end) aspect of the Service:

4. Are the workers enabled to perform the activities needed to provide the multiple services required for the Learner Driver to complete the journey towards a driver’s license?
5. Are there integration problems that could be preventing the systems to function properly? This includes physical integrations, legacy systems, cloud services, government data and privacy limitations, etc.

In particular, I wanted to see how the client’s team dealt with the most common issues reported by the Learner Driver’s users.

In terms of operations, I planned a Contextual Inquiry in three parts:

• On-site data collection, which included shadowing the different teams, interviewing key stakeholders, registering different devices used to perform the activities, process mapping and bottlenecks identification;
• Office work to compile all data captured on the first visit and create the Future State Service Blueprint.
• Final workshop with all teams involved in the service provision.

By doing that, my goal was to find out what was the client’s teams consensus around how the service flopped and how it should look like. This comes from my business training, which showed me from experience that as designers, we have to focus on getting key stakeholders buy-in to ensure the longevity of any proposed design improvements.

In other words, we have to, in some ways, “sell” the idea and offer the practical aspects of maintaining a service vision as part of the day to day activities of the business. So a big portion of my work was to understand how the teams operated separately and how they worked together to create a service so that later I could create a document that acted as a guide for the service maintenance.

After the data collection, we moved on to the office work part of the Service-Blueprinting, which is essentially drawing a Service Blueprint with all the information gathered until that point.

I also created multiple Research Decks that compiled the research findings divided by business unit, which included “quick wins” and improvements that required medium and long term planning.

The final document I developed was a guide on how to deploy and maintain the Service Blueprint in real life, which we called the “Service Blueprint Playbook”. This included creating two versions: one in Mural and one in an Excel spreadsheet. I did that to align the Design with the tools the client was good at using.

The Service Blueprint Playbook was then presented to multiple teams in a workshop in person at the client’s site. In this workshop, the client had the opportunity to add more of their insights to the final version of the document (Figure 6).