Groups: Access, Permissions, and the People Behind Them

Groups are infrastructure. They’re not the kind of feature that gets people excited in a demo, but they’re what makes everything else work. When an admin assigns a pathway to a department, or restricts a piece of content to a specific cohort, or tracks completion rates by team — groups are the thing underneath all of that.

Designing the groups system for HBP Spark meant building something that had to be both simple enough for a non-technical admin to use on day one, and powerful enough to support the access control needs of large, complex organizations.

The Groups Mental Model

The first design challenge was establishing the right mental model. Groups in HBP Spark serve a few distinct purposes:

• Access: Some content is only available to members of certain groups.
• Assignment: You can assign learning content to an entire group at once.
• Reporting: You can see completion and progress data segmented by group.

These purposes overlap but they’re not identical. An admin creating a group for reporting purposes thinks about it differently than one creating it for content restriction. We needed a mental model that accommodated all of these without requiring admins to pre-decide which purpose they were creating a group for.

The answer was to make groups intentionally general: a group is a named collection of people with an optional description. What you do with that group depends on where you use it. This keeps the creation experience simple while allowing for flexible downstream use.

The Empty State: Where Most Users Start

The Groups page for a new organization is empty. No groups, no members. We put significant work into this empty state because it’s the first thing most admins see when they open the groups section.

The message we landed on: “Groups help manage access and permissions better.” This is accurate without being technical. It gives an admin enough context to know why groups exist without burdening them with the full data model.

The empty state also surfaces the “Create Group” action prominently. There’s no reason for an admin to be in this section if they’re not going to create a group — so the empty state is also a call to action.

Designing the Group Creation Flow

Creating a group requires only two things: a name and members. Description is optional. We kept it intentionally minimal because we’d learned from enterprise software research that over-fielded forms cause abandonment. Admins see a long form and mentally categorize the task as “something that will take a while.”

The “Create Group” flow opens in a panel or modal pattern rather than navigating to a new page. This choice reflects the admin’s context: they’re in the middle of managing their organization, not beginning a new task. Panel-based creation means they can complete the setup and be back in their list without a disorienting page transition.

Group Details: What an Admin Needs Once a Group Exists

The Group Details page shows the group name, description, a list of members, and actions to edit or delete the group. It’s deliberately minimal.

The “No Members in Your Group” state on a newly created group includes context: “Search your organization to add members. Groups without members won’t be visible elsewhere.” That last sentence — “won’t be visible elsewhere” — is important. It prevents the confusion of an admin creating a group, publishing a pathway for it, and then wondering why no one can see it.

Small explanatory text like this is one of the highest-value things you can include in an admin interface. It answers the question the user is about to ask before they ask it.

Delete Group: The Conversation We Had to Have

Deleting a group has downstream implications. What happens to pathways assigned to that group? What happens to access restrictions tied to it? What happens to the historical reporting data?

We made a deliberate decision: deleting a group removes it as a target for future assignments and access controls, but does not retroactively affect completed actions. Assignment history that referenced the group is preserved. Completion records for learners who were in the group are unaffected.

This decision had to be made explicit in the product documentation and communicated clearly in the delete confirmation flow. “Delete this group” with no context would leave admins uncertain about what they’re actually doing. The design includes a clear explanation of what deletion means — and what it doesn’t.

The Organizational Challenge

Groups represent one of those features where the design work is mostly invisible. When it works, an admin creates a group, adds members, and moves on. The complexity is in the edge cases, the error states, the downstream effects — all the things that should be handled gracefully so the admin never has to think about them.

That’s the goal: make the organizational complexity disappear behind a clean interface, without pretending the complexity doesn’t exist.