Assignments

The assign action is one of the most consequential things an admin does on HBP Spark. When you assign content to a person, you’re creating an obligation. You’re saying: “I expect you to engage with this, and we’re going to track whether you do.”

Designing the assignments feature meant thinking across two worlds that don’t always communicate well: the admin world of management and oversight, and the learner world of tasks and progress. The same object — an assignment — looks completely different from each side. Getting the feature right required designing both simultaneously and ensuring they connected into a coherent loop.

This post covers the full assignments system: the management view, the creation flow, the details panel, the notification logic, and the learner-side experience.

---

The Admin Assignments View: Managing Learning at Scale

The Admin Assignments view is where an organization’s learning accountability lives. It’s the place where an L&D manager can see what they’ve asked people to do, track whether they’re doing it, and intervene when they’re not. Getting this right had real business consequences — if admins couldn’t easily track assignments, assignments would stop being used, and the platform would lose one of its most powerful mechanisms for driving actual learning.

The Fundamental Tension

There’s a tension at the heart of any assignments management interface: the admin needs a complete picture and they need to be able to act quickly. These are somewhat opposing forces. A complete picture implies density — lots of data, lots of rows, lots of columns. Acting quickly implies clarity — visible priorities, obvious next steps, low cognitive overhead.

We couldn’t have both without making deliberate tradeoffs.

Deciding What “Managing Assignments” Actually Means

Before we could design the list, we needed to understand what actions admins actually take when they “manage” assignments. We broke it down:

• Creating: Starting a new assignment.
• Reviewing: Checking on the status of an existing one.
• Modifying: Changing the due date, instructions, or assignees.
• Following up: Identifying who hasn’t started or is overdue.

The design needed to support all four, but the everyday use case was reviewing and following up. Most admins create assignments infrequently compared to how often they check on them. The interface should feel fast for people in scanning mode.

Structural Simplicity as a Feature

The final design is genuinely simple: a list of assignments with just enough metadata visible to enable quick decision-making, and a clean entry point to create new ones. There’s sometimes pressure to make admin tools feel “enterprise-grade” through density and configurability. But the admins using HBP Spark are not power users in the traditional sense — they have a job to do and limited time to do it. The most respectful design is the one that gets out of their way.

Where Assignment Starts

The assign flow can be initiated from two places: from an asset detail page, and from content cards in the catalog or search results. This dual entry point reflects how admins actually work. Some assign from a specific asset they’ve been reviewing; others scan through results and assign on the fly.

We placed the assign action as an overflow menu option on content cards throughout the catalog. It doesn’t sit as a primary button because “assign” isn’t the most common action on a content card — viewing, bookmarking, and sharing are. But it needs to be findable without hunting, which the overflow menu handles appropriately.

When an admin selects “Assign” from a card’s overflow menu, the assignment modal opens over the current catalog view. The catalog stays visible behind it. When the assignment is created, the modal closes and the admin is back exactly where they were. This “modal over context” pattern preserves the browsing session and lets admins assign multiple pieces of content in sequence without losing their place.

Both entry points — the catalog card and the asset detail page — launch the same modal. A consistent assignment creation experience regardless of where it was triggered.

Status Indicators on Cards

Content cards in the assignment context show a status indicator — “Viewed,” “In Progress,” or nothing (not started). For an admin deciding what to assign, these status indicators reveal something useful: which content their team is already engaging with and which they haven’t touched.

An admin who sees that 15 members of their team have already viewed a particular article might decide to assign a more advanced follow-up instead. The status context turns browsing into informed curation.

The “From Your Organization” Badge

Content created by the organization (as opposed to HBP catalog content) is labeled with an organization badge. This distinction is important for assignment decisions: org-created content is configurable and custom, while HBP content is standardized and produced by experts.

Admins making assignment decisions benefit from knowing which is which. Not because one is better than the other, but because they’re different kinds of content with different implications for how learners will experience them.

The Assignment Modal

The assignment modal needed to accomplish several things in a constrained space: confirm which piece of content is being assigned, collect the list of assignees, capture optional context like a name, instructions, and due date, and provide a clear path to confirm and a clear path to cancel.

Asset Identity at the Top

We structured the modal with the asset identity at the top — a card preview showing the title and description of what’s being assigned. This is important because admins often have the modal open without the underlying asset visible. Showing the asset in the modal prevents confusion about what’s being assigned.

Naming the Assignment

We pre-fill the assignment name as “{Asset Title} Assignment” — a sensible default that most admins will use without modification. This reduces friction for the common case while leaving the field editable for admins who want a more specific name.

The name matters for tracking. When an admin has multiple assignments in their Assignments tab, they need to be able to distinguish them. “Revise Your Draft Assignment” is more useful than “Assignment #4.”

The Assignees Field: Groups and Individuals Together

The assignees selector is the most complex part of the modal. Admins can add both individual users and groups, and the two can be mixed in a single assignment. A group and three specific individuals can all be in the same assignee list.

The visual treatment differentiates: groups appear with a group name and a count indicator; individuals appear by name. This distinction is visible in the summary of assignees so the admin can see at a glance whether they’ve assigned to individuals, groups, or both.

One important note we surfaced in the modal: “Note: Users must have logged in once to appear in the list of possible recipients.” This is the kind of operational detail that causes enormous confusion when it’s hidden. New organizations often have a roster of users who haven’t activated their accounts yet. Those users won’t appear in the assignee selector, and without this note, admins would think the platform was broken.

Instructions: Turning an Assignment into a Directive

The instructions field is optional but powerful. It transforms a bare assignment into a contextualized directive. An admin who assigns a pathway on “Communicating for Impact” and adds instructions like “Please complete before our team offsite on June 15th — we’ll be discussing the key frameworks in our session” has done more than create a task. They’ve connected the assignment to a real moment in the learner’s work life.

We limited instructions to 300 characters — enough for a meaningful context-setting sentence or two, not enough to write a novel. The limit forces concision and keeps the instructions field from becoming a document.

Due Dates: Signaling Importance

The due date field is optional and includes a tooltip explaining what it means. Due dates have specific implications: they affect how assignments appear in learner notifications, how they sort in the assignments view, and whether they appear as overdue.

Making the due date optional was deliberate. Not all assignments are deadline-driven. A recommended reading list that an admin assigns for a team doesn’t necessarily have a specific due date — it’s more of an invitation than a mandate. Forcing a due date for every assignment would conflate these two very different assignment intentions.

The Cancel/Assign Pair

The modal closes with two clearly labeled actions: Cancel (which dismisses without saving) and Assign (which commits the assignment and triggers notifications). The placement and visual weight of these buttons shape whether people feel confident or hesitant at the final moment.

We made Assign the primary (filled, prominent) button and Cancel a secondary text link. This reflects the assumed intent: someone who opened the assignment modal almost certainly wants to assign something. The secondary Cancel path is available for the case where they’ve changed their mind, but it shouldn’t compete visually with the primary action.

---

The Assignment Details Panel: Complexity in a Drawer

The assignment details panel was one of those features that looked simple on the surface and turned out to be a small design universe once you got inside it. The core function — let an admin see the specifics of an assignment they’ve created — seemed straightforward. The challenge was that “the specifics” turned out to include a surprising number of dimensions.

The Drawer as Container

We chose a drawer (a panel that slides in from the right) rather than a full page for assignment details. The reasoning was practical: admins often want to review assignment details while keeping the list of all assignments visible. A full-page navigation would take them away from the context they’re operating in. A drawer lets them inspect without losing their place.

The drawer pattern also solved the “back button” problem. Admin users in enterprise software often open multiple details in quick succession. If each detail view is a new page, they’re hitting back repeatedly and losing scroll position in the list. With a drawer, close is always close — the list underneath never changes.

What Information Actually Belongs Here

Before touching Figma, I mapped out every data point that could plausibly live on an assignment details view: the asset being assigned, who created the assignment, when it was created, when it was last modified, who the assignees are, any instructions, the due date, the current completion status of each assignee, and a preview of the content itself.

That’s a lot. And most of it is sometimes relevant, not always relevant. An admin reviewing a newly created assignment cares mostly about the assignees and due date. An admin checking in a week later cares mostly about completion status. An admin who inherited someone else’s assignments cares about who created it and when.

This pushed us toward a progressive disclosure model — show the essential metadata prominently, surface the rest on demand.

The Assignees Section

How you display assignees turns out to be a genuinely hard design problem. An assignment might have one assignee, or it might have three hundred through group membership. Showing all three hundred names in the details panel would be useless. Showing just the count would feel opaque.

We landed on showing the first few assignees by name with a “More assignees” expandable link that reveals the full list. This gave admins an immediate sense of who was involved while not overwhelming them with a scroll of names they’d never need to see all at once.

One thing I pushed for: showing group names when assignments were made to groups, not just the expanded list of individuals. An admin who assigned a pathway to “Cohort January 2025” wants to see “Cohort January 2025” in the assignees section — not a list of seventy names that no longer maps to how they think about that assignment.

The Preview Integration

Adding a content preview directly in the assignment details was a late addition, and a good one. Admins who manage large catalogs sometimes lose track of exactly what’s in a piece of content they assigned months ago. Being able to see the actual asset — its title, a description, a link to view the full content — without leaving the assignment details panel meant one fewer detour.

We included an explicit “view full content” link rather than trying to embed the content itself. Embedding felt like solving the wrong problem — the admin needs to remember what something is, not consume it in full inside a management panel.

Close vs. Cancel: A Small but Important Distinction

The panel has a close action and a save action. At first glance this seems obvious — close dismisses, save commits. But we went through several iterations of the question: should closing the panel auto-save changes?

We decided no. Auto-save in an admin context is risky. If an admin accidentally edits the due date and then closes the panel, they don’t want that change committed silently. Explicit save keeps the admin in control of when changes become real. The tradeoff is that we had to be clear about unsaved state — we added a visual indicator when there were pending changes and a confirmation prompt if the admin tried to close without saving.

These friction points feel small in isolation. Over hundreds of interactions, they’re what separates a tool admins trust from one they’re afraid to use.

---

Notification Logic: The Rules Behind the Button

Notification design is one of those areas where the UI is almost secondary to the logic. The button that says “Assign” is simple. The rules engine that determines what happens after you click it — who gets notified, when, about what, and under what conditions — is where the real design work lives.

Getting it wrong would create one of two equally bad outcomes: users drowning in irrelevant notifications, or users missing notifications about things that actually matter to them.

The Core Decision Tree

The notification logic for assignments centers on a few key conditions:

When a new assignment is created:

• If the assignment is to a group, the system checks each individual user in that group.
• If the assignment is to an individual user, the system checks that user directly.
• For each user: if the item being assigned is already completed by that user, no notification is sent (and the assignment is automatically marked complete).
• If the item is in progress or not started, the user receives an in-app notification.

When an assignment is modified:

• The same group-to-individual expansion logic applies.
• If a user has already completed the item, no notification is sent.
• If the item is in progress or not started, both the user and the original admin who created the assignment receive a notification.

That last detail — notifying the original admin on modifications — required explicit design attention. If admin A creates an assignment and admin B modifies it, admin A should know. Assignments are commitments to learners. Changes to them affect the admin’s relationship with their team.

Why “Already Completed” is a Special Case

Designing the “already completed” case carefully was important for respect and relevance. If someone has already done the thing you’re assigning them, sending them a notification saying “you’ve been assigned this” is noise at best and insulting at worst. It implies you don’t know they did the work.

More concretely: auto-marking an assignment as complete when the item is already done prevents a false backlog. An admin reviewing completion rates doesn’t want to see “50 people haven’t completed this” when in reality 30 of them completed it last quarter through a different mechanism.

The Group Expansion Problem

One complexity in notification design is the “group-to-individual expansion” problem. When an admin assigns something to a group, they’re thinking in terms of the group. But notifications are sent to individuals. The transition from “assign to Cohort January 2025” to “send notification to James, Jamil, Jameson, and 47 others” has to happen somewhere in the logic.

Mapping this explicitly forced a conversation about timing: does the expansion happen immediately? What if the group membership changes after the assignment is created? What if someone is added to a group after the assignment was made?

These aren’t just technical questions — they have user experience answers. We decided that group assignments are expanded at the time of assignment creation, not dynamically updated as group membership changes. This is the simpler model and avoids the strange experience of a user receiving a notification about an assignment that was made three months ago because they were just added to the group.

In-App vs. Email Notifications

The notification logic specifies in-app notifications — the bell icon menu in global navigation. Email notifications were a separate consideration that required additional rules about user preferences and organization-level settings. For V1, we focused on getting the in-app logic right and treated email as a separate layer on top.

This kind of scope decision is important to document explicitly. “Notifications” means different things to different stakeholders. Being clear that this flow covers in-app notifications only prevents the assumption that email is automatically handled.

---

What Happens After: The Learner’s Side

The assignment flow doesn’t end when the admin clicks “Assign.” From the learner’s perspective, that’s when it begins.

A notification arrives. The assignment appears in their profile under Assignments. A due date (if set) surfaces in their task view. The content card — wherever they encounter it next in the catalog — shows their assignment status.

Designing this post-assignment experience meant coordinating across the notification system, the user profile, and the in-platform alerts — ensuring consistency in how the assignment appears and is tracked across all these surfaces.

The admin closes the modal feeling like they’ve done something. The learner receives a clear, actionable signal. The system maintains the record. That three-part coordination is what makes the assignment experience work as a complete loop rather than just a database entry.

---

What This Feature Taught Me About Admin-Facing Design

The assignments system is a good example of a feature where most of the design work isn’t visible in the final interface. The drawer vs. full-page decision, the notification decision tree, the group expansion timing, the auto-save question — none of these show up as prominent design elements. They live in behavior, logic, and the absence of problems users never notice.

Admin-facing design at scale isn’t about making things look impressive. It’s about making tools that hundreds of people can use confidently, daily, without thinking about the interface. The best compliment an admin can pay a management tool is not noticing it at all — because it’s doing exactly what they expect, every time.