Case 01 · Holaspirit · Product design · UX/UI · Project management

When work crosses teams, someone still has to know who owns it.

Holaspirit runs on circles and roles a governance model where every task has a clear owner. Opening projects to collaboration across circles broke that clarity. This is the assignment system that let teams work across boundaries without losing track of who does what.

Role: Product Designer: research through UI
Product: Holaspirit · enterprise scale
Scope: Assignment system, cross-module
Status: Shipped

Context

One team, one circle until projects needed more.

In Holaspirit, people work inside circles (the Marketing team, the Sales team, ect...) and hold specific roles within them. It's a governance model built for clarity: every responsibility has a named owner.

To let teams collaborate more freely, project boards were opened up. Anyone could now join a project run by another circle. A Marketing member contributing to a Sales-led project, for example. The flexibility was the point, but it also broke what made circles work: knowing exactly who was responsible for what.

Diagram: a task pulling roles and members from both the Marketing and Sales circles.

Before, a project drew from a single circle. After, it pulls roles and members from any circle. A powerful feature, but ownership stops being obvious.

The problem

Cross-team work blurred the one thing circles were built to keep clear: ownership.

The moment a project extended across circles, coordination started to leak in four predictable ways.

Who owns this?

With several circles on one project, it stopped being obvious who owned which task.

Hard to see how it fit together

Roles, circles, and members were mixed together, so their relationships inside a project were unclear.

Locked to one circle

The system tied every assignment to a single circle, blocking the cross-team workflows people now needed.

The same task, twice

Without visibility across teams, the same work got picked up by two people.

On top of that, even a single assignment took multiple steps and context switches so the flow itself was slow before cross-circle work ever complicated it.

What the system demanded

The platform set hard limits. Each decision answers one.

This is an enterprise governance software. The design could not bend the rules to feel nicer. Every decision here is a direct answer to a constraint.

Constraint 01

Governance cannot be broken

Cross-circle assignments could never override role permissions or the structural logic underneath them.

Decision

The assignment model, always inside the rules

A single interface that stays true to governance while bending for cross-team work.

Trade-off: more interface complexity, in exchange for structural integrity.

Constraint 02

Must scale to hundreds of roles

Large organizations have hundreds of users and roles. The interface must stay manageable at that scale.

Decision

Progressive filtering, like a funnel

Choose a circle → the roles → the members. It narrows automatically, cutting the list down before it can overwhelm.

Trade-off: more clicks to choose the member, but far easier to find.

Constraint 03

Consistent across every module

Assignment shows up in meetings, metrics, and other governance modules. It had to feel like one system.

Decision

One reusable assignment pattern

The same logic and interaction, wherever assignment appears. Not just for projects.

Trade-off: less freedom per module, far more coherence overall.

Constraint 04

Three layers at once = visual noise

Showing circles, roles and members together risked overwhelming the interface.

Decision

Hierarchy revealed on demand

Hover states and compact modals show the relationship only when it's needed.

Trade-off: structure is one interaction away, not always on screen.

Three ways to assign

Three attempts to make assigning feel like one action.

The hard part was not showing the data. It was making assignment feel like a single, obvious act while three layers of structure sat underneath. I tested three directions.

Assignee rows

Rejected

Each "added assignee" created a row: pick a circle, choose a role, then select members. It filtered like a funnel, with a confirm step before saving, and laid the structure out visually.

Wireframe of the assignee-rows direction: one row per assignee with circle, role and a members dropdown.

Wireframe: assigning by circle → role → members, one row at a time.

What improved

Easy to see everyone on a task at a glance
Any row deleted in one click

What fell short

Too much clicking to assign one person
A confirm button that added a step for nothing
Two assign buttons crammed into a tight space

Dropdown by context

Rejected

Clicking + Assignee opened a dropdown to choose the context: circle, role, or member. Choosing one opened a second dropdown with a search bar to type or scroll to the exact role.

Wireframe of the dropdown-by-context direction: choose a context, then search the exact role.

Wireframe: pick a context, then search the exact role.

What improved

A clear step-by-step that reduced ambiguity
Role search that held up for large orgs
Roles tied to their circle, so responsibility was understandable

What fell short

Still click-heavy, still that confirm button
Over-categorized: every section added a click
Emphasized structure over the user doing the task

People first

Shipped

The final direction flipped the priority. Add members directly, or reach them through a circle or role when you want the context. Hover reveals which team someone is acting under; a click opens a small modal to reassign or unassign. Circle and role became optional funnels, not gates.

What improved

One menu, with search always at the top
Keyboard-navigable; members picked straight from the cascade
Assign a whole team by circle or role, or just the right people
Members can be assigned outside any circle or role

The cost

Richer hover / modal logic to build and maintain
Structure is one interaction away, not always visible

The system that shipped

People first. Structure when you ask for it.

The final flow starts with the user, that is who completes the task, while circle and role stay as optional filters when a part of the team is needed.

Add a member directly, or through a circle or role for extra context. Click a member and a small modal shows which team they're acting under, with a button to unassign. Hover circles, roles and members for a quick read of who is in what team.

High-fidelity screen of the shipped people-first menu inside a task panel, with search always on top.

High fidelity: add members directly, click to reassign, search always on top.

Add a member directly

Hovering a circle highlights it and previews its team.

Hover a circle to preview its team

Clicking a circle opens options to remove the role or its members.

Click a circle to remove a role or its members

Clicking a member shows their teams with a button to unassign them.

Click a member to see their teams, or unassign

Progressive filtering: each choice narrows the next list, so an org with hundreds of roles stays a two-step selection.

How I worked with AI

Faster to explore. Sharper to decide.

On a governance product, judgment is the whole job. A wrong assignment model breaks permissions. AI helped me search wider, but I made the calls, and each step kept those two things separate.

Synthesis

Claude AIChatGPT

AI did

Clustered interview notes and support signals into recurring frictions.

I decided

Which were built into the system versus isolated cases, and which were worth solving at scale.

Scenario writing

Claude AIChatGPT

AI did

Generated the full list of assignment scenarios, edge cases included, faster than I could name them.

I decided

Cut it to the cases governance actually had to handle, and removed what the permission rules wouldn't permit.

Benchmark

ChatGPT

AI did

Researched and summarised how other tools handle assignment across teams.

I decided

Which patterns actually fit governance, and which would seem to fit but break the logic.

Edge-case pressure

Claude AIChatGPT

AI did

Stress-tested the flow against permission rules and large-org scale before I committed.

I decided

Fixed what broke and kept every path inside governance logic through to handoff.

Creating the solution

Figma MakeClaude Design

AI did

Created layout variations and turned rough sketches into clickable screens.

I decided

Nitpicked toward the version that kept a dense flow feeling light, then refined it.

The decisions were mine. AI widened the search, but not the standard.

Outcome

Faster, clearer, and finally a cross-team solution.

+34pts

0% → 34%

Roles assigned across multiple circles. It started at 0% because collaboration simply couldn't happen before.

−39%

19.4s → 11.8s

Time to complete an assignment, measured in Mixpanel across real sessions.

+43pts

41% → 84%

Positive feedback in user testing on the assignment experience.

Cross-team collaboration

Projects can now involve members, roles and circles across the whole organization.

Transparent visibility

Users see how members relate to roles and circles. Less ambiguity, less duplicate work.

Scales to other modules

The same pattern carries into meetings and metrics, staying performant for large orgs.

The takeaway

The win was flexibility that stayed clear under pressure.

Flexibility and clarity usually trade against each other. The more open the system, the more complicated it gets.

The challenge was to have both: let teams cross boundaries without losing the clear ownership governance is meant to protect.