Social Computing, Phase 2+3
Ideating + Paper Prototype
This document is written for the Final Project in H541: Interaction Design Practice — Instructed by Sonali Shah, at IUPUI in Indianapolis, IN.
Other parts of this project:
In this phase of the project, I delve into some low-fidelity mockups for the nonverbal feedback in messaging platforms, as outlined in Social Computing, Phase 1.
Phase 2.1: Initial Paper Prototype shares my primary sketches and the related peer feedback collected for two distinct directions.
Phase 2.2: Revised Concept provides a description of the newly refined purpose of my solution following the Phase 1 user research and the aforementioned peer feedback.
Phase 2.3: Updated Prototype presents the newly updated paper prototype which shows a basic flow and functionality of the solution, as a revision to the initial sketches.
Phase 2.4: Prototype Validation contains my “Quick-and-Dirty Usability Test,” as described by Leah Buley in The User Experience Team of One (Buley, 2013).
2.1: Initial Paper Prototype
As an interim phase of this project, I created some rough paper prototypes to serve purely as a visual as we were required to gather feedback from at least two classmates. For this, I pursued two directions, as outlined in the assignment’s requirements.
One important note about the solution: for the purposes of this project, I will be mapping the features onto iOS Messages. This is due to the fact that it is widely used, familiar to all of the users I interviewed, and, most importantly, is the messaging app that I am most familiar with. While the precise visual implementation of these features might vary from one messaging platform to another, the concepts still hold true.
Concept 1: Snoozed Conversations
As the name suggests, this approach would allow users to “snooze” a message that contains a response they are unable to respond to immediately. My initial user research showed that message recipients put off responding to message for a wide variety of reasons (see Phase 1). This would encourage a timely response to the message sender, by providing a notification at a set time.
In the first sketch, you can see the conversation view. When the recipient receives a message they are unable to respond to in the moment, they have the can press the snooze icon at the top right. This will bring up a popover.
Using the popover dialog, the user can select a date and time they would like to receive a reminder about the conversation. They can choose from some contextually aware options, such as “this evening” or “tomorrow,” or they can set a specific date a time with a system date/time picker element.
Once the user confirms the snooze details, the message list view will include an indicator that it has been snoozed for later (via an icon), along with what time it will be snoozed for. A response from the message recipient before the set time will cancel the snooze (though a new message from the sender will not). The snooze notification can be disabled at any time.
The user will receive a notification at the specified time. It will include a descriptive message, such as: “Snoozed conversation with [Name]. Respond to ‘[snoozed message]’.” The message in question is whatever the most recent message was at the time of the snooze. The notification will include the options “Respond” (primary action) or to “Snooze Again.”
Concept 2: Flagged Conversations with Receipts
The second approach involves flagging a conversation. As a key difference, this concept also includes feedback to the message sender. However, rather than including “Read [at time],” this would not display the time but indicate that the message recipient has marked the message and will come back to it later.
This is a “kinder” way of communicating back to the message sender that the recipient has read the message and intends to respond. However, they are being delayed by some reason which is not specified. This way the sender knows they are not being ignored.
The flag button resides by the text entry input, as it is an alternative action to responding right away. Hitting this button will mark the message as “flagged.” This will be indicated in the conversation view, from the conversation list view, and will also be reflected in the messages notification badge. This will allow the message to stand out as not-yet responded to as part of the natural user pattern of unread messages.
Finally, when the recipient flags the message, the sender is able to see a label, similar to the previous “Read Receipts” label. This label reads, “Delivered. [Name] will respond to you soon.” The user is able to customize this precise message in their settings. This indicates to the sender that their message has not been forgotten, but does not require any action from the recipient.
One key point of feedback I received from peers was for the second scenario: could the message that is displayed to the sender be customized by the recipient? There are a few directions that could be taken to address this:
- Option 1: Recipient can type out a message to be displayed to the sender every time.
Downside: This would require an identical level of effort as simply replying to the original message. Therefore it would defeat the purpose of the feature and provide the recipient no additional advantage. This fails one of my key requirements as defined in Phase 1, “Requires little to no effort on the sender and receiver’s end.”
- Option 2: Instead of creating a message to respond every time, the recipient could customize the message that is displayed to the sender in advance, as an app setting. The same message would be used each time, meaning they would not need to write it out every time. This could be set for all senders or on a per-person basis.
Downside: This would still require far too much effort from the user, and many messaging users would likely not be aware of it.
- Option 3: The recipient could choose from a set of pre-made messages, such as “I’ll respond soon!” or “Busy at the moment.” This is similar to a feature that exists in iOS when receiving a phone call.
Downside: It would still require input from the recipient, who may not have time to choose the most accurate response. In short, it fails to simplify the interaction. Any response status displayed to the sender should not require additional input from the recipient.
- Option 4: Adjust the wording of “[Name] will respond to you soon” so that it does not overpromise, while still communicates it has been seen and the recipient intends to respond soon. This must also strike a balance by not coming across as overly harsh, which is a current flaw of the “Read [at time]” pattern.
Downside: Determining the perfect label and wording that describes every situation may be impossible. Not to mention, it would require solving for every language that uses the messaging app (hundreds of languages).
- Option 5: Avoid specific copy altogether in the status label that is displayed to the original message sender. Instead, use a visual system to indicate to the sender when the message has been marked to be returned to later.
Downside: Clarity. How will users know what the visual indicator means? This indicator must rely on existing patterns of digital communication to be successful.
One other piece of feedback I received was that both directions provide some value and could potentially be combined to create a more complete solution. While there is certainly some overlap that will need to be resolved, a combined effort could provide a more valuable end product.
2.2: Revised Concept
My user research and peer feedback provided me with a different perspective to approaching this problem. Rather than seeing communication delay as a hurdle that needs to be overcome, it can also be seen as a feature of the channel. In fact, it is the reason that so many choose to use messaging over phone calls and other more direct methods of communication. So my goal with this solution is to enhance the benefits gained by the communication delay, while also reducing the impact of the negative effects.
Based on my initial user research in Phase 1, I came away with a specific set of requirements for my solution. Following my peer feedback, I am able to expand on these in context:
- Requirement 1: The solution should provide transparency between the sender and receiver.
Feedback to the sender on the status of the message with the recipient must be included.
- Requirement 2: The solution should require little to no effort on the sender and receiver’s end.
The status label that is displayed to the original message sender should not require any positive sending action from the message recipient but should happen as a side-effect of other actions.
- Requirement 3: The solution should encourage a timely response.
This will be accomplished by the inclusion of a few features: Snooze, Flag and Send Later (more details for these later). Note the use of the word “timely,” rather than “quick.” Each of these features contributes to control over timing and cadence of messages.
- Requirement 4: The solution should prevent messages from being forgotten.
This will primarily be accomplished via Snooze and Flag, in addition to a better visual indicator in the conversation list view when the other person was the last to respond.
- Requirement 5: The solution should allow for immediate feedback from the receiver to the sender (and vice versa, if applicable).
The recipient can take a number of actions (including opening the message, flagging and snoozing), which should concurrently change the status displayed to the message sender.
- Requirement 6: Both sender and receiver should willingly opt-in (on each message send instance or for the entire conversation history).
The user will be able to disable the label from displaying to the sender from within the conversation preferences.
2.3: Updated Prototype
The updated paper prototype below is broken into 4 separate flows. For the recipient, there’s the snooze action flow, the flag action flow, and the send later flow. For the sender, there’s the status label flow.
From within the conversation view, the user can choose the “Snooze” button next to the text input. When this is selected, the Snooze dialog will pop up, allowing them to choose a time for the message to be snoozed until. In the conversation list view, a snoozed message will be indicated with an icon at the right of the list item. It will also indicate the time it has been snoozed until. When that time has been reached, it will send a notification telling the user to respond to the latest message when they initiated the snooze.
From within the conversation view, the user can choose the “Flag” button next to the text input. When this is selected, the message will be marked to return to later. In the conversation list view, a flagged message will be indicated by a bubble at the left hand of the message. If you have a flagged message and you receive a new (unread) message from the same person, it will display an encircled bubble to indicate both unread and flagged. Any flagged messages will contribute to the messages’ badge app icon.
When composing a new message, recipients (and technically also senders) will have an icon for “Send Later” next to the standard “Send” button. When selecting this, a dialogue (similar to “Snooze”) will appear allowing them to choose from some time-contextual times. After selecting a time, a pending message will show up in the conversation. This will include a label that reads “Sending at [time] • Edit.” The edit option will bring up an action sheet with options to edit the pending message, send now, or cancel. At the determined time of send, a notification will inform the user that the message has been successfully sent, or that it has failed.
Each of these actions (save for the “Send Later”) has an associated Status Label side-effect. The sketches to the left indicate that this label is displayed to the sender in the same location as the standard “Read Receipt.”
The diagram indicates what message will be displayed by the Status Label and when. As the message is first sent, it shows “Sent” and then “Delivered” when it has been successfully delivered (also included are error messages which display when the message has failed to send correctly). Then, most importantly, there are the action labels. A message that has been seen is indicated by an eye icon. The “delivered” message remains to tell a more complete picture. A similar pattern is used to show when a message has been flagged or snoozed.
Notice that delayed send intentionally does not provide any feedback via the Status Label to the message sender. This is because knowing a new message will be coming soon without actually knowing what the message actually is serves the sender no real benefit, and would likely lead to a feeling of anxiousness or apprehension.
2.4: Prototype Validation
To conduct the usability test, I followed the guidelines of the “Quick-and-Dirty Usability Test” as per Method 21 in The User Experience Team of One (Buley, 2013). We have used this particular format in the past with the Midterm Project. With this exercise, we “forego rigor and perfectionism” and “test the designs with anyone who’s available…[and] unfamiliar with the product.” This allowed me to gain a number of insights on my paper prototype.
The first sticking point for my subject in walking through the various flows, was “what happens to a message that’s been snoozed?” In other words, does it get hidden from the conversation list view, or does it remain? It seems likely that this confusion stems from the name “Snooze” being somewhat ambiguous. From this, I decided that “Remind Me” is a more fitting description of that particular action. “Snooze” can mean different things in different contexts. In many apps, this will remove the item altogether and then send it back to you at the given time.
As an extension of renaming “Snooze” to “Remind Me,” to further reduce ambiguity, I intend to use a different icon than just a plain clock. Instead, something like looks like a classic alarm clock with bells at the top or a notification bell would be a better indication of the functionality.
Another valuable piece of feedback from my subject was that “Remind Me” (and by extension, also “Send Later”) should have shorter default times in the dialog box. This makes sense as the cadence of messaging is much quicker pace than email and other forms of communication.
My test subject specifically mentioned “driving” as a common use case for wanting to reply later (as a means of safe driving). It would be beneficial if the “Remind Me” feature could tap into the system “Do Not Disturb While Driving” status, which was implemented in iOS 11. In that case, the message recipient could get a reminder to respond when they are done driving. That would be a major step towards timeliness.
For the flagged messages flow, my test subject was particularly bothered by the idea that the badge app icon number would include flagged messages. She mentioned that many users prefer to have their badges completely under control and this could be a pester. As a remedy to this, the flagged messages in the list view would stand out enough to remind the recipient to respond, without adding to the badge app icon.
Furthermore, this encouraged me that the status of a message (whether snoozed or flagged) should be visually indicated somehow within the conversation view (not only the conversation list view). This was followed by an insight that flagged conversations should be pinned to the top of the conversation list view.
In addition, there should be a swipe actions menu in the conversation list view. Currently, swiping a message to the left brings up the “Delete” action button. But swiping to the right could bring up “Send Later” and “Flag.”
In revisiting the original requirements with my test subject, I also determined that it should include a method to disable the “Status Labels” directly in conversation stream rather than having a toggle in the conversation details. Most people are not aware of “Read Receipts”(especially the ones at a per-conversation basis) because it is hidden and separate from the action itself. This needs to be visually represented on the sender and recipient’s screen when they send a message, directly in the conversation view, associated with the latest message.
An interesting note I also encountered was that currently, the actions buttons are always present in the compose bar at the bottom. But as they are tied to specific messages, perhaps they should appear below a received message, just as the status labels are displayed below the send message. The tradeoff would be a more cluttered conversation space.
Finally, as a minor detail, the Status Label direction need to be reversed to accurately reflect actual order of occurrence. For example instead of “[Eye Icon] Delivered.,” it would read “Delivered. [Eye Icon].”
In this phase of the project, my solution significantly evolved from a high-level concept to a specific and targeted set of actions and features. It also allowed me to transform how I view the problem space. Rather than focusing only on resolving the issues presented by communication delay, I also want to enhance the possibilities it presents. That is most clearly represented by the “Send Later” feature, which takes advantage of the control that messaging provides its users over timeliness.
In the next phase of the project, I will create high-fidelity prototypes, which will not only represent what was included in my paper prototypes, but also embrace the takeaways from my validation.
- Buley, L. (2013). The User Experience Team of One: A Research and Design Survival Guide. Brooklyn, New York: Rosenfeld Media, LLC.