As a systems analyst intern at Wellington Management, a trillion dollar asset manager, I designed a Microsoft Teams' chatbot. The chatbot allows employees within the 1000 person company to submit positive and critical feedback about each other.
The project was three months long and resulted in the launching of the chatbot. My partner on the project was a developer, we were embedded on a team responsible for rolling out MS Teams throughout Wellington Management.
My responsibilities were to design branching and intuitive chat paths, communicate with developers, interview stakeholders and employees, and design and document the constantly changing user flows.
The chatbot was presented to Wellington Management's Chief Technology Officer and his senior technical team and was met with positive acclaim.
Below are mockups demonstrating the core interactions from the initial chat with the chatbot to the successful submission of feedback. We were responsible for the Give feedback and Help features with View feedback opening a link to an employee's Workday account.
Once an employee interacts with the chatbot it displays its core functions. Following the chatbot's prompts, the employees enter the name of the person they would like to submit feedback for.
If the name of an employee cannot be found the chatbot generates likely substitutes.
Once feedback is written the chatbot asks the employee to confirm that they would like to submit feedback. This confirmation prompt was incredibly important to our stakeholders and userbase.
Confirmation message letting the employee know that the feedback was submitted.
By typing help or pressing the help button an employee can be quickly taught how to use the chatbot. Important in a company where most employees haven't interacted with one before.
Through interviews with our primary stakeholder we learned about what Wellington Management wanted as an organization.
Broadely the chatbot needed to be:
And, in a interesting display of organizational dynamics:
The business objective of Wellington was to change how feedback was rolled out. Instead of employees providing feedback once a quarter the goal of our chatbot was to facilitate the giving of feedback on a more regular basis.
Under the quarterly system of feedback submission employees would not know in a timely manner when their efforts were commended or if they needed to adjust behaviors if performance was lacking.
We spoke with employees and demoed the chatbot throughout its lifecycle.This allowed us to easily identify employee concerns and design with a focus on mitigating if not erasing them.
Concerns mirrored those uncovered in earlier conversation albeit more with a focus on implementation:
With initial user, organizational, and technical requirements in hand I began whiteboarding to get a sense of how employees would interact with our chatbot.
With early whiteboarding complete I designed detailed flows that captured the minute actions employees would take. We had daily meetings with our project manager who gave us constant feedback.
We initially started with having the bot pull relevant links from Wellington's Workday account before moving to a more integrated solution down the line.
With an initial flow in place, I began researching the Microsoft Teams’ API to understand what kind of interfaces, commands, and user actions were possible with our chatbot.
After the initial command to access the chatbot much of the user interactions would take place on cards. When mapping out 1 to 1 how the experience would work I had to be conscious of what was possible within this confined sandbox.
There are three types of UI cards that MS Teams can display:
Besides typing, these cards answered the question what kind of UI would employees be able to interact with?
By using Microsoft’s Bot Framework we were able to get an early version of the chatbot up and running before it was deployed. This allowed the team to rapidly prototype and test the bot in a real environment.
The testing was done in Microsoft's bot framework and then printed out on paper to easily show and deliver to stakeholders. Names and personally identifying information have been hidden.
During this project testing was less a structured session and more so something that happened constantly.
An important session was a checkin the team had with the manager of the overall bot suite project. Four chatbots, including the feedback chatbot, were being designed for a singular bot suite.
Feedback from this session included:
Below are examples of the radically different tones and different points of interactions the chatbots had.
The chatbots were altered to speak in similar tones, display three buttons in lieu of being text based only, and include a help button.
We met with Wellington’s HR Director to demonstrate the chatbot and take into account her input. She strongly stressed the need for a confirmation message to appear after feedback was written but before it was submitted.
I initially chalked this up to slowing down the experience.
However, in a corporate environment, people don't want to ruin relationships with colleagues due to an ill-timed or poorly phrased piece of feedback.
And with that, the confirmation message was added.
We demoed the Feedback Chatbot along with the rest of the chatbot suite to Wellington Managements Chief Technology Officer and his senior technical staff. He and his team were impressed with the chatbot and the amount that we were able to get done in such a short amount of time.
As someone who has designed consumer products it was an enlightening experience to be able to design for employees who operated within a traditional enterprise corporation.