When we launched organizations, we stole a page from Github's playbook and went with a team model that would allow you to organize people into groups, and then grant access to projects through those groups.
After watching users struggle to make that model work, we feel it's time to revisit that model and hopefully design something far easier to work with.
In this post we'll review some of the issues we're seeing with the current model and lay out an alternative that we believe is much easier to work with. We'd love your feedback on whether you agree, or (even more important) if the proposed changes are going to be disastrous for how you currently manage projects within your organization.
The current model
To summarize the headaches we see most users run into, consider the following scenario:
- I create an organization account and start three new projects within that organization. Since I'm an owner of the org, I automatically have access to each project. Simple!
- I now want to invite someone to collaborate. I only want that person to have access to one of those projects. In this case I need to add that person to my organization as a guest, create a new team, assign that team permissions to edit the specific project, and finally add that person to the team. Not so simple...
Teams definitely have a place, especially across large organizations or efforts that have relatively stable teams, which each require different access to projects. But we just haven't seen many people needing to use Kumu in this way. The additional power ends up being a burden instead.
A simpler way?
We've brainstormed a number of approaches to simplifying how collaborators are managed for organization projects. One change we definitely want to make is the ability to invite a person directly to a project (from within the project itself, just like in personal projects). This solves the simple case where you have a person that may only need access to a single project, or you're dealing with few enough projects that adding each person to each project one-by-one isn't an undue burden.
Once we started moving in this direction, we had an idea. What if we got rid of teams altogether? What if adding someone to an organization meant that they had access to every project under that organization, and their editing rights were based on whether they were added to the organization as observers, contributors, or admins (view, edit, or admin rights, respectively)?
The scenario we walked through above becomes much simpler:
- I create an organization account and start three new projects within that organization. Since I'm an owner of the org, I automatically have access to each project. Simple!
- I now want to invite someone to collaborate. I only want that person to have access to one of those projects. I simply add them as a collaborator via the project settings menu. Simple!
- I get an email from my CEO requesting view access to every project. I simply add the CEO as an observer of the organization. Simple!
In our view this solution provides the best of both worlds. You continue to have an easy way to grant certain people automatic access to every project that ever gets created within your organization (with either view, edit or admin rights). Plus you can grant direct access to specific projects by inviting someone to a project via the project settings menu (with the choice of whether that person should have view, edit or admin rights for that project).
So, what do you think? Will removing teams ruin your life, or make it better?