Granularity sounds like a good thing. More options, fewer restrictions, the more I can do the better. However, from a user experience perspective, granularity typically does more damage than good.

Let’s take a look at a few case studies to demonstrate how granularity can go wrong (with some possible alternatives).

Social Media App:

Goal:

The user wants to control who sees their posted content.

Granularity’s Solution:

Force the user to choose each person in their friend’s list one-by-one before publishing their post. That will give them the reassurance they need to make sure the content they publish will be seen only by intended viewers.

Problem:

Scalability: The first problem with this solution is that it does not scale very well. If the user has 10, 100, or 1000+ connections, sifting through contacts is a time-consuming process that the user will not likely want to do more than once.

Cognitive Load: The second problem is the amount of cognitive load that the user has to burden to understand the variations of visibility from one post to the next. User A can see posts 1, 2, 3 and 5. User B can see posts 2, 3, and 4. User C can see posts 1, 3, and 10… and so on. Depending on the app, this cognitive load can manifest itself in the form of fear, apprehension, anxiety, and ultimately, a significant increase in abandonment.

Alternate Solutions:

Subtractive Model: Instead of a additive model where you choose each person who can see the post one by one (starting from zero), simply default to an “everyone, except” model (like Facebook), and only choose people who cannot see your post.

Group/Tagging Model: Another way that you can restrict visibility is to assign your contacts to groups, or tag them based on a theme— and then simply choose whether or not the group can view the content.

Share with Purpose: You can also make the audience deliberate recipients of your content. For example, instead of thinking of the visibility of your post as the consequence of posting it, re-shape the narrative to “Share with a Group”. This model has two primary benefits. First, it stimulates activity with content creators due to having an audience carefully curated to suit the content type. Second, it results in a higher content quality ratio due to the fact that the creator is creating content…with a purpose. For example, I’m more likely to create and share family-related content with a group called “Family” than I am creating content for a community of people who are not thematically related.

Sales Team Management App:

Goal:

Admins should be able to customize the permissions of each salesman in the app.

Granularity’s Solution

Allow the admin to create new roles, and customize the CRUD permissions for each role. Force the admin to complete a step during the invite process where they can assign or withhold CRUD permissions before sending the invite. Allow the admin to override the settings of a role by going back and editing a user’s permissions after they’ve already been assigned a role and added to the system.

Problem:

New Admins: What happens if the original admin leaves their position, and is replaced with someone who has no knowledge or context regarding the roles that were created? Often times, admins will create roles that they personally identify with, based on the use case or persona that it was created to represent. For example, the previous Admin created roles for Special Admins, Client Admins, Customer Admins, Partner Admins, Midwest Team Members, and Assistants to the Regional Manager. While the new admin may be able to gleam some insight into what those roles represent, they’re likely to have absolutely no comprehension of the specific permissions tied to each role. Typically, this results in admins creating new roles to compensate for that issue.

Trial & Error: When becoming accustomed with new software and/or systems concepts, there is typically a strong amount of “experimentation”. Typically, the user will start off by creating a handful of roles, assigning those roles, and later realizing they want to make an adjustment. More often than not, the admin will then create new roles and abandon the old ones — cluttering the experience and increasing the likelihood of user error.

Cognitive Overload: For an admin that had 100 users, 10 permissions, and 2 other assignable instances (schedules, prospects), there are over 2000 possible permutations between each user. Not only is it humanly impossible to mentally process those variations, it results in, you guessed it, the admin creating more roles.

Takes Too Long: There’s no greater deterrent of repetitive actions in an app than tasks simply taking too long to complete. First, you have to gather the user’s name, their email, phone number, address, and so on. Then, you have to choose from a variety of permissions and other settings. By the time it’s all over, the admin will be grateful they’re done (and likely to never use the feature again).

Scope Creep: I’ve been on several projects where the answer to a problem is not to actually fix the problem, but to tack on more screens, video, illustrations, and visual clutter to “make sure the user gets it.” I prefer to default to the popular quote:

“UX is like a joke. If you have to explain it, it isn’t that good.”

Instead of adding more content to make your story louder — re-shape the assets you have in a more intuitive way to tell that story better.

Role Defiance: The reason that systems have roles to begin with is that they are simple and recognizable terms that immediately communicate precisely what level of control or permissions the user has. Defying those roles post-assignment undermines their value, and diminishes the admin’s trust in the system. Depending on the system, it can also lead to security risks, a reduction in user on-boarding, and liability of the user or company using the application.

Final Thoughts:

No matter which angle you come at it from, granularity is rarely the solution. Sure, it may be easy to conjure edge-case examples where it sounds like a solid plan. It may even sound like innovation in an industry where everyone else is restrictive and roles based. Stop over-thinking things.

Develop clear personas based on research and user testing. Create clear roles that speak to the specific segments of your target user-base. Use card-sorting techniques to find out what users truly care about and how they would group things together based on their needs. Identify outliers and consider the risk/reward factor. Sometimes there are permissions and variables that, even after testing and grouping with roles, still seem like a good idea to make available to everyone. The first question I ask is always “Who is this good for, the end user or the business?” Will we get more customers who buy the app because marketing did a rock-star job at promoting granularity as a feature? Or, will it lead to abandonment, lack of use, security/privacy issues, or even liability. Innovation is rarely taking something that works and breaking it down to make it harder — and you should never compromise the user’s best interests simply because it benefits the business.

Michael Sim

Website | LinkedIn | Twitter | Behance