diana
bloom
SYMPHONY
Inline Reactions
Summary
Symphony users were complaining about unnecessary noise generated in chat rooms from users reacting to chat messages by sending another message. Additionally, Symphony wanted to provide users with more ways to engage socially.
Project goal
The goal was two-fold: Increase engagement by enabling users to react to messages using emojis, and cut down on room noise.
My role / project scope
I was the lead designer in collaboration with various stakeholders, developers, and design team peers during the process.
Reactions was one of five separate projects under a meta-project “Inline Message Actions”. I worked on all sub-projects in parallel.
PROCESS
Initial research
After kicking off the project, I looked at competing B2B collaboration platforms as well as social media and chat apps. Most offered the ability to directly react to a message, with the biggest variance being the size and type of emoji sets.
I also dug into the feedback and requests from our clients. There were two distinct needs:
1. Ability to quickly react to a message without sending another message
2. Ability to reply directly to a message with the reply linked to the original message
Replying directly to a message was a separate project, but it works hand-in-hand with reactions.
Primary considerations
Symphony users work in milliseconds and speed is critical, so adding (and removing) reactions had to be discoverable and lightweight - at most a 2-click interaction.
Other considerations:
-
How reactions mesh with other message actions
-
Which emoji set to use (or whether to create a separate custom set)
-
Aggregating notifications
-
Company compliance concerns
Allow "negative" reactions?
Certain financial users can be sensitive to social feedback due to perceived impacts on their reputation. We needed to be careful about whether to include emojis that could be seen as "negative", such as thumbs down, frowning faces, etc.
No
Yes
Maybe
I surveyed internal users since many Symphony employees have a background in finance.
Results were mixed:
-
~20% - negative reactions should not be allowed
-
~25% - negative reactions should be allowed
-
~55% - negative reactions were ok only for certain purposes (like polling)
There was no clear winner and some clients are more cautious about what they'll allow than others. The final design had to be flexible enough to accommodate admin controls over which emoji sets are allowed.
Allow multiple reactions?
Another decision point was whether to allow a user to apply multiple reactions to the same message. There were risks either way:
-
Risk of "spamming" behavior if multiple reactions are allowed
-
Inhibiting opportunity for more social engagement if only one reaction is allowed
We didn't have data to back up a choice either way, so the MVP design allows for multiple reactions. The model can be adjusted in the future.
Sketching, menu & inline display pattern
Part of the inline message actions meta-project was designing a menu for all available actions. I worked on Reactions and Bookmarking in parallel and sketched ideas for both.
To start on the inline pattern for Reactions, I did some initial (messy) sketches, then quickly moved to higher fidelity wireframes to get a sense of how it would look in a few different configurations and with other inline actions.
Inline pattern explorations
After exploring several options for the inline visual design, I met with design team peers and we settled on a pattern that echoes the rounded badges used elsewhere in the app.
Prototyping & user testing
To make sure the interactions made sense we tested both internally and with UserTesting.com. Test results were consistently above 90% pass rate.
Flow
There are multiple entry points to add a reaction:
1. Use the overflow menu
2. Use the "+" menu
3. Click on an existing reaction
This flow illustrates adding a reaction using the "+" button.
User testing showed there was no confusion between entry points.
Next steps
Users will want to know when a message is receiving reactions. A new notification center was being designed separately, so a follow-on project is to develop a pattern for notifying both the original poster and users in a room when there's a message that's receiving reactions.
It may also be necessary to allow admin users to choose which emojis to allow.
Learnings
This project went relatively smoothly with no technical snags. The interactions were well received by test subjects, and the feature will drastically reduce noise in rooms.
The area that created the most churn was the decision around how many and which emojis to display. There were differing opinions all around, and if I were to do it over again I'd survey as many external customers as possible to get input earlier in the process.