Fluent: Rethinking Invisible Labour
Embedded Files
Project Overview
Invisible labour exists in almost every workplace, yet it rarely gets acknowledged as real work. Tasks like onboarding new employees, mentoring coworkers, organizing team logistics, or emotionally supporting colleagues often happen quietly in the background. These responsibilities help teams function, but they are rarely reflected in promotions, evaluations, or formal recognition systems.
Duration: 4 Weeks
Team: Christina, Rutuja, Avani
Role: UX Designer & Researcher
Tools: Figma, AWS Lex, AWS Lambda, Flow Mapping, Conversational Scripting
Our team wanted to explore a difficult design question:
How might we make invisible labour more visible without turning care into another performance metric?
The Problem
Most workplace systems are optimized for productivity, output, and measurable performance.
They track deadlines, tasks, meetings, and deliverables but not the emotional and interpersonal work required to keep teams functioning. This creates an invisible imbalance.
Some employees consistently become the default helpers:
Onboarding new hires,
Mentoring teammates,
Resolving interpersonal tension,
Or coordinating emotional support behind the scenes.
While these contributions benefit the organization, they often go unrewarded and emotionally exhausting over time.
During our research, we realized this problem was not simply about workload distribution. It was deeply tied to emotional expectations, workplace culture, and social conditioning. Many people did not necessarily volunteer because they wanted to help they helped because they felt expected to. This emotional tension became the foundation of the project.
Understanding the Emotional System
Before sketching a single screen, we had to understand who we were designing for and not just their goals, but their emotional reality. We needed to feel the weight of the problem before we could design our way through it.
Design Method 1: Affective Personas
Traditional personas tell you what someone wants to accomplish. Affective personas tell you what someone is carrying. We chose this method because invisible labour isn't a usability problem, it's an emotional one. The friction isn't in the interface. It's in the relationships, the expectations, and the unspoken rules about who is supposed to help and who gets to say no.
Instead of building traditional productivity-focused personas, we used affective personas to better understand the emotional dynamics surrounding invisible labour. We wanted to design not only for functional needs, but also for emotional burden, interpersonal tension, and workplace expectations.
Jessica: The Woman Who Absorbs Invisible Labour
Jessica is the person this entire project was built around. She has worked at her company for several years, genuinely enjoyed helping people early in her career, and slowly realized that her helpfulness had become an expectation rather than a choice. She was passed over for a promotion despite taking on significantly more work than her peers and when a new hire joined the team, her manager assigned her the onboarding without asking, without acknowledging it as real work, and without checking what was already on her plate.
Her experience helped us frame a central challenge of the system: How do you encourage workplace care without creating emotional pressure?
➡️ This drove our decision to make declining emotionally neutral and to let her control exactly what her manager ever sees.
David: The Manager
David is not the villain. That was one of our most important early realizations. He is efficient, well-meaning, and genuinely wants to be a fair leader, he just has no mechanism for seeing what fairness actually requires. He offloaded onboarding to Jessica without realizing he had done so. He has no visibility into what that cost her, because the system around him has never asked him to look.
David represented another important perspective. This persona helped us recognize that workplace inequality is often reinforced unintentionally through systems that fail to surface emotional labour at all.
➡️ This led us to design the manager view so he only sees what Jessica actively chooses to share, never an aggregate or ranking.
Adam: The New Employee
Adam's persona mattered to our design because he represents the downstream effect of the whole system. When Jessica is burned out and resentful, Adam receives worse support. When invisible labour is distributed more fairly, Adam gets an onboarding buddy who actually has the emotional bandwidth to show up for him. He is not responsible for the problem but he is affected by the solution.
➡️ This informed the private acknowledgment flow that he can recognize Jessica's support quietly, without it becoming a public performance.
Together, these personas revealed a lose-lose-lose dynamic, because the invisible labour is forced onto Jessica, she is stressed, which means Adam receives inconsistent support, and David never becomes the fair leader he wants to be because nothing shows him what fairness actually requires. The work stays invisible not because no one cares, but because there is no mechanism for making it visible without also making it worse.
That is the gap Fluent was built to fill.
Mapping Risks & Ethical Tensions
Before designing any interfaces, we mapped the emotional and ethical risks of making invisible labour visible. We quickly realized that a poorly designed system could unintentionally gamify care, pressure employees into participation, encourage performative helping, or create workplace surveillance. Both early ideas had the same flaw: they made the labour visible for the organization's benefit, not the person doing it. Every feature in Fluent had to answer one question first: Is this for Jessica, or is this for the company?
This led us to several guiding questions:
How might we allow people to reject additional labour without penalty?
How might we avoid turning emotional labour into a scorecard?
How might we create visibility without emotional coercion?
How might we preserve privacy while still encouraging fairness?
These questions became the foundation for our design decisions.
Theoretical grounding
The project drew on three bodies of work that shaped specific design decisions. Don Norman's Emotional Design informed how we thought about visceral, behavioral, and reflective responses at each touchpoint. Ian Bogost's critique of gamification warned us away from points and badges, we needed helping to remain emotionally meaningful, not transactional. Jared Burraway's work on intentional friction challenged the UX default of removing all friction: in our system, deliberate friction before sharing contributions is what protects emotional autonomy. Kate Crawford's Atlas of AI pushed us to ask whose interests the data serves which is why contribution records belong to the employee, not the manager.
Introducing Fluent
We had a clear problem. We had three deeply understood personas. We had a set of ethical guardrails we couldn't cross. What we needed now was a system that could thread all of those needles simultaneously one that named invisible labour without surveilling it, redistributed it without coercing anyone, and gave people like Jessica a record of their work without turning that record into someone else's performance metric.
Fluent is a Slack-integrated system that surfaces invisible labour opportunities and redistributes them more equitably across teams.
Instead of assigning support work directly to one employee, Fluent introduces opportunities through the team channel and allows participation to remain voluntary. The system focuses on emotional safety, reflection, and employee-controlled visibility rather than metrics or rewards.
The name “Fluent” came from the idea that emotional labour is a workplace language that many people benefit from but few are taught to recognize.
Designing the First Experience
We had a working theory. Now we had to make it real and making it real meant making dozens of small decisions that each carried emotional weight. Every word in the interface, every button label, every moment of friction or flow was a design choice about how Jessica should feel.
We explored three perspectives within the system: Jessica volunteering for support work, Adam receiving help, and David managing team contributions. However, we chose to prioritize Jessica's emotional experience first, because her perspective carried the greatest emotional burden and the greatest ethical complexity. If the system didn't work for her, if it made her feel watched, pressured, or used then nothing else mattered.
Step 1: Introducing a Helping Opportunity
The experience begins inside a shared Slack channel. Instead of directly assigning onboarding work to Jessica, Fluent introduces the task as a collaborative opportunity visible to the team.
The wording was intentionally designed to feel inviting rather than demanding. We wanted the interaction to avoid recreating the same emotional pressure that already exists in many workplaces.
This became one of our earliest emotional design decisions that helping should feel voluntary, not socially mandatory.
Step 2: Viewing Task Details
Employees can open a task details panel to learn more about the invisible labour involved.
The interface explains:
The type of support required,
Why the work matters,
And the interpersonal skills connected to the task.
Rather than framing invisible labour as “extra work,” the experience reframes it as meaningful emotional and collaborative contribution.
This section also began introducing one of the project’s core ideas that soft skills are real skills.
Step 3: Confirming Participation
Once someone agrees to help, Fluent asks whether they would like their contribution to remain anonymous or associated with their name.
This moment became central to the project because it balanced:
visibility,
emotional autonomy,
and social pressure.
Public recognition can help employees feel appreciated, but it can also create pressure to constantly appear helpful. By allowing anonymous participation, we aimed to preserve emotional safety while still acknowledging support work.
Step 4: Making Contributions Visible
After someone volunteers, the team channel updates to show the task has been accepted.
Depending on privacy preferences, the system either:
displays the volunteer’s name,
or simply states that someone has stepped in.
This allowed support work to become visible without forcing every interaction into public recognition.
Step 5: The “My Contributions” Space
One of the most important parts of Fluent was the private reflection space.
Most workplace systems track performance through numbers, metrics, or rankings. We intentionally moved away from that model.
Instead, employees could privately document:
What support they provided,
How they contributed,
And what emotional or interpersonal skills were involved.
The interface intentionally included messaging like:
“No scores. No metrics. No comparisons.”
We wanted reflection to feel personal rather than evaluative.
Six Major Design Decisions
By this point we had a first prototype. But building something is different from knowing whether it works. Before we could test it with real people, we needed to be explicit with ourselves about the principles underneath each decision because those principles were what we'd defend when testing challenged them, and what we'd hold onto when the temptation to add a leaderboard or a badge crept back in.
Design decision 1: Private contributions by default
We found that public visibility immediately raised fears of social comparison and performative helping. So we made contributions visible only to the contributor unless deliberately shared, with anonymous volunteering as a first-class option.
Design decision 2: Private DMs for low-pressure follow-up
If no one volunteers in the group channel, a broadcast ask would recreate workplace pressure publicly. So Fluent reaches out privately, making it clear there's no record of the conversation and no consequence for declining.
Design decision 3: Friction before sharing We treated friction as a feature, not a bug.
Sharing a contribution with a manager requires two deliberate steps, slowing down impulsive or anxious sharing and giving the user control over what becomes visible.
Design decision 4: Private feedback instead of public ratings
Turning care work into a rating system felt ethically wrong. Feedback between Adam and Jessica stays one-directional and private, it can't be broadcast, compared, or used as a score.
Design decision 5: Opt-in participation with equitable redistribution
Entirely voluntary systems can reproduce the same inequalities if the same people keep volunteering. So Fluent redistributes tasks via private DM when no one steps in, targeting whoever has taken on least invisible labour, while keeping participation genuinely optional.
Design decision 6: Skill visibility as intrinsic motivation
Instead of badges or points, Fluent privately names the soft skills a task develops: mentoring, communication, conflict resolution. The goal was to make helping feel meaningful to the helper, not transactional.
Each of these decisions was a direct response to a risk we had mapped. None of them came easily.
Design Method 2: User Testing + Cognitive Walkthrough with Emotional Friction
We ran six sessions (two per team member) using a scenario-based cognitive walkthrough that explicitly prompted participants to narrate emotional responses not just usability reactions at every decision point. Sessions lasted 30–60 minutes each.
We synthesised findings using affinity mapping, grouping responses across three core design decision areas: how support opportunities are introduced, how contributions are displayed, and how the system communicates recognition and visibility.
The most valuable signal came not from what participants said they wanted, but from moments of hesitation, surprise, and discomfort the emotional friction that revealed where the design still inadvertently recreated the pressure it was trying to relieve.
Evaluating the Emotional Experience
To evaluate the system, we conducted cognitive walkthroughs focused specifically on emotional friction. Instead of only testing usability, we observed hesitation, emotional discomfort, pressure, guilt, and perceptions of visibility.
Participants consistently responded positively to anonymous participation, private reflections, and the anti-surveillance stance of the system.
However, testing also revealed tensions:
Some users were still worried that visibility could become performative,
Others feared that optional systems might still rely on the same people volunteering repeatedly,
And some questioned whether emotional labour could ever truly be measured fairly.
These conversations became some of the most valuable outcomes of the project because they reinforced the complexity of designing workplace emotional systems.
What user testing changed
Testing didn't just confirm our hypotheses, it revealed that the design was still inadvertently recreating workplace pressure in specific moments. Here's what we changed and why.
Design Consideraions
Reframing the support opportunity. The original Fluent message in the team channel read like a task notification. Participants said it felt like being assigned work, not invited to help. We rewrote it to centre on welcoming a new teammate, added a "Not this time" button at the same visual weight as "I can help," and embedded privacy reassurance inline.
Redesigning the decline experience. Even with neutral wording, participants felt subtle guilt declining.
The fix: make declining available directly in the group chat (not only via private DM), and rewrite the follow-up copy so that "No problem" is the actual message, not a consolation.
Reflection as ownership, not logging. Words like "log" and "record" triggered surveillance associations. We removed them entirely, introduced helper text so users knew what kinds of support to write about, and added quick-select skill chips for anyone who didn't want to write freeform.
Sharing with managers. Multiple participants described the sharing flow as feeling like self-promotion or boasting. The redesign reframes contributions as accumulating into a review repository that managers can access later, they aren't notified immediately when something is added. This small framing shift removed the performance anxiety from what is actually a protective, empowering feature.
Reflection
The hardest design problem in Fluent was not making something useful, it was resisting the pull of visible metrics. Every instinct in product design pushes toward dashboards, scores, and rankings as proof that something is working. This project forced me to sit with the discomfort of designing for intrinsic motivation: a system whose success you can't easily see, because the point is that it doesn't surveil.
I also learned that emotional safety is not a feature you add at the end. It has to be embedded at the copy level, the interaction level, and the system architecture level simultaneously. The moment a single word "log," "track," "assign" slips through, the entire emotional contract breaks. That level of precision in language was new territory for me, and it's something I'll carry into every project.
Final Reflection
I came into this project thinking about emotional design as something you apply on top of a functional system. I left it understanding that the emotional architecture is the system. Fluent won't solve structural gender inequity and we were honest about that. But naming invisible labour, building a record of it in the employee's interest rather than the company's, and giving someone like Jessica genuine agency over when and whether she puts in this time that is a concrete, meaningful first move.
The speculative framing that stayed with me most: What if emotional labour became a soft currency that exists beyond survival and institutional recognition? Not for promotion, not to be seen but just for the simple act of helping a fellow person? Designing toward that future, however partially, changed how I think about what technology is for.
Page updated
Google Sites
Report abuse