We believe that the comments section can be a place where diverse voices come together to share opinions and experiences. From the very beginning, we’ve prioritized better conversations and interactions over “engagement at all costs.”
To do this, we take a user-centered approach. Before a line of code was written or an interface was designed, we conducted hundreds of interviews with commenters, comment readers, non-commenters, moderators, community managers, and even trolls, to understand the problems surrounding the toxicity of comment section. We commissioned several studies to delve into motivations for commenting and to uncover the needs of underrepresented voices in the comments such as those of women, and gender non-conforming people of color. We continue to conduct such research today.
After each study, we take our learnings and translate them into user stories that reflect the needs of our users. We then use these stories to determine our priorities and decide what to build.
What are user stories?
A user story is a structured sentence that reflects a particular need that a user has, and explains why it is important to that user. When it comes to approaching user stories, there are two main schools of thought: needs-focused and feature-focused.
Needs-focused user stories
The traditional format of a needs-focused user story is as follows:
As a <user type>, I want to <user task or goal>, so that I <value statement>.
A user type can be as broad as a “new user” or more specific such as “commenter” or“moderator.” The user task or goal is a plain language articulation of something that user type would like to accomplish. And finally, the value statement is the reason why this task is important to that user. The key feature of a needs-focused user story following this structure is placing an emphasis on understanding what the user wants to accomplish, based on focusing on the problem at hand.
For example:
As a moderator, I want to be able to review a commenter’s comment history so that I can have better context to moderate their comment.
Feature-focused user stories
A traditional feature-focused user story is a little different:
As a <user type>, I want <a feature or solution>, so that I <value statement>.
For example:
As a moderator, I would like a drawer to appear with a commenter’s comment history when I click their username, so that I can have better context to moderate their comment.
Implications of feature-focused vs needs-focused
While the distinction between feature-focused and needs-focused user stories may seem small, the impact of that difference is great. For many teams, user stories are viewed as a limiting and overly formulaic way to describe a feature to be built. This is often a symptom of having a feature-focused approach to creating a product – you’ve already decided what to build, and are creating a reverse justification about why you’re building it, rather than having the focus on being trying to figure out the best way to fulfill a deeper user need. It’s like having an answer without fully understanding the question. This can easily lead to building the wrong thing, by merely putting a Band-Aid on a user’s pain point.
When a team has a needs-based, problem-first focus, user stories are a powerful tool for keeping empathy with its users. Needs-focused user stories give teams the freedom to explore a variety of solutions and to help prioritize what’s important. The focus is on the relative value solving the problem, rather than delivering a specific feature. Under this model, it is a team’s responsibility to dig deeper with our users to identify their needs and the problems they are trying to solve from both a high and more micro level.
As the sole designer wearing many hats on Coral, writing and using user stories in this way has turned advocating for user experience into a collaborative task, creating a shared language for maintaining empathy with different types of users.
How this works in practice
Handling feature requests
Coral primarily focuses on two types of users: commenters (a person who comments, wishes to comment, or reads the comments) and moderators (a person employed by a publisher whose responsibility is to approve or reject comments, and to respond to commenters).
Many of our clients have previously used other commenting platforms containing features they relied on to accomplish their goals. As a result, it is not uncommon for us to receive feature requests that reflect another platform’s functionality. Often times, this happens in the form of a conversation. For example, we’ve heard various versions of this request:
“You know, it would be really awesome if Coral had a feature that let us pin comments to the top of the comments section. It has been really helpful for us in the past when we want to make announcements or highlight a really awesome comment!”
Taken at face value, that statement alone could warrant us immediately writing a feature-focused user story as follows:
As a moderator, I’d like to pin a comment to the top of the comment stream, so that I can make sure all of our commenters are aware of changes or updates to our community and so that I can highlight a great comment.
Signed, sealed, delivered. Create the feature, problem solved. Except, not really.
Reframing the ask
In reality, the most interesting and helpful part of that feature request is not the feature, but the problems they are seeking to solve, and the deeper underlying needs they are trying to communicate – the ‘why’.
Under a needs-focused framework, we take a step back from that specific solution and write the user story in a way that focuses on what they’d like to accomplish instead of how they’d like to do it. The ‘what’ and the ‘why’ are core to the user’s expertise in this collaboration. The ‘how’ is our job.
After digging a bit deeper into this feature request, we uncovered at a high level that newsrooms wanted both to reward positive commenting behavior but also to set an example for what positive contributions look like. Similarly, from our research, some studies have shown a strong correlation between what people read and how they behave in the comments.
With respect to the goal of making announcements to all community members, at a high level we find that newsrooms recognize the importance and value in consistent communication. Announcements have a direct impact on behavior, either by explaining a change in policy that communicates transparency, or by shaping the topic for discussion, or in reminding people of the rules for all participants in the space. A desire to “pin them to the top” of the comment stream acknowledges that community members should be aware of these announcements and messages before participating.
In this case, there are two needs we’re trying to fulfill:
a desire to highlight a comment; and
a need to streamline announcements.
And so we wrote two separate user stories:
As a moderator, I’d like to make an announcement on a comment stream, so that I can make sure that our commenters are aware of changes or updates to our community.
As amoderator, I’d like to highlight a great comment, so that I can recognize commenters for their positive contributions and so that I can give would-be commenters an example of a great contribution.
Exploring and arriving at different solutions
From here, our team has the flexibility to explore a number of design solutions that can accomplish each or both these user goals, with a “pin comment” feature being just one possible path.
“Should announcements be in the form of notifications? By email? Pinning a comment would mean it would appear at the top of the comment stream… but is there another way that we can have something appear in a prominent place?“
“How could a highlighted comment appear? Should it have a different color background? Maybe a badge? Should it appear on the top of the comment stream? Should it be highlighted in a separate section? How many comments are usually highlighted, and where would they be best placed as a result?“
By taking advantage of this flexibility, we were able to deliver two distinct features to more directly address the users’ original goals:
‘Featured Comments’ allows moderators to easily select user comments to be highlighted as thoughtful contributions. Those comments are then shown in a tab that is separate from the whole of the comment discussion, and also receive a badge in the main comment stream.
A featured comment shown in-stream. This comment also appears in the “Featured” tab.
We created two types of announcement features:
The site-wide announcement box appears at the very top of every single comment stream on the site, which is great for sharing community guidelines and site-wide changes or updates.
We also built a separate announcement box available for each comment stream, to allow moderators to make story-specific announcements or pose topics for discussion.
Example of community guidelines posted site-wide along with a question posed for this specific story on school lunches
… and not a pinned comment in sight. We have since tested both features in the wild, and they are extremely popular and highly used – in fact, The Wall Street Journal created an entire strategy based around the Announcement feature.
In building Coral, commenters and moderators remain at the center of our work. Our goal is not to give them simply what they ask for, but to take a deeper look into understanding the problems they face, and the goals they are hoping to achieve, and build the right solution for them. User stories are a foundational tool we use every day to do that.
By Sam Hankins, Sr. Product Designer, Coral
We believe that the comments section can be a place where diverse voices come together to share opinions and experiences. From the very beginning, we’ve prioritized better conversations and interactions over “engagement at all costs.”
To do this, we take a user-centered approach. Before a line of code was written or an interface was designed, we conducted hundreds of interviews with commenters, comment readers, non-commenters, moderators, community managers, and even trolls, to understand the problems surrounding the toxicity of comment section. We commissioned several studies to delve into motivations for commenting and to uncover the needs of underrepresented voices in the comments such as those of women, and gender non-conforming people of color. We continue to conduct such research today.
After each study, we take our learnings and translate them into user stories that reflect the needs of our users. We then use these stories to determine our priorities and decide what to build.
What are user stories?
A user story is a structured sentence that reflects a particular need that a user has, and explains why it is important to that user. When it comes to approaching user stories, there are two main schools of thought: needs-focused and feature-focused.
Needs-focused user stories
The traditional format of a needs-focused user story is as follows:
As a <user type>, I want to <user task or goal>, so that I <value statement>.
A user type can be as broad as a “new user” or more specific such as “commenter” or“moderator.” The user task or goal is a plain language articulation of something that user type would like to accomplish. And finally, the value statement is the reason why this task is important to that user. The key feature of a needs-focused user story following this structure is placing an emphasis on understanding what the user wants to accomplish, based on focusing on the problem at hand.
For example:
Feature-focused user stories
A traditional feature-focused user story is a little different:
As a <user type>, I want <a feature or solution>, so that I <value statement>.
For example:
Implications of feature-focused vs needs-focused
While the distinction between feature-focused and needs-focused user stories may seem small, the impact of that difference is great. For many teams, user stories are viewed as a limiting and overly formulaic way to describe a feature to be built. This is often a symptom of having a feature-focused approach to creating a product – you’ve already decided what to build, and are creating a reverse justification about why you’re building it, rather than having the focus on being trying to figure out the best way to fulfill a deeper user need. It’s like having an answer without fully understanding the question. This can easily lead to building the wrong thing, by merely putting a Band-Aid on a user’s pain point.
When a team has a needs-based, problem-first focus, user stories are a powerful tool for keeping empathy with its users. Needs-focused user stories give teams the freedom to explore a variety of solutions and to help prioritize what’s important. The focus is on the relative value solving the problem, rather than delivering a specific feature. Under this model, it is a team’s responsibility to dig deeper with our users to identify their needs and the problems they are trying to solve from both a high and more micro level.
As the sole designer wearing many hats on Coral, writing and using user stories in this way has turned advocating for user experience into a collaborative task, creating a shared language for maintaining empathy with different types of users.
How this works in practice
Handling feature requests
Coral primarily focuses on two types of users: commenters (a person who comments, wishes to comment, or reads the comments) and moderators (a person employed by a publisher whose responsibility is to approve or reject comments, and to respond to commenters).
Many of our clients have previously used other commenting platforms containing features they relied on to accomplish their goals. As a result, it is not uncommon for us to receive feature requests that reflect another platform’s functionality. Often times, this happens in the form of a conversation. For example, we’ve heard various versions of this request:
“You know, it would be really awesome if Coral had a feature that let us pin comments to the top of the comments section. It has been really helpful for us in the past when we want to make announcements or highlight a really awesome comment!”
Taken at face value, that statement alone could warrant us immediately writing a feature-focused user story as follows:
Signed, sealed, delivered. Create the feature, problem solved. Except, not really.
Reframing the ask
In reality, the most interesting and helpful part of that feature request is not the feature, but the problems they are seeking to solve, and the deeper underlying needs they are trying to communicate – the ‘why’.
Under a needs-focused framework, we take a step back from that specific solution and write the user story in a way that focuses on what they’d like to accomplish instead of how they’d like to do it. The ‘what’ and the ‘why’ are core to the user’s expertise in this collaboration. The ‘how’ is our job.
After digging a bit deeper into this feature request, we uncovered at a high level that newsrooms wanted both to reward positive commenting behavior but also to set an example for what positive contributions look like. Similarly, from our research, some studies have shown a strong correlation between what people read and how they behave in the comments.
With respect to the goal of making announcements to all community members, at a high level we find that newsrooms recognize the importance and value in consistent communication. Announcements have a direct impact on behavior, either by explaining a change in policy that communicates transparency, or by shaping the topic for discussion, or in reminding people of the rules for all participants in the space. A desire to “pin them to the top” of the comment stream acknowledges that community members should be aware of these announcements and messages before participating.
In this case, there are two needs we’re trying to fulfill:
And so we wrote two separate user stories:
Exploring and arriving at different solutions
From here, our team has the flexibility to explore a number of design solutions that can accomplish each or both these user goals, with a “pin comment” feature being just one possible path.
“Should announcements be in the form of notifications? By email? Pinning a comment would mean it would appear at the top of the comment stream… but is there another way that we can have something appear in a prominent place?“
“How could a highlighted comment appear? Should it have a different color background? Maybe a badge? Should it appear on the top of the comment stream? Should it be highlighted in a separate section? How many comments are usually highlighted, and where would they be best placed as a result?“
By taking advantage of this flexibility, we were able to deliver two distinct features to more directly address the users’ original goals:
… and not a pinned comment in sight. We have since tested both features in the wild, and they are extremely popular and highly used – in fact, The Wall Street Journal created an entire strategy based around the Announcement feature.
In building Coral, commenters and moderators remain at the center of our work. Our goal is not to give them simply what they ask for, but to take a deeper look into understanding the problems they face, and the goals they are hoping to achieve, and build the right solution for them. User stories are a foundational tool we use every day to do that.