Case 02 · Holaspirit · Product design · UX/UI · Team management

As organizations grew, their governance stopped being readable.

In Holaspirit, a company is built from roles and circles. Past a certain size, there was no shared way to organize them, so patterns blurred and duplicates piled up. This is how I gave teams a way to group, filter and navigate their governance as structured data, without imposing a hierarchy on how they organize.

Role: Product Designer · UX/UI · Information architecture
Product: Holaspirit · enterprise scale
Scope: Governance structure · cross-app
Status: Shipped

My role

Everything underneath had to stay exactly as it was.

Roles, circles, permissions, the decision flow they carry: organizations run on that model every day, and nothing I designed was allowed to alter it. My work was the layer above it, and the rules that keep that layer coherent once a company runs on 300 roles. I carried it from discovery through to engineering handoff.

What I inherited

The governance model itself: roles, circles, permissions, and the reporting lines they define.

What I owned

The new layer end to end: discovery and synthesis, the information architecture across 3 areas of the platform, the vocabulary rules for admins, high-fidelity design and handoff.

Who I worked with

A product manager on scope, the support team for recurring client signals, admins of large organizations for testing, and developers on what we could reuse rather than build.

Context

Not an org chart. A living organizational architecture.

Holaspirit is a governance platform: it defines the roles, circles, and decision-making structures a company runs on. As that company grows, the model turns into an interconnected system of responsibilities, domains, and accountabilities. One that has to stay transparent and adaptable.

It's less an organizational chart than a living architecture. And it never stops expanding.

The problem

As governance scaled, it lost its legibility.

Roles and circles multiplied without a shared categorization logic. So patterns got hard to see, and the structure got hard to trust.

01 · Structure

No shared way to organize

Roles and circles multiplied without a common categorization, so consistency broke down across teams.

02 · Scale

Governance outgrew itself

As organizations grew, the structure got harder to navigate and harder to maintain.

03 · Cognitive load

Everything meant scanning

Finding a single role or circle meant reading through large, complex structures.

04 · Duplication

The same role, reinvented

Without system-wide visibility, similar roles got created without anyone realizing.

The reframe. The problem was never a missing feature. It was the absence of any scalable way to structure governance data once a company grew past a certain size.

Discovery

Four sources, one conclusion.

I started with 4 sources: support tickets, interviews with admins of large organizations, Mixpanel, and a benchmark of other tools. Each one showed a piece of it. Put side by side, they kept pointing at the same 4 problems.

Support signals

Recurring client complaints about navigating and maintaining governance.

Admin interviews

How large organizations actually keep their structure readable.

Mixpanel baseline

The governance view measured at 18.2s to locate a role.

Benchmark

How other tools structure without imposing a hierarchy.

The path I kept hearing in interviews. Friction doesn't peak on finding a role, it peaks on not being able to prove one doesn't exist: that's where duplication comes from, and why the answer had to be filtering, not another view.

The bet

Add structure without adding a hierarchy.

Every angle of the research pointed the same way: users didn't need more features, they needed a way to organize what was already there.

The bet was labels. Extending them to roles and circles adds structure without forcing anyone into a fixed model: each team groups and filters its governance its own way, and nothing underneath moves. And because a label means the same thing everywhere it appears, one vocabulary can end up covering the whole company.

The constraints

New structure, without touching the old one.

Organizations define their governance on purpose. The labeling layer had to add capability while changing nothing underneath it.

Constraint 01

Cannot alter reporting or authority

New structuring mechanisms must never change reporting lines, authority, or how decisions flow.

Decision

Labels are metadata, never hierarchy

A categorization layer that sits beside governance with zero effect on reporting or decision flow.

Trade-off: labels sit on top of the structure without shaping it.

Constraint 02

Cannot impose a rigid model

Every company governs differently; a fixed categorization would fight their internal logic.

Decision

Optional, adopted gradually

Labels are a layer teams opt into at their own pace — not a structure forced on them.

Trade-off: uneven adoption, in exchange for organizational autonomy.

Constraint 03

Vocabulary loses consistency at scale

Across a large organization, the same idea gets written 5 different ways and filtering falls apart.

Decision

Admin-controlled vocabulary

Label creation can be admin-managed, so the whole organization shares one language instead of near-duplicates.

Trade-off: less spontaneity and extra effort for managers, for a vocabulary that actually filters.

The system in practice

Categorize, filter, and keep the vocabulary shared.

Rather than add new visualizations, the system works inside the views users already know. Labels are added into existing flows, and filtering happens in place.

Apply

Categorize where you already work

Labels are added right where you view or edit a role or circle. Reusing the existing label modal keeps everything familiar from day one, and a new section holds personal labels like "to review", making categorization part of the flow instead of a separate task.

Applying labels inside a role view: the Labels section on a role, the members filled by it, and the label panel with checkboxes.

Reusing the label model also avoids costly development for the tech team.

Creating and editing a label: the labels list, the edit-label modal, and the colour picker with a custom colour.

How the label system works.

Filter

Turn the whole structure into something to filter and explore

Click the search bar and a modal opens with filters and your recently searched words. Enter one, and the governance view filters to the matching roles and circles. It makes it immediately clear what needs attention and where it sits in the organization. This is where a big map becomes navigable.

The search modal open over the governance view.

Search opens filters and recently searched words.

The governance view, filtered to the labels that matter.

Govern

One vocabulary, across the whole company

Labels can be admin-managed, so the organization shares a single vocabulary instead of 5 spellings of the same idea. It is the difference between filtering that works and filtering that adds confusion. They can be cross-app too: a label created in "Centralize labels" also appears in project labels, unifying the wording company-wide so governance and projects finally speak the same language.

Administration label settings: centralized cross-app labels, governance labels, and project labels, each able to allow custom labels.

Each section can allow custom labels, so teams can adapt them to how their governance works.

How I worked with AI

Faster to map. Sharper to decide.

3 different places in the platform had to work together, which AI helped me map out. But the real challenge was making labels adapt to any way a team governs itself. Some managers want a say, some a bit, some none at all. AI helped me see the space; the calls were mine.

Synthesis

Claude AI

AI did

Gathered support data and client feedback into recurring governance pain points.

I decided

Which were structural versus surface complaints that labels would not fix.

Edge-case pressure

Claude AI

AI did

Stress-tested the model against real organizations — near-duplicate labels, cross-app conflicts.

I decided

Set the admin-vocabulary rule directly from what broke under that pressure.

AI helped me see the edge cases, but my decisions were the design work.

Outcome

Governance you can search and navigate, not just read.

+37pts

0% → 37%

Roles and circles using at least one label — users adopting the new structure.

+31%

860 → 1,127

Interactions with the governance view. People are actually exploring it now.

−41%

18.2s → 10.7s

Time to locate a specific role or circle.

Clarity & navigation

Sharper filtering, faster decisions, easier comparison across teams as well as fewer accidental duplicates.

Scale without clutter

Complexity is handled through labels, not new visualizations, with the option to restrict vocabulary to admins.

Consistency across entities

One shared vocabulary covering roles, circles, and projects, across the whole company.

The takeaway

The change was from reading governance to navigating it.

A shared labeling layer let teams organize, filter, and navigate their organization as structured data. It eased the mental load while letting each team grow its own way.