Introduction
A typical employee spends - on average - six hours a week per week in scheduled meetings. Unfortunately, meeting participants do not always participate optimally, or equally. Frequency of verbal contribution can not only affect who gets heard, but who gets credit - and eventually, who gets rewarded or punished.
Considering the fact that a 2017 study by Office Team found that feeling “unappreciated” was a top reason for employee exits, how might we promote a more inclusive meeting room environment that encourages more equitable speaking time, preserves anonymity, enables supervisors, and empowers team members to express themselves?
We believe Eclipse can help in this regard.
Notice
Please note that this is the Eclipse Shortform, and is intended to be an overview of the Eclipse project. If at any time you’d like to explore the longer, in-depth Eclipse process and story, please visit the Eclipse Longform, where each component is unpacked more extensively.
What is Eclipse?
Eclipse is a mobile application/chat plugin that tracks people’s verbal contributions in terms of time spoken during meetings.
We envision Eclipse being used anywhere people participate in meetings, provided there is a smartphone or other listening device present.
How Eclipse Works
Supervisors assign team members to their team.
Users attach their voice to their handle in the system.
Once in a meeting, the team leader triggers the Eclipse listen function.
Eclipse then listens to the meeting until told to stop, and forgets what is said.
Contribution levels are represented using visual language, ignoring language barriers.
Why Eclipse Is Important
Consider the following scenario as documented in a study published by the Harvard Business Review: a woman named Cheryl is in a meeting. Over the course of the meeting, Cheryl raises the most ideas, which are then enthusiastically supported by a colleague named Phil.
Phil often iterates on Cheryl’s ideas and expands on them - something that Cheryl will later report as making her feel supported.
Yet later, when asked who had generated the most ideas, attendees of the meeting will incorrectly attribute Cheryl’s ideas to Phil, despite them not originating with him. This is because memory is fallible. We tend to attribute ideas to people who say them last, or talk about them most.
This, coupled with the fact that men tend to dominate 75% of conversations in a conference setting, indicate a troubling reality: quantity can outweigh quality in terms of how people are perceived in group meetings.
Eclipse is Here to Help
Eclipse looks to combat this type of scenario in two ways: first, by empowering a team member to see how much they are (or are not) contributing; and second, by enabling a team lead to see if/when their personnel are dominating or under-participating in meetings.
While Eclipse offers no judgment in whether speaking more or less is preferable, our hope is that by offering a non-judgmental, data driven look at this information we can help pave a way towards a more equitable - and productive - meeting room.
See Two User Flows
Eclipse offers two flows: that of the team lead (or supervisor) and that of the team member. Supervisors can see team contribution levels during a meeting, while team members only see their own contribution.
First User Flow: Supervisor
team view included
Not anonymOUS
no judgment, Allowing Team Leads to contextualize speaking time
Second User Flow: Team Member
individual view only
anonymOUS
visualizes how contributions may be seen/interpreted by others
Shown Above: The team at work on the Eclipse in the design studio.
Design Process
Exploratory
Literature Review
Observation Studies
Case Studies
Exemplar Collections
Artifact Analysis
Generative & Evaluative
Rapid Ideation
Interviews/Concept Testing
Wireframing
Medium - High Fidelity Prototyping
Usability Testing
First Frame: Gender
Well documented/warranted, but risks being inherently combative.
Second Frame: Interruptions
Universally unacceptable, but may ultimately punish well intentioned colleagues.
Final Frame: ContributionS
Trackable, potentially anonymous, non-combative, and malleable.
Shown above are screens from the (now inactive) Woman Interrupted App website. This application heavily influenced our design, and is ultimately responsible for our decision to create a non-combative product. Source
FRAMING: Artifact Analysis
As we explored existing solutions and designs aimed at addressing our problem space, we conducted an artifact analysis on an application called the Woman Interrupted App.
What We Liked:
preservation of user anonymity
conversations are not recorded
bold color scheme
What We Didn’t:
combative language of tutorials and mission statement
off-putting assumptions made about both genders
unfinished (conceptual only)
Primary Constraints and Considerations
How might we create a design that promotes respect while also taking an intentionally non-gendered, non-combative stance?
How might we address the outside perception of our users while remaining non-gendered, non-combative, and preserving user anonymity?
How might we use color and physicality to effectively communicate data and enable user insights without being judgmental?
ABSOLUTELY MAD ALCHEMY
Our generative process cycled between ideation and iteration as we stress tested whimsical ideas through various user scenarios. Threads of these ideas evolved and merged into our final Eclipse prototype. Consider:
The Respect-o-Meter: what if everyone had a rating that indicated how respectful they were reported as being by others?
The Catharsis Box: what if during meetings, whenever you felt frustrated, you could tap your phone and add kindling to a digital fire to burn?
Respect Goggles: what if there were goggles that allowed you to see everyone’s respect rating as indicated on the Respect-o-Meter?
Shown Above: A representation of how an idea arrives, forms, manifests, and may be iterated upon.
USABILITY
For our testing, we conducted five remote, task driven usability tests along both user flows.
Participants were selected to represent both team leadership & team membership from a wide range of vocations, including lawyers, pharmacists, cybersecurity engineers, enterprise directors, and team leads.
Participants were walked through a scenario and asked to complete a set of tasks (run a meeting, then find and interpret results).
eclipse is on my side
During testing, the reception to our Eclipse application was overwhelmingly positive. Users cited the prototype’s ease of use, social value, and even - in one case - expressed interest in purchasing the application should it gain an engineering component. Towards this end, we have discussed the possibility of recruiting engineers for future iterations. Noteworthy quotes:
“How are you making sure this doesn’t turn into a tattle-tale app?”
“I think the non-gendered approach was the right one.”
“How is this data being used?”
FINDINGS: REQUIRED CalibratioNS
Overall, users showed little confusion in terms of interactions.
One of the main points, as best articulated by Tester 5, was the issue of color misleading the user as to which part of the Contribution Wedge was “theirs”.
This can be resolved by ensuring that colors align across wedges, letters chips, and text.
Shown Above: Preparing for remote usability testing with a nice cup of java.
Lesson & Reflection
Primary Lesson: Ideal vs. Real Users
Over the course of this project, one of our biggest breakthroughs came when conducting a usability test with a Program Director at IBM. When asked to describe her job, she responded by saying “I’m a manager who manages managers.” This simple sentence proved the key which would unlock the problem that had plagued us since the project’s early days.
In the beginning, our ideas surrounding the so-called Ideal User did not embrace the dynamism and complexity of real people. Specifically, while we imagined users as either supervisors or team members (and this framing shaped out entire design), the truth is that most people who would use Eclipse application would not simply be either a team member or a supervisor.
While these two roles do exist in a corporate environment, it was flawed thinking to believe that people sit exclusively in one of those two roles. Eclipse’s real users fill both roles, often simultaneously. In one room, they might be a team member - in another, they might be the supervisor. (Sometimes, it’s even complicated than that - as one user tester (a supervisor) said, occasionally their team will meet with someone even higher ranking in the room, simply to observe.)
Design Implication
Moving forward, the Eclipse application must - and will - be incorporated with existing company calendars and organizational charts. In this way, users will be afforded the view appropriate to their role in the room.
We looked to various forms of visual inspiration. We loved the use of color and language to convey a mood. Image Source
Reflection
We set out to design for respect, and in the end we hope we did.
In order to truly respect people, a design must not only accept but embrace their dynamism and simultaneity. People are complicated. They can be two things at once - even when those two things are seemingly at odds with one another.
In the end, we came to believe the best way to “respect” people is to not only find, but nurture - and empower - the parts of them of which they themselves are most proud.
An enormous thanks to our participants at Hewlett-Packard, IBM, UXG, Scientific Research Corporation, Verspire, Lichten & Liss-Riordan, Wexner Medical Center and Indiana University.
Would You Like To Know More?
Would you like to know more about Eclipse? If so, head over to the Eclipse Longform for an in depth review of the design process and future considerations.
Items included in the Longform (but not shown here) include:
Method Innovation: “Constellation Method”
Specific usability test results and video capture
Bringing Eclipse into the physical world with a design called “The Wallflower”
Shown above: The Eclipse team at rest. (L-R: Elisa Krebs, Ries Murphy, Clara Bradford, Aswati Panicker)