Transforming the Employee Feedback Experience
How Experience Design played a crucial role in machine learning development for the Slalom Build internship program
How are you doing? No, really?
If you’re like me, your reaction to this question can change depending on levels of stress, connection, or even the weather. For such a simple question, there’s a whole lot to unpack, or miss, behind that anticipated “fine.”
As part of the preparation for the 2022 Houston Slalom Build internship program, a group of engineers and designers were tasked with just that — finding a better way to capture employee well-being at Slalom. The discovery effort was led by two experience designers (including myself) and a solution owner (the project team lead). Our goal was to define a data analytics solution for the incoming interns to develop. We would then document that proposed solution to ensure smoother onboarding for the interns and promote alignment between their two pods.
This experience serves as a guide for how experience design (XD) supports technical discoveries and why our involvement is essential when building intelligent products for the future.
The State of Things
The current prompt for gathering weekly feedback asks employees to select a thumbs-up or thumbs-down of how their week went when filling out their timesheets. While there are also more in-depth feedback questionnaires that happen each year, our team wanted to create a solution that offered the best of both worlds, gathering meaningful insights at a more frequent cadence. To do this we needed to connect different data points and uncover trends over time.
Being one of two designers on a team made up of mostly engineers presented its own challenge. We knew it was our job to make sure the team was asking the right questions and not jumping to solutions. Our opening session was focused on architecture diagrams and discussion of building a chatbot — but was that even the right direction? How could the team know what to build when we didn’t understand what logic the chatbot needed to support? Or what feedback we wanted to gather?
How can we gather insights around employee satisfaction in a more meaningful and measurable way?
We still had a lot we needed to learn from varying groups. For our business stakeholder in Slalom IT, what did he hope to get out of the engagement, and what did success look like for him? For our users, employees at Slalom, we needed to understand what meaningful work and well-being meant to them. How did they prefer to give their feedback, and how often did they want to be asked? Only then could we build something that employees would actually use.
Figuring Out Our Why
We began by collecting feedback through survey questions sent out across Slalom Build. Given our tight timeline, we only had a week to gather responses and learn what made employees feel engaged.
The results varied quite a bit. Every employee had their own view of what made their work meaningful. They also had their own unique project schedules and cadences for when they were free to provide feedback. To uncover larger themes, we synthesized the responses. Employees referenced connection, quality of work, feeling challenged, work/life balance, and the ability to make an impact. With so many interpretations, the solution needed to be flexible and adjust based on how employees responded. Prompts needed to be presented in a way that could draw out these insights and follow up with more probing questions.
With this new list of requirements, a chatbot did sound like the right solution, but now we knew why. We also had direction on a key XD deliverable that would be needed later in our discovery — a process flow of the different logic-based conversation scenarios.
We shared our findings with the team through a Miro board, our main hub for capturing key decisions and artifacts. Throughout the discovery, the Miro board served as a helpful breadcrumb trail pointing back to our process and reminding us why we made certain decisions. In our presentation, our findings were validated by our business stakeholder. We learned there was another team working in parallel on how to best capture meaningful feedback. We had arrived at the same conclusions.
From these collaboration sessions, we arrived at our solution: a chatbot that would interact with employees and gather meaningful insights backed by a powerful machine learning model. These metrics would be visualized through a Power BI dashboard to help leadership understand what factors shaped employee engagement.
Creating a Source of Truth
To deliver on this solution, the team needed a shared understanding of how the systems and technology worked together to support the end experience. This understanding would guide each pod in its larger goals and provide direction on how they would work together. We created a service blueprint beginning with the key touchpoints of the user journey and mapping out a conversation between an employee and a chatbot. We then layered in our understanding of the supporting technology. Through workshop sessions, we brought the full team (product owner, solution owner, software engineers, data engineers, and design) together to provide input and let us know what needed to be adjusted.
Once the workshops were complete, we had a documented source of truth for what the team needed to build. For the discovery team, this service blueprint brought the what and the why into focus. And for the interns, it teed them up so they could focus on building (the how). For the software engineering (SE) pod, this meant understanding what APIs needed to be built. For the data engineering (DE) pod, this connected the dots on what type of information needed to be consumed and how it would be visualized for leadership.
Establishing a Conversation Flow
Next we needed to consider the types of questions users would be asked. We knew from our survey that employees’ preferences and cadences were varied. For the machine learning model to learn and adapt, we needed to maintain data quality. Questions needed to be formatted in a way that could be measured and compared over time.
Possible formats for the sample questions included:
- True/False
- Scale of 1–10
- Text input
- Multiple choice
- Emoji reaction
We then focused on how these question types would fit together in a natural way, considering language and tone for more conversational interactions. By mapping out sample user flows, we anticipated how the chatbot would ask follow-up questions (or not) based on employee responses. We made sure the interactions would be flexible and transparent about how data would be used, providing users with more details only when they wanted them.
By visualizing how these conversations were structured, we revealed invisible touchpoints from the user’s perspective. The chatbot would then adjust to the employee’s workflow, not the other way around. The more an employee interacted with the chatbot, the more it would learn their behavior and preferences for when and how often they wanted to be prompted.
With direction and discovery artifacts in hand, the interns were able to go beyond the expected MVP. Along with a Power BI dashboard and machine learning model, the intern team also developed a fully working proof of concept. This POC proved invaluable for building momentum and buy-in during team demos, demonstrating how multiple conversations would look and feel for employees in Slack.
Better, Faster, Stronger
Data analytics and machine learning can feel like heavy technical territory, but if you look past the surface, design considerations and user needs are everywhere. XD challenges teams on why we build products a certain way. It makes the difference between a meaningful interaction and just another task to be done.
With designers on board, the team achieved faster velocity and gained a stronger understanding of the problem space. By providing guidance on everything from goal alignment to conversational tone, XD proves that solving for the user means building better — and more meaningful — products for the future.
You can learn more about how Slalom Build approaches Intelligent Products here. For related articles, check out Human-Centered APIs.
