Overview
I lead design on a new social feature in Confluence, taking a scrappy, iterative approach with my PM to get feedback early and often
My role
End-to-end designer, including research planning, feedback triaging, design execution, and leadership presentations.
Timeline
8 months (on and off), 2021
Overview
I lead design on a new social feature in Confluence, taking a scrappy, iterative approach with my PM to get feedback early and often
My role
End-to-end designer, including research planning, feedback triaging, design execution, and leadership presentations.
Timeline
8 months (on and off), 2021
Context
Confluence is traditionally referred to as a wiki product, as it allows users to write and read documentation for their teams and projects. But inside the company, we were trying to evolve that perception. We felt it could become a more open, collaborative, and even bustling center for work.
Activity Feed came about as one of the new Smart team's first projects with the goal of furthering this mission. The vision was to help users discover what was going on around them, in turn transforming Confluence from a black box into a town square.
Process
For this project we knew that typical interviews and user testing could only take us so far. Feeds deal in user-generated content, and the relevance of the content shown to users is very personalized – not something we could fake with sample data.
This lead us to focus on building prototypes in code and getting customer feedback as much as possible, even if those customers were internal employees.
Our process was closer to the typical build-measure-learn loop than linear steps
As we learned from customers, we adapted our prototype to learn more, expanding our user base as we gained confidence. Our single most helpful decision was to create a feature flag for employees and stakeholders to enable so they could try out the feature and give us feedback on a rolling basis.
With each iteration we expanded our group of testers
Problem Space
The project started with a hunch that our existing feeds could be improved. But what did that hunch mean? Was there really an opportunity here?
The existing "All updates" feed was very noisy in active Confluence instances
Our existing feeds, which could be found in a sidebar experience on home, allowed users to browse either all activity or popular activity in Confluence.
While not positioned as a core experience in Confluence, some users made regular use of it. However, we found that at companies grew, fewer and fewer users used the "All Updates" feed.
"All updates" was useful, but only in small instances
To us, this signaled a missed opportunity. If users at small companies found value here, wouldn't those at larger companies too? Our hypothesis was that the current solutions weren't serving our larger customers.
I helped visualize the gap the feed would fill, positioning it in the space between existing features:
We wanted the new feed to make Confluence feel more open and transparent
With this lens, we began to see feeds as helping users discover content that was relevant to them but which they probably didn't yet know about.
Opportunity: How might we help users discover content and activity relevant to them?
The Relevance Problem
With our understanding of the problem space more refined, it was time to tackle our first big problem: relevance. The feed could be beautifully designed and integrated into the product, but if the information surfaced wasn't relevant, it would be a flop.
We had a basic choice to make: should we use a smart model, or a heuristic model? A smart model, which would use algorithms to personalize surfaced content based on information about a user, seemed like the ideal state. But we also knew this might not be feasible up front.
A heuristic model, on the other hand, would be based on simple rules. These rules could be explicit (user follows X person and sees updates from them), or implicit (user viewed Y space and sees updates from that space). Point is, they'd be easy to define – and easy for users to configure.
And this was at the end of the day the direction we decided on. We not only had confidence we could define simple rules, but also believed it was all we needed at this stage of the project. It would garner us valuable feedback, and would help us decide how much to invest in a smarter model in the future.
Hypothesis: We believe that a feed based on user-specified spaces and people will help users both stay across important discussions and discover relevant content.
Humble Beginnings
With our sights on researching with customers, we cobbled together a basic prototype with our idea.
This new feed would be based on spaces users were watching. ("Watching" was an existing concept in Confluence that let people mark spaces they wanted to receive email updates about.)
For our prototype, we would filter All Updates by these spaces and allow users to edit their watched spaces (and therefore feed) right from that view. This would let us configure it with them in interviews to learn what was working and what wasn't.
The first experiment surfaced pages that the user marked as "Watching," but users were inundated with emails
Introducing "Following"
As we sat in on interviews with customers, it became clear that – although users enjoyed seeing a more tailored version of feed, and were even excited by it – one problem stood out to us: email spam.
We weren't totally surprised, either. Users were finding that if they wanted to watch a bunch of spaces for feed updates, they would also be inundated with emails for all the same activity. Knowing our user base's frustration with Confluence emails in general, it was looking like this could be a strong deterrent for feed use.
We knew that configuring the feed was an important part of the experience, but we were hesitant to create another concept or change something big in product when we were still in exploratory phases.
After closely considering our options, we decided to introduce a "following" concept. Following would work quite like "watching," except it wouldn't send any email notifications. Users would be free to configure without worry of endless spam. Long term, we saw this as a first step towards phasing out "watching" all together.
We also liked that this concept could expand to allow users to follow other objects like people, teams, pages, labels, and more. This would let us to experiment and learn without disrupting the existing product and its concepts.
To provide reasonable defaults, the design automagically followed 3 people and 3 spaces for each user
Users could edit their feed to their liking. This ended up being a helpful datapoint as we iterated.
Users could edit their feed to their liking. This ended up providing a helpful datapoint as we iterated.
Designing Feed Cards
Now that I've shared how we laid the groundwork for feed with the following concept, I want to jump to a more tactical and detailed topic: form factor.
Noise
We had decided that users could determine what streams of activity (from people and spaces) would go in feed, but had noticed that even activity from one stream could prove too noisy. Users often comment or edit multiple times in a row, and with the current implementation all of those would pile up and push down other information.
Below you can see some options we considered with regard to grouping activity updates. On the far left, the current model shows a feed item for every separate action. But to avoid the repetition and noise, we thought we could combine actions somehow.
How activity is grouped greatly affects the feed reading experience
When it came to the design of the feed itself, we decided to show each page only once. As opposed to an activity log (like All Updates), this would eliminate the noise provided by showing every action separately.
Card Information
Designing what information went on feed cards proved challenging from a few standpoints. First, there was the constant tension between information and scannability (with more info generally making it harder to scan). Then, there was the challenge of organizing that information so it was easy to understand and digest.
As we gained more understanding of what users might be looking for, I identified three key categories:
User "lenses" helped us talk about what was important to the design
I used these three lenses – topic, social proximity, and momentum – to explore some possibilities. This proved a great way talk about where we saw feed going, even if many of these ideas could not be implemented in our beginning iterations.
A few of my card explorations. There were lots of possibilities, but I wanted to be opinionated in our final design
Prioritization
At a certain point, I decided to take an analytical tack. When it came to the information we would show, certain aspects like page title were intuitively important. But what about the rest?
To address this, I lead my team in an exercise to place the kinds of information and potential actions into three buckets: obvious, easy, and possible. This helped us make tradeoffs about what deserved prominence and what didn't, and moreover helped us avoid the "frankenstein" page card I feared.
I lead a prioritization exercise with my PM and Eng lead
Fitting in with the Atlassian System
The design also had to keep in mind that the feed and feed cards would not be living in isolation. They had to exist harmoniously with the whole – not only within Confluence but within the Atlassian suite of products.
I collected examples of cards from across Atlassian
One particular challenge was figuring out how similar feed cards should be to another card design we were using in product. Not wanting to introduce an unnecessary design pattern (and to keep pages looking familiar to users), I looked at a spectrum of options.
I compared different card styles on a spectrum from consistent to distinct
Ultimately my philosophy was that the feed cards should feel like a part of the same "family" as other page cards, but that they didn't have to look exactly the same. After all, the purpose of feed was unique, and required a hierarchy of information that the other card designs simply weren't flexible enough for.
Getting Feedback
Throughout the process we gathered feedback from a number of places, including select customers who had signed on for our beta program. But perhaps our most beneficial group was internal users: passionate and ready to give feedback.
Early on, we pushed a banner to all Atlassians (4000+ people) that let them opt in to the new activity feed experience. We monitored feedback on a dedicated Slack channel, and the constant stream of input was invaluable to our experience.
I designed a banner to allow all Atlassians to try out the feed. Illustration by Vania Wat
Results
After lots of feedback, design crits, stakeholder reviews, and iteration, the design was ready to go out for a larger customer experiment.
The new feed goes bold and is the first thing users see in Confluence
One subtle way the design provides context is through a summary of recent actions. This solution is intended make it much easier to understand what was gaining or keeping momentum, where people are working, and what is worth digging into.
One subtle way the design provides context is through a summary of recent actions. This solution is intended make it much easier to understand what was gaining or keeping momentum, where people are working, and what is worth digging into.
One subtle way the design provides context is through a summary of recent actions. This solution is intended make it much easier to understand what was gaining or keeping momentum, where people are working, and what is worth digging into.
The design let users see recent activity without going to the page itself
The comment is another key piece of supporting information. We decided to show the comment if it was the last action taken on that page. (Comments are displayed in gray boxes to visually distinguish them from the other aspects of the cards.)
In future iterations, we're looking forward to exploring how to show more comments and how to use smarts to surface the most relevant comment up-front.
The comment is another key piece of supporting information. We decided to show the comment if it was the last action taken on that page. (Comments are displayed in gray boxes to visually distinguish them from the other aspects of the cards.)
In future iterations, we're looking forward to exploring how to show more comments and how to use smarts to surface the most relevant comment up-front.
The comment is another key piece of supporting information. We decided to show the comment if it was the last action taken on that page. (Comments are displayed in gray boxes to visually distinguish them from the other aspects of the cards.)
In future iterations, we're looking forward to exploring how to show more comments and how to use smarts to surface the most relevant comment up-front.
When it came to the action buttons (like, comment, share), we debated quite a bit between displaying them subtly or prominently. Ultimately we chose the latter, with the commitment to gather engagement data for each and adjust the design if needed.
When it came to the action buttons (like, comment, share), we debated quite a bit between displaying them subtly or prominently. Ultimately we chose the latter, with the commitment to gather engagement data for each and adjust the design if needed.
When it came to the action buttons (like, comment, share), we debated quite a bit between displaying them subtly or prominently. Ultimately we chose the latter, with the commitment to gather engagement data for each and adjust the design if needed.
Impact
As of this writing, we are on the eve of rolling out our experiment to customers and don't have final impact data. However we've put in place mechanisms for qualitative feedback, and added data instrumentation for all the parts we want to measure.
On the latter, I worked with our business analyst team, PM, and engineers to ensure we had instrumented the right parts of the UI. We all also worked together diligently to prioritize them so the most important pieces could be put into code first.
I created an index to help us identify what we would and would not instrument on the feed cards
In addition to key metrics like engagement and retention, we are looking to learn more about relevance. We will be closely monitoring the spaces and people followed in order to grow the sophistication of our relevance algorithm.
What's next?
I'm so proud to have been part of the first steps of what will hopefully be a long-living feature in our product. What's more, the data we gather can help drive smart suggestions beyond this feature. We aren't just building a feed, but also a foundation for a better understanding of our users.
