Screenshot of two permission groups from Addepar's Permissions page

One of our content strategy goals in H2 2019 was to simplify the Settings page in Addepar's web app. The Settings page had stayed stagnant for years, becoming more and more bloated with each new product feature. The page that got the brunt of it was the Permissions page.

To most Addepar users, the Permissions page was a necessary evil. Firm administrators rarely wanted every Addepar user on their team to have the same permissions, and they often wanted to restrict the highest-level permissions to themselves.

Screenshot of old Analysis and Transactions permissions

But additional permissions had to be added for each additional feature, and as time went on, these permissions not only became numerous, but confusing as well.

For example, what did "Full permission" mean for Analysis versus Transactions? And would it be difficult for users to skim through permissions if "Firm views" and "Portal views" appeared in multiple permissions?

Screenshot of old Reports permissions.

Problems popped up for each product the Permissions page featured. In Reports permissions, it was unclear if a user with "Manage team section templates" permission could manage all team section templates, or just their own team's. And once again, "full permission," whatever that meant, reared its nondescript head.

As the product content strategist on the Permissions rewrite project, I was responsible for researching and rewriting each permission. I also updated our help documentation for the Permissions page, and handled in-app communication for the changes.

Product Goals

Timeline: 12 weeks

My goal was to create permissions that were easy to understand and implement without needing to refer to help documentation. 

Until the Permissions rewrite project, firm administrators relied on an "All Available Permissions" document to understand what each permission did. Firm administrators would have to open this document in a new tab, and constantly refer back to it while changing each permission for each user.

User testing conducted early in the project confirmed that while some firm administrators had memorized what each permission governed, most hadn't, and would welcome more specificity to each permission.

Screenshot of the "Available Permissions" reference page on the Addepar help site.

Key Considerations

Reducing confusion without reducing efficacy. Due to not keeping up with a decade's worth of new features and products, the Permissions page was bloated with unclear text and inconsistent design patterns. However, long-time Addepar users had developed roles with these permissions in mind. I wanted to create a Permissions page that would retain its granular permissions for veteran users, without retaining its confusing text for others.

Resisting the urge to consolidate permissions. Early on, several permissions seemed like they could be bundled together into a single, clean permission. This certainly would have made the Permissions page much shorter and easier to parse. However, due to the sensitive nature of permissions and the strong feelings of firm administrators when it came to roles and permissions, we had to keep the function, if not the form, of each permission.

Writing with the right expectations. I understood that the engineering team did not consider the Permissions page a priority. Addepar was a start-up with a small team, after all, and I knew I had to pick my battles. When I performed user research, I made sure to understand the priorities of each firm administrator. With those priorities, I zoned in on three permissions I wanted to revamp for this project: Analysis, Transactions, and Reports.

Approach

Despite having been at Addepar for 8 months at the start of the Permissions revamp project, I still wasn't familiar with each permission. Before starting user research, I made sure to meet with four technical account managers, a product manager, and a senior engineer to understand each permission.

This came with the side bonus (slash eyebrow-raising revelation) of realizing certain permissions actually did more than they did, because engineers would sometimes tie new features' permissions to existing ones, rather than create a new permissions section. I earmarked these permissions for special focus in my rewrites, and updated help site documentation to message this change to both internal and external users.

I then made a simple spreadsheet with three columns to track each permission's current name, its functionality, and a potential new name. I created a first draft for each permission, partnered with a designer to create mocks in Figma, and worked with a technical account manager to find clients who would be willing to participate in user research sessions.

Part of a Google Sheet I created to document current permission functionality, as well as my first pass at new permission names.

User Testing

My first pass at the permission labels was strictly functional: I hypothesized that users might want as much information as possible for something as sensitive as permissions. However, being so functional proved to be harder to understand during user testing.

For example, users had trouble reading three different permission labels that began with "Create, edit, and delete," as I had written in my first pass of Reports permissions, and found it hard to skim to the permissions they wanted to fix.

(The designer I partnered with expressed her concern, as well—three rows of "Create, edit, and delete" wasn't exactly aesthetically pleasing.)

This round of research necessitated a compromise in philosophy. If I didn't state the permission functionality in full, Addepar would risk user confusion. But if I was explicit as possible, the new permissions could cause the very textual overload the project was meant to avoid.

After more whiteboarding, spreadsheeting, and plenty of user interviews, I landed on a standardized naming convention for the three permission groups I was working on. They weren't quite as explicit as my first pass, but they were more readable, while still explaining more than the current permission text. Moreover, the new permission labels were based on the actual language users used to discuss these features and permissions.

The new Reports permissions, including a toggle for parity with Analysis and Transactions permissions, clearer permissions based on user language, and no more pesky "full permission" radio button.

Thankfully, I was also working on a revamp of the Reports tool at the same time, and was able to scope the Permissions page rewrite as part of the revamp. In fact, the Permissions page was the first of the Settings pages to be rewritten, and launched in July 2019.

Takeaways

Don't overlook settings pages. Product teams may sometimes consider the Settings page of a product a "set it and forget it" page, but they're often the first pages new users visit to curate their product experience. A bloated settings page discourages users from using the product until they learn more about it, and reduces engagement for features that have to be enabled first.

Write with users, not at them. Instead of making assumptions about user language, let language be a part of your user research. Ask them questions specifically about how they would describe a particular action or need, and collate the responses to find common terms. Consider using these terms when writing for a feature.

Copy can serve as a stopgap for engineering limitations. Some permissions, I learned, only existed because engineering had no bandwidth to create around them. For example, the Teams feature was slated to have its own permissions group, but because of rescoping, it was slotted into the Reports permission group. However, rewriting the copy for Teams-related permissions made the integration smoother, and made it look like a natural fit.

Designed by Andrew Hsieh © 2021-2022. All rights reserved.