Fluent
A workplace tool for the work no one tracks but everyone depends on
Objective
Help employees name their invisible labour, say no to these requests without consequence, and ensure non-promotable work is shared fairly.
my Role
Product Strategist
User Researcher
UX Systems Designer
Tools
Figma
Figjam
prototype and materials
Team
Me (Design)
Avani Chandorkar (Design)
Rutuja Nagulpelli (Design)
Duration
3 weeks
context
Invisible labour (i.e. non-promotable work) disproportionately affects women
Research from the Harvard Kennedy School revealed that women log more than 200 additional hours per year on non-promotional work than male counterparts (The Hidden Costs of “Helping”: A Conversation with Lise Vesterlund, 2026). Even though this work includes many relational, organizational, and emotional tasks that benefit the overall team, it's rarely recognized.
Why this matters
For the individual: Higher burnout rates, slower career progression, and an erosion of morale (Zabbo, 2026).
For the business: An organizational loss of $4,000–$21,000 per employee per year (CUNY Graduate School of Public Health and Health Policy, 2025).
Who we designed for
The employee (yes, who is often a woman) who wants the ability to say no to this invisible labour, and who desires recognition when they say yes.
Design Challenge
How might we ensure invisible workplace labour is shared fairly, instead of falling disproportionately on women?
The Solution
Fluent: A speculative Slack plugin that records and redistributes invisible labour
Even though invisible labour is a problem, making it visible creates new risks. This is why designing for emotional safety sometimes meant creating flows with more friction (Burraway, 2023). To build something economically viable and emotionally sustainable, we aimed to appeal to people's intrinsic motivation to help, rather than encouraging participation through gamified reward systems.
I led the formative research, core product strategy, and systemic UX logic, while serving as project manager. Avani and I collaborated closely on the interaction flows, with Avani executing the hi-fi UI prototype while I provided detailed UX feedback and structural iterations based on our user testing.
Opt-in flows to participate, with public channels and DMs to encourage, not mandate, participation
Copywriting focuses on the skill developed (i.e. what's in it for the helper) with an emphasis on relational friendliness.
Participation is always opt-in, with no managerial visibility as to who is declining the task.
Private redistribution of labour to target those who have taken on the least invisible labour.
Public or anonymous attribution on a volunteered task in the public group chat
Gives the choice of visibility to encourage a low-social-pressure way to help out without broadcasting to everyone.
People who want visibility can choose to attach their name, signalling both their contributions and their current bandwidth.
A contribution tracking feature that serves the employee, not the manager
Records are private by default, so contributions don't feel like automatic performance tracking.
Contributions are authored by the helper themselves, not pre-determined by the person being helped, nor strictly by the system.
impact
All 6 user testers said they would use Fluent at work
User testing helped us understand the emotional impact of our design decisions, and how difficult it can be to make a tool that recognizes labour without making it into a social performance. More importantly, it confirmed that a tool to surface and redistribute invisible labour is genuinely needed.
"I would really appreciate a tool like this, especially as a woman.
[Women are] often told to do these less desirable tasks that aren't revenue-generating, and aren't tracked regularly. [But] women are [also] less likely to vocalize contributions themselves.
So this is really helpful." - User feedback
affective personas
Starting by discovering power dynamics in existing workplace relationships
Before we could design any solution, we needed to understand the full relational system in which invisible labour operates. If we could understand why emotional work gets assigned, not just that it does, we could design something everyone in the system would actually want to opt into.
Affective personas gave us that fuller picture by going beyond typical personas to include emotional triggers and needs, helping us map the power dynamics among the main characters affected by an invisible labour dynamic.
How do all of these characters relate to the employee's invisible labour experience?
Jessica wants to help, but resents being taken for granted
David wants to be fair, but takes shortcuts for efficiency
Adam needs help, but doesn't have the confidence to ask
Naming the labour, distributing it fairly, and giving people the genuine choice to participate gives all three a reason to engage.
design principles
Design choices that protect the employee absorbing invisible work
While each affective persona plays a role in the invisible labour dynamic, we scoped down to prioritize the experience of the employee absorbing the work (Jessica), since our core challenge was designing something that gave her genuine agency and emotional safety.
Key design decisions
Privacy and choice as default
Whenever the user faces a choice, both the mechanism and the copywriting make it clear that the manager has no visibility over their actions, reducing social pressure to say yes.
Anti-gamification, pro-reflection
Soft skills are best developed and later remembered, when records of them are not generic. Manual thought entry, without points or streaks, encourages honest self-reflection rather than gaming the system (Bogost, 2015).
Friction before visibility
High-risk actions, like saying yes to a volunteering task or sharing a private note publicly, have an added layer of friction. Contrary to common UX recommendations, adding friction here aims to prevent impulsive decisions and promote more thoughtful engagement (Burraway, 2023).
cognitive walkthrough testing
Testing for emotional friction, not usability
A cognitive walkthrough with a focus on emotional responses is a usability test, but with questions centred on how the interaction feels rather than whether it functions correctly. We tested with 6 users (5 women, 1 man) who have a history of unwillingly performing invisible labour at work.
Finding 1: Users overestimated the burden of tasks
When introduced to the volunteering flow, all 6 users said they would decline because they didn't have bandwidth. This likely reflected biases from previous experiences where these previously unstructured tasks went unrewarded, which meant the perceived effort of participating had to be reduced.
Reframing task details
Finding 2: Users wanted more control over how contributions are recorded and shared
The contributions flow was one of the most useful features for our user testers, because it provides a record of what they've done. Since it's integrated directly into a primary work application, they feel that they'd be more likely to be consistent at using it.
Recording, modifying, and exporting contributions
I caught that over 50% of users pointed out that contributions don't always start from the group chat. When help happens over DM or in person, they still wanted a way to record and own that contribution for their own records. Exporting the data would also be helpful so they can bring this record throughout different jobs.
Controlling how and when managers see your contributions
Users wanted to share contributions with managers but worried about appearing boastful or pinging them too frequently. So I suggested that contributions be added silently to a review document rather than triggering individual notifications.
additional contraints
The problem with privacy: Data can always be misused
The only way this idea works is if Fluent can genuinely keep data private, meaning managers have no record of who declined, and no one can use contribution data to make assumptions about employees. Theoretically this is possible if Fluent operates as a truly neutral third party, outside the company's own infrastructure.
But the reality is, if data is collected, it can be misused. Anyone can hack a database, or use points of data to tell a different story. Many parts of this process could end up working against the very users it's supposed to protect.
reflection
What I learned: Designing for invisible labour is more than designing for function
Fluent obviously won't solve workplace gender inequality on its own, but naming this labour, tracking it, and giving employees ownership over it is the first step. Yet, even visibility creates problems. One user said:
"I'd share all my contributions if I knew my other coworkers were sharing." - User feedback
The issue: If coworkers could see what others are sharing, it would create competition, resentment toward consistent contributors, and discourage the people who are already most self-conscious about workplace politics.
To make the whole system work, you can't just design for features — you have to consider how people might use it, abuse it, and what environments you're building for. It's less like a consumer app and more like an HR policy, where power dynamics and livelihood are always at stake.
what's next
What would I do next if I had more time?
Test with the employees who typically don't volunteer or perform emotional labour
Fluent was tested with the users who most often do the work. But to address whether the solution can intrinsically motivate someone to volunteer for invisible labour, I would also need to test with people who don't already have the habit of doing so.
Experiment with a different platform/mechanism
I wonder whether Fluent being attached to a work app like Slack causes users to perceive invisible work as just another tracked metric. Would moving this to a separate platform, with different visuals and no prior association with workplace productivity tools, change how people relate to it?