This project is a scenario-based training for customer support staff at an IT company. The goal is to help staff develop an approach for having productive and satisfactory interactions with customers via email, particularly when there is a communication barrier in place.
Audience: New customer support staff and those who struggle with difficult customer interactions
Responsibilities: Instructional Design, eLearning Development, Graphic Design
Tools Used: Articulate Storyline, Figma, Affinity Designer, Mindmeister
Problem and Solution
The client expressed issues with the performance of their customer support staff, which has expanded rapidly in recent months. Many of the junior associates have struggled to resolve issues with the more difficult customers, which has led to an increase in poor reviews, prolonged resolution times, and larger workloads for senior associates. The client admits that this stems largely from a lack of formalized training, and thus reached out to discuss a solution.
I proposed a course to help staff develop a more structured approach for evaluating a situation, identifying needs, and responding appropriately. This would feature realistic customer interactions in which the learner must select the most suitable response out of several offered. The learner sees the outcomes of their choices, and is offered constructive feedback which can also be applied to real practice.
I consulted with a SME to identify specific weaknesses of the support team, and we agreed that a scenario-based training would ideal for addressing these weaknesses by simulating the customer support experience. I then designed a course by defining goals in an action map, storyboarding pathways toward various outcomes, setting a visual style and tone of voice, building and testing an interactive prototype, and then developing the end product.
I asked the SME to identify a training goal, and then list the tasks that the staff would need to do in order to make it happen. These were laid out as a map and then refined as observable actions, which we broke down further into specific examples. By getting this down, we were able to establish a basic blueprint to aid in setting up scenarios.
Using real customer emails for reference, I came up with five interaction scenarios. I wrote an ideal response for each one, along with two “wrong” ones, to give the learner three options to choose from. I also created a ‘trainer’ character named Vernon, who provides hints and feedback that can be accessed at the learner’s discretion to simulate the experience of consulting with an actual trainer.
I then added realistic customer replies that are triggered by each response option. In addition to indicating whether or not the selected response was satisfactory, these replies also produce emotional impact and further immerse the learner.
I used Affinity Designer to create vector graphics and Figma to lay out the general design. Because the training will allow for moderate freedom of choice, a key goal was to establish navigability without increasing complexity. To this end I placed a navigation bar at the bottom of the screen and used simple icons to represent most buttons.
I chose blue and orange as the primary colors, as their associated meanings are well-aligned with the theme of the training: blue to represent trust and loyalty, and orange for warmth and communication. After the initial iteration, I elicited feedback from other designers to identify areas for improvement. I made changes accordingly, which included reducing information density, and improving color contrast.
To ease the transition from design to development, I created a visual storyboard to specify events and interactions in the course. This was important due to the extensive use of pop-up message boxes and other triggered events planned for the course. By expressing everything in thorough detail, I was able to more readily identify missing elements and save a lot of time and trouble in the development phase.
I first built a prototype in Articulate Storyline with examples of key interactions, to facilitate a more efficient cycle for eliciting feedback and making changes.
To create slides, I designed the static graphic elements in Figma and then exported them to Storyline, while the interactive and variable elements were created directly in Storyline.
Some feedback given was that visual contrast in some areas could be stronger, and the presentation was too static. There were also a few typing errors, and calculations sometimes did not display accurately. I responded by adding bold strokes to message boxes, incorporating several brief animations to create a more dynamic feel, and correcting the typing and technical errors.
After making the changes, I finished the rest of the build as defined in the storyboards. To stay organized in Storyline, I split up the course as seven scenes: The introduction, the outcome, and one for each of the five scenarios. After completion, I published the course and tested it for errors by going through all possible pathways on both desktop and mobile devices.
Results & Takeaways
The training was rolled out with a group of recently-hired customer support associates, all within their fourth week of employment, who were asked to provide verbal feedback after the training. One associate noted that the approaches covered in the training aligned well with critique he received from his lead regarding his performance, while another mentioned that she found the checklist to be a useful tool and kept a printout at her workstation.
Of all participants, the overall average score (counting only the first time through) was 4.2 out of 5 possible stars, which is above the 4 needed to “pass” the training. As far as the effect on practice, the SME stated that she found that the participants on the whole were more confident in solving problems independently and less reliant on senior associates for support.
As I underestimated the time needed to create a scenario-based experience, for planning of similar courses I intend to plot out variables and triggers more explicitly during the storyboarding phase, in order to make implementation more streamlined and not the “I’ll handle it when I get there” approach that characterized much of my time spent on this project.