Managing People and Permissions

Whether we’re looking at multinational companies or a smaller production houses, businesses share several needs around permissions. They need to define access to content, manage different types of users—and business structure— around that content, and seamlessly orchestrate what their users can see and do in their system while making sure secure content stays locked down. On top of that, businesses are constantly evolving; the way they manage permissions needs to be flexible for these shifts and allow them to respond and scale accordingly.

We undertook this effort to rehaul our permissions model to make it seamless for enterprise businesses to manage people and access to content.

Like many fledgling companies do in their early days, focus is too narrowly placed on the problems in front of them without considering the broader longterm implications of the decisions they make today. Our existing permissions model definitely fit that buck. While we were able to support it for several years, we began to see scale and visibility issues particularly for larger businesses supporting 10-20 departments with hundreds of users.

These are their problems (* dun dun *):

• Admins have to manage access and permissions for entire organizational structures at a single level of hierarchy and have no way to delegate management responsibilities
• Trying to track down all the pieces that affect what a user can see and do is a bit like tracing the breadcrumbs that Hansel and Gretel left for themselves to get home: you get lost in the forest and almost get eaten by the Permissions Witch
• Because we don’t have granular enough permissions to restrict or grant access to a single piece of content, admins have to shard existing permissions structures to get things done. When you combine this with the problems around delegation, a single level of hierarchy, and visibility equivalent to driving in the thickest of fogs, it is a recipe for at best—frustration — and at worst — sensitive content falling into the wrong hands.
• Users feel incredibly uneasy touching permissions in any way and when they do they have little to no trust that it will result in what they needed

*

• Helped align and guide business, product, and engineering strategy around the Permissions overhaul effort with CoSTAR, Business Model Canvas, and Gherkin models
• Led and conducted intensive research efforts with companies of varying size and industry to understand the core problems we needed to tackle first
• Interpreted data and aggregated insights from interviews, surveys, usability tests, and relevant data from clients systems
• Led the breakout of strategic, mid-term, and tactical options (wireframes, prototypes) to guide and roadmap positive, incremental, and attainable changes to our product.

Version 1




Version 2




Crafted a comprehensive research report synthesizing 3 short and long term options to address the core issues we identified
We not only identified these problems across 8 key market segment clients, we synthesized the research and used it to guide our wire-framing, prototyping, and roadmap efforts. These are primarily centered around creating hierarchical and relational groups and teams to manage people and content, improved information architecture with the addition of a checked comparison list of permissions, and bringing the ability to apply permissions on individual assets and metadata fields.

Implemented the ability to create hierarchical and relational groups and teams
Currently, roles and permissions for users are managed at a single level with no way to organize their business and work structure in a way that makes sens to their existing processes . We added in the ability to create hierarchical structures to mimic how they organize people and permissions article at a single level first. We also outlined opportunities to integrate with third party organization builders to allow businesses to create infinite layers between their organization, people, and content.

Improved visibility into all permissions on users and fixed issues in information architecture
Our permissions structure allowed admins to create high level properties that users inherit based on their roles and categories. But these properties lived on 4 different pages and was a mess to keep track of what was affecting what a user can see and do. Not to mention, admins had no visibilty into these properties at the user level and had to interpret the properties set on multiple roles and trace them back to the user.

We fixed these visibilty problems to surface these properties at the user leve, while also making sure dots were connected on any other pages relating to permissions aspects.

- Version 1

- Version 2

Ability to manage permissions directly on assets and fields
Admins need to set general rules for content access but need to create exceptions to those rules. A great example of this is how Google Drive works: you set permissions on areas and then can share content directly with specific users. We brought this concept into our app allowing users to see who has access to any given piece of content on the content itself and the ability to create the exception right then and there.

Our users previously had to shard existing permissions in order to create a one off scenario to share content access that balloned the number of roles, categories, and permission properties admins then had to manage. Now, users can now create exceptions to their high level rules without seeing scale issues in their permissions model.

Next Project

.