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: Sole product designer · discovery → handoff
Product: Holaspirit · enterprise scale
Scope: Assignment system, cross-module
Status: Shipped

My role

What was mine to design, and what I built on.

I was the only product designer on the assignment system, from discovery to engineering handoff. To be clear about what was mine: I didn't design the governance model. I designed the assignment system built on top of it.

What I inherited

The governance model (circles, roles, permissions) and part of the existing design system. I also had to respect how Holacracy worked within projects.

What I owned

The cross-circle assignment system end to end: discovery and synthesis, the three explored directions, high-fidelity design and handoff.

Who I worked with

A product manager on scope and constraints, users for testing and developers on feasibility.

Context

Each project lived in one circle, until they 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

The boards were about to open across circles. The assignment model was not ready.

Nothing had shipped yet, and that is exactly where the work started: mapping what the opening would break, before starting anything.

Three roles, one name

Every circle has its own “Team Lead”. On a project with several of them, three identically named roles would land on the same task. There would be three different accountabilities with one label.

One more thing to fit on screen

The role already shows but not the circle. Once they open, there was one more level to fit into an already dense flow, in an already tight space.

Locked to one circle

Assignment only offered members of that one circle. That is exactly the limit the opening has to lift, and the flow was never built for it.

The existing flow was already slow: 19.4s per assignment, multiple steps and context switches, before cross-circle work even entered the picture. Found with user interviews, support tickets, measurement of the old flow.

Discovery

Where the three frictions came from.

The problems above were not assumptions. They came from four inputs I gathered before touching an interface: conversations with users, support tickets, the Mixpanel baseline of the old flow, and a benchmark of how other tools handle cross-team assignment.

User interviews

Where the confusion actually showed up in real workflows.

Support tickets

Recurring complaints about assignment and ownership.

Mixpanel baseline

The old flow measured at 19.4s per assignment.

Benchmark

How other tools handle assignment across teams.

Risk-mapping board: my questions about what opening projects across circles would break, clustered into the three problems the system had to solve

Before building, I mapped every question that opening projects across circles would raise. They clustered into the three problems the system had to solve. There was ownership, structure, and reaching outside your circle.

Two jobs sat underneath every question, and the design had to serve both at once rather than pick a side.

The member

“Just assign the right person, fast.”

Wants to add whoever should do the task without thinking about circles or roles.

The lead / admin

“Keep ownership clear, even in big organizations.”

Needs to see how members, roles and circles work so responsibility stays clear across hundreds of roles.

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.

Task panel before any assignment: no assignees yet, with circles, roles and members ready to pick from.

Before assigning: add members directly, click to reassign, search always on top.

Task panel after assigning: circles and member avatars shown under Assignees, with the menu still open.

After assigning: information of users added for more context.

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 approach

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 approach.

+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, clearer ownership.

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.