Making permissions clear
While working on InVision’s Design System Manager project, we received feedback that users were confused by project link-sharing capabilities.
Originally, the project manager asked that I clarify how this feature worked in the documentation. While I appreciate good docs, making a product so intuitive that doesn’t need instructions is even better.
I set out to do some quick research on why users were getting confused. I partnered with our support team, and analyzed all support tickets related to this particular sharing feature. This was pretty simple, because each ticket was tagged with a specific topic. I could then filter tickets according to tags.
After analyzing the tickets, I realized the confusion rested in the naming of the last sharing option, “Anyone with the link.”
To users, this language implied that they could share the library without having to add the entire org or invite people directly. But they still expected password protection for some level of gatekeeping.
A similar scenario would be setting up your portfolio for a job hunt. You want any recruiter or manager with the password to see it, but you don’t want everyone on the internet to see it. So you make a site and password protect it, giving out the password to those you want to have access.
That’s not what this last option, “Anyone with the link” was. This was truly allowing anyone to access your library. It was totally public.
I proposed a few simple copy edits:
Rename the setting to “Public” and changing the description so it was clear this could not be gated at all.
Update the password-protected link description to further emphasize this feature wasn’t available for public libraries.
Also, let’s say you selected one of the other two options. The description used under the available password-protected link option originally read:
“People outside of your org will need to enter a password.”
This is true. But it didn’t explicitly state that enabling this option gave them access.
So, I changed it to more directly address the question users were really asking—how can I share this with a broader audience, but still have it password-protected?
The updated copy clarified that when this feature is enabled, “Anyone with the password can view this link.” It also clarified that members of the org wouldn’t need the password. And if you chose to invite individuals, the copy would provide a similar explanation.
After we shipped these changes, I revisited support tickets to see what kind of impact, if any, the changes had.
We saw a 100% reduction in support tickets. Meaning, no new tickets were coming in related to this issue. Those small copy changes completely eliminated the need for additional documentation.
To calculate time savings for customers, you can estimate that an average customer spent an hour dealing with this: 20-30 minutes on their own, and another 30 minutes with an agent (average email ticket time).
We were also able to save agents 2.5 hours/week troubleshooting this issue, resulting in 130 hours/year to dedicate to other work.