Context
My experience designing for Confluence up to this point was pretty clear: solve a known customer problem. This project, in addition to that goal, had the responsibility of enhancing Confluence's new Premium offering as well. This presented a challenge: balance user needs with business needs when the two don't always see eye to eye.
Problem Space
Confluence is often referred to as a wiki, and users can write documents – or pages – that live in what we call the page tree. Over time, as teams grow and pages accumulate, the page tree can often become cluttered with outdated content and immensely disorganized, especially when no one is actively tending to it.
If disorganization is the byproduct, the impact to users is that it becomes extra hard for them to find what they need. Thus begins a vicious cycle: as a page tree becomes less organized and therefore less "browsable," it in turn becomes harder to organize. This directly impacts customer retention – as well as the bottom line.
Opportunity: How might we empower users to remove outdated and duplicate content from their page trees?
In a nutshell, this feature would let users archive instead of permanently deleting pages
Process
If I speak generally this project evolved as a typical process, moving from discovery to design to shipping in code. But when I reflect on the specifics, the process was messy – and I mean that in the best way possible.
You could start by looking at the concept testing my PM and I did early on without a researcher. It might have been scrappy, but it absolutely pointed us in a solid direction. Or you could consider the many little discussions with engineers after standup about edge cases they'd found. Finally, you might look at the technical constraints for bulk archiving that engineers only discovered when they got into the weeds.
However you look, the team persisted and got the project out the door. That feat was the result of weekly cross-functional check-ins, daily standups, design reviews, and our fair share of Slack threads. In the process, I worked closely with a PM, engineering manager, engineering team of front and back-enders, and a writer.
The journey was full of surprises, and I'd like to share a few of the roadblocks along the way.
Challenge 1: Edition Gating
Context
At this point in time, Confluence had just released its new editions (Free, Standard, and Premium), and Premium needed a boost. We knew, per the remit of our team, that driving upgrades would be a key measure of success. But archiving felt essential. What was appropriate to put into Premium?
We could risk putting every aspect of the feature in Premium, but this would likely anger customers who expected basic functionality for free. On the other hand, putting too much in Standard could make it harder to reach our upgrade business goals.
Initial Solution
There were three aspects of the feature that could be easily separated by edition:
• archiving a single page
• archiving a section of pages (nested)
• or archiving a complex selection of pages (bulk).
We started with the assumption that basic functionality should go in Standard, and power-features like Bulk archiving should go in Premium. This would fit in with our goal to cater Premium to Enterprise companies, who would place greater demands on archiving as their teams and content scaled, and actions would become more frequent and repetitive.
But what about nested pages? This seeming in-between functionality might be expected, but could also be used as a rough workaround for bulk archiving, potentially cannibalizing upgrades.
We did some preliminary research to address this and other questions. Below, some synthesis I lead with my PM and eng lead based on user testing we conducted:
Concept testing of initial prototypes let us check our assumptions about user expectations
Final Solution
Through our research we found that users generally expected to be able to be able to archive nested pages, but that this was not the dealbreaker that single-page archiving was.
Weighing all the tough tradeoffs, we ultimately decided to put this functionality in Premium. Single-page archiving lined up with the greater vision we had for our Standard offering. Moreover, this decision optimized for business goals while allowing us to keep the door open to change if customer feedback gave us a strong signal.
Challenge 2: Reducing Friction
Context
When I did a design audit at the outset of the project and noted we already had "delete" functionality in the product, I had to wonder: What is archiving adding?
I felt it was crucial to distinguish between deleting and archiving. A big part of that would be making archiving feel more accessible – and less permanent – than the former. With the goal of encouraging users to organize and archive, I sought to really make archiving feel light and easy.
In an early solution, research participants had a hard time finding the archive
Users also took too long to understand how to restore a page to the page tree
Solution
I felt that it should be really easy to find the archive. This would make it feel like archiving could be easily un-done, encouraging the behavior and de-cluttering page trees.
To achieve this, we placed the archive entry point at the bottom of the page tree. Prominent enough that it could be easily found, but not so prominent as to conflict with more frequent user tasks.
I moved the entry point to a more prominent spot to reassure users how they could recover pages
We also decided to set the default location for unarchiving (aka restoring) to the last known parent page. This would make it super easy to put pages back if someone had made a mistake, or a user realized they wanted the page after all.
The updated design had better defaults, clearer information grouping, and the more natural language of "Restore" in place of "Unarchive"
Challenge 3: Nested Pages
Context
Archiving a section of pages (nested archiving) ended up being, well... quite complicated. As a sampler, consider these cases:
• What if I only have permission to archive some pages?
• What if there are pages I don't have permission to see within a section?
• How would these scenarios work with deeply nested pages? (multiple layers)
After deciding to include nested archiving in our feature, I had to figure out how to handle these cases. Not only that, but what would we convey to the user? (And what was the importance of each message?)
Solution
When a user is on Premium, we decided to allow them the option to archive with nested pages. We would enable this option by default, while providing a warning message if users did not have to archive all pages.
Providing the right information at the right time was a big challenge, and looking back there are still things I'd like to improve
Upsell: If a user is not on Premium, they see a message that lets them know they have to upgrade if they want this functionality.
Challenge 4: Bulk Actions
Context
Bulk archiving posed many challenges – especially when it came to interaction patterns –but our chief question was about where bulk archiving should exist in product.
In our initial research, we tested bulk archiving from 3 places (below). But results showed that each had its merits. And through our discussions we realized that they were not mutually exclusive. So where would we focus first?
Initial Solution
My initial preference was to allow users to take bulk page actions where they were used to working: the page tree.
Unfortunately, when I presented designs to engineers and they dug in further, they discovered that this wasn't realistically feasible. Modifying our page tree component, as it turned out, would actually take a huge amount of effort.
Our team was then faced with the reality of building software: we'd have to sacrifice our best option for the next best thing. Fortunately, we had options.
For the initial solution, I created a prototype to illustrate how the page tree might expand into an editable mode
Final Solution
Since we couldn't modify the existing page tree, we decided to create a focus state where users could archive their pages in bulk. Users could get here from a button directly above the page tree, meaning easy access to this powerful organization tool.
The focus state provided a flexible solution that could port to a new part of product in the future
I had to consider selection states for multiple scenarios
Future Improvements
During this process I noticed that bulk archiving could be bundled with other potential bulk actions like moving and labeling, and that there was significant overlap with a few existing tools (like a hidden "reorder pages" tab).
With my triad, I pitched to the Confluence leadership team our vision for a unified page management tool that would not only improve the user experience, but also remove tech debt (and design debt!) that had been laying around for years. The pitch went well and I'm happy to say these changes are now on Confluence's roadmap.
A future state integrated archiving with other bulk actions
Impact
When it comes to measuring our success, here's some of what we heard after the initial phase (for single page archiving).
Positive Reception to Core Functionality
I love that I can archive pages without deleting them!
Comparative Engagement
Users archived pages far more than they deleted them – a great indication of success for our project
Ratings Feedback
In our optional feedback survey, we had users rate the archiving feature using a series of emojis – and an optional comment.
Many feedback comments confirmed what we expected for this phase: that users were missing two main features in nested archiving and bulk archiving.
Please please please give the option to archive all nested pages too!
Must have a bulk archive feature. This is insanity archiving a large space one page at a time.
While no one wants to see less-than-ideal ratings, this feedback was no surprise to us. It actually validated what we had learned from research, and we expect to see the ratings improve as we roll out the expanded functionality in successive phases.
What's next?
Updates
This feature was shipped to the public in October 2020: Introducing page and bulk archiving in Confluence Cloud
Confluence Support documentation: Archive Pages
Andrew Nelson ©2023
Built with love in Framer