“Why can’t this user do that thing?”
Focusing on creative relationship-building is not so easy if your systems aren’t working as expected. So sometimes my work involves handling very specific technical questions from my clients.
One of the more frustrating — and surprisingly common — questions goes like this:
“Hey Allen, one of my users says they can't find this feature (or open this page, or whatever). What's going on?”
And one of the more frustrating — and surprisingly common — causes is this:
Somebody — or something — has changed the permissions for this user's role.
And, somehow, nobody can remember when or why that was done.
Obviously this is a huge problem.
Changes to user permissions should be made with great care.
Otherwise, things start getting very weird, very quickly.
So what to do?
Here's the answer:
1. Document. Create clear documentation for your team that explains, in very simple human friendly language, the name and purpose of each user role, and generally what users with those rules should be able to do (or not do). Google Docs is fine for this. Just make it clear and simple, so that everyone can understand it and be on the same page.
2. Lock down. Limit, to as few as possible, the number of users who can modify user accounts and permissions. Just like you would severely limit the number of people who have a master key to all the doors in your office building.
3. Log. Implement an automated logging system that records important information about any changes to user permissions. For WordPress, I created Capabilities Logger, a simple plug-in that does this nicely. This week I'll be installing it on all of the WordPress sites joinery manages, so we can always see, retroactively, a clear record of when, how, and by whom any changes were made.
Here's the thing:
Poorly planned or unexpected changes to your user permissions can create a ton of headaches for you, your staff, and your constituents.
You can avoid that — by creating and documenting a clear plan, limiting the number of people who can make those changes, and logging all those changes in a way that alleviates the mystery later on.
That way, you can spend less time dealing with silly technical problems, and more time building relationships with your people.
All the best,
A.