Sharing in ShareFile

00

Overview


I was a product designer on this project for Citrix from 2021 - 2023.

We made it 3.5 times faster to share files, reduced the costs of generating and maintaining links by at least 50%, and strengthened ShareFile's security posture.

01

Context


More than 40 billion files are shared every year in ShareFile.

ShareFile is a B2B SaaS file sync and share solution that service providers (like lawyers, accountants, and financial advisors) use to collect and store client documents. It caters to both enterprise and SMB customers and has 3 million monthly active users.

At the time of this project, ShareFile was owned by Citrix, and its file sharing functionality was also used in Citrix Workspace (a secure access digital work solution). Each product had its own web, desktop, and mobile application.

This project started as part of a larger effort to improve our document collaboration abilities.

02

Discover


  We conducted a competitive analysis  
I looked at other file sharing applications — Google Drive, Box, Dropbox, OneDrive. How were they enabling collaboration? What were they doing well? Where were they falling short, and what could we do better?

  We combed through NPS verbatims  
I studied Net Promoter Score verbatims to see if there were any common sentiments about document collaboration. First, I took stock of detractors to see what bothered our customers most. I then looked at promoters to make sure we knew what they appreciated, so that when we went to add value, we didn’t accidentally take any away.

  We assessed our technical limitations  
ShareFile was a 16 year old application with plenty of tech debt. We met with a team of engineers and engineering directors to understand the technical constraints that we needed to keep in mind. We also used this as an opportunity to ask our engineers if they saw any opportunities to improve share from a technical perspective.

03

Define


When it came time to hone in on a minimum marketable feature, the choice was easy: Sharing is the core of ShareFile. It’s the most frequent user action and the first action taken in over 90% of trials. It’s even right there in the name. 

During our discovery phase, we uncovered some fundamental problems with sharing.

  The experience was disjointed  
There were two ways to share a file: you could either Get a link or Email with Citrix. At no point in the content viewer experience or in either flow did users see the word “share,” despite that being the common nomenclature in 100% of the products we analyzed. These were also entirely separate actions, despite their close similarities.

  The flow was inefficient (and expensive)  
Users inadvertently created a new link every time they went to share a file. Rather than giving them the option to reuse a link, we generated a brand new one every time they clicked share. In many cases, users would create two links every time they went to make one: the first that generated as soon as they opened the page with their default permissions, and then a second with the permissions that they actually wanted to assign.

If a user went to get a link 10 times and only 5 of those use their default settings, they’d have created 15 links when they might have only needed 2.  With more than 40 billion files shared a year, that becomes expensive to maintain.

Additionally, we knew from NPS verbatims that some of our users had security concerns regarding the number of unused links floating around.

The old get a link experience in Citrix Workspace

  We had a navigation gap  
Users didn’t have a straightforward way of navigating to files that had been shared with them from within the application. If someone shared the folder containing the file with you, you’d be able to navigate to it, but otherwise you were stuck digging the link out of your chat history or email inbox.

Shared folders don't provide access to individual files

04

Develop


  First, we ideated  
The team brainstormed potential blue-sky solutions and came back together to share low-fidelity wireframes. We tried to go beyond merely correcting the problems with share—we looked at this as an opportunity to improve the experience to a degree that we surpassed our competitors.

  Next, we built and tested a prototype  
We started by identifying our goals and outlining the research questions we wanted to answer. I then took those questions, created a task-based testing script around them, and built a prototype in Figma. For this first round of testing, I chose to use a low-fidelity component library so that our participants would focus their feedback on the experience rather than the UI.

After recruiting participants from Respondent, I ran and moderated usability tests. I made sure that the engineers on our project were invited to each research session so they had the opportunity to provide their own observations.

When we finished testing, I collated insights and created a top-line readout that I presented to project leadership. The readout covered the prototype’s SUS score, NPS, learnability score, task success rate, and a summary of our findings from each task. It also outlined our next steps.

  Finally, we iterated  
We took our learnings from the first round of testing, reworked our designs, and built a high-fidelity prototype. We then conducted another round of testing using the same tasks to ensure we were moving in the right direction.

05

Deliver


Our final solution addressed the three problems we had uncovered:

  We unified the experience  
We decided to merge the separate Get a link and Email with Citrix actions to make one cohesive sharing experience called Share. We knew from user data that the vast majority of shares were from Get a link, so we put that at the forefront and made email a secondary action.

The only exception to this was when users went to share multiple files at once. We couldn’t use reusable links with bundled files, so when a user went to Share with multiple files selected, we asked them to choose if they wanted to Get a link or Send to specific people (more on that wording in just a moment).

  We streamlined the flow  
We introduced reusable links to help our users accomplish their goals faster, reduce friction, and mitigate the costs associated with link generation. Users could now see and manage all of the links to their files in one place. To improve confidence in our security posture even further, we made it an active choice for a user to generate a reusable link.

  We closed the navigation gap  
To address the issue of users being unable to find files that had been shared with them without leaving the application, we proposed two changes:

Firstly, change Email with Citrix to Add someone to this file. Make this an action that gives another user persistent permissions on a file rather than just another way to send a link.

Change Shared folders to Shared with me. Make this a home for both files and folders.

While this was a simple change from a design perspective, it had pretty serious engineering implications. We learned that both sharing methods were dressed up versions of Get a link—ShareFile had no framework for file-level user permissions, and architecting one would take time.

As a stopgap, we changed our language to Send to specific people. We chose this language to introduce the idea that you’d choose this option based on who you want to share with rather than how you planned to share it.

A gif showing the creation of a reusable link

06

Outcomes


  We made it 3.5 times faster for users to share files  
Before this project, users had to configure nine different settings if they wanted to share a file with non-default permissions. We reduced this burden significantly by introducing reusable links.

  We reduced the costs of generating and maintaining links by more than 50%  
Reusable links were obviously a huge factor, but we saw major improvements just from no longer generating a new link every time the user went to share a file.

  We strengthened ShareFile's security posture  
In addition to making it easier for users to keep track of links (and helping them create fewer links in the first place), this project was a springboard for additional security enhancements:

• We strengthened our default sharing permissions.

• We heightened user awareness around sharing anonymous files.

• We started warning users before they shared files with sensitive data, and we enabled them to easily improve their security settings without sacrificing convenience.