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 a labeling layer that gave teams a way to tag, filter, and navigate their governance as structured data, without imposing a hierarchy.

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

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.

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 labels to roles and circles added structure without forcing anyone into a fixed model. Teams could group, filter, and explore their governance without a taxonomy imposed from above. Labels became shared signals across the system, surfacing the right information when it was needed, and turning a static structure into something you could filter and explore.

Where governance drew the line

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

Cannot break existing governance

Organizations rely on stable models. Nothing could disrupt current roles, circles, or permissions.

Decision

Purely additive

Every existing role, circle, and permission is preserved. Labels only add to them.

Trade-off: no restructuring shortcuts, nothing at risk operationally.

Constraint 04

Vocabulary loses consistency at scale

Across a large organization, the same idea gets written five 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 five 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.

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