Enterprise · Internal Tool
Replacing Jira at Halden Group with Compass, an internal task-management product built on Mendix.
Role
UX & Product Designer
Timeline
Early 2025 — Present
Services
UX Research, Information Architecture, User Flows, UX/UI Design, Design System contribution
Year
2025 — Present
Industry
Enterprise · Commodities
Platform
Mendix (low-code)
Live
Internal — Halden Group (Baar, CH)
Leftward pointing arrow icon.
Back to all case studies
Jump to key decisions
Three problem cards — Usability, Coverage, Security — breaking down what sounded like 'replace Jira' into the three forces that actually shaped Compass. Security was the forcing function; the other two made it worth doing well.
Project overview
Compass is Halden Group's internal task-management product — a Mendix-based platform built to replace Jira as the day-to-day tool used across departments. It's live in ten departments at the Baar headquarters, with the migration from Jira continuing in a deliberately slow, careful way to avoid losing traceability built up over years of use.

The project started in early 2025 and is still in active rollout. The product keeps evolving in parallel — adding coverage, refining flows, and moving teams off Jira when they're ready, not when the calendar says so.
Context
Halden Group has thousands of employees spread across departments that work very differently from each other — IT, Operations, Finance, HR, Legal, Supply Chain. All of them used Jira as a shared layer, but Jira had grown organically for years and carried the usual debt that comes with that growth: over-complex workflows, each department using the system in its own way, and users leaning on workarounds (Excel, email, chats) whenever the tool got in the way.

On top of that, the internal security team had raised flags — Jira wasn't meeting several criteria that Halden requires for a tool this critical. Between that, the functional gaps some teams reported, and the learning curve for non-technical users, the decision was made to build the replacement in-house on Mendix.

That replacement is Compass.
Six Jira pain points at Halden Group — over-complex workflows, team silos, workarounds in Excel and email, tangled permissions, high entry barrier, and security gaps — alongside the decision to build Compass in-house on Mendix.
Research approach
Methods
Mendix platform research — what the low-code environment allows and penalises.

Stakeholder interviews across business, tech and governance.

End-user interviews across roles and departments.

Online survey open to the full user base.

Heuristic analysis of Jira's structural pain points at scale.
Key findings
Jira's flexibility had become a liability, not a feature — every team ran its own version.

The same "task" meant different things to different roles — work, commitment, process step.

Occasional users avoided the tool and fell back to spreadsheets, email and chat.

Governance couldn't scale without role-based differentiation.

Security requirements had to shape the product from the start, not be added later.
The problem, broken down
What sounded like "replace Jira" was actually three different problems happening at once, each pulling in a different direction. Treating them as one would have produced a prettier Jira. Treating them as three shaped Compass.

Three distinct problems, in order of weight:
— Usability. Too many fields, inconsistent statuses, high entry barrier. People who used Jira occasionally stopped opening it.
— Coverage. Functional gaps had forced teams into their own silos — impossible to govern at scale.
— Security. Jira couldn't meet Halden's control, traceability and audit requirements with confidence.
The third one is what made the decision final; the first two are what made it worth doing well.
Jobs To Be Done
Synthesis surfaced four core jobs — Executor, Manager, Process Owner, Admin — and the map of conflicts between the mental models each of them brings to a task. For an Executor, a task is "something to do." For a Manager, it's "a commitment." For a Process Owner, it's "a step in a process." The same object, three meanings. A good part of what felt inconsistent in Jira is explained by that mismatch.
In V1 scope
— Task creation & assignment
— Role-based views & permissions
— Simplified workflows
— Status & progress tracking
— Dashboards per role
— Explicit empty, loading and error states
— Microsoft Teams integration
— Audit trail aligned with Halden security criteria
Coming next
— Advanced reporting
— Automation rules
— Approval workflows
— SLA tracking
— HelpDesk / ITSM integration
— Migration of remaining departments
Role-based UX, not feature-first
Instead of one configurable interface for everyone, Compass shows different flows and views depending on role. An Executor sees "my work" with the minimum needed to act. A Manager sees team state and blockers. A Process Owner sees compliance and exceptions.

Same entity model underneath, different visibilities on top. This was the single most important structural decision in the project — it directly addresses the mental-model mismatch that made Jira feel inconsistent to everyone at once.

Three more decisions sit alongside this one: configuration over customisation (standard patterns that cover 90% of cases, flexibility in config not in UI); states as first-class citizens (empty, loading and error states designed from day one); and simplifying workflows before optimising them (a workflow with four clear states gets used; one with twelve gets avoided).
Four Jobs To Be Done personas — Executor, Manager, Process Owner, Admin — each with a different mental model of what a 'task' means. Below: V1 scope shipped and the coming-next roadmap.
The role-based dashboard: today's work, blockers, and the pieces waiting on the user — stripped down to what actually needs attention.
Compass 'My Work' dashboard — role-based view for an Executor showing 4 KPI tiles (due today, in progress, in review, done by me), filter chips, and a 6-row task table with status pills, priority flags, assignees and due dates. Role chip 'Employee' visible in the topbar.
Simplified task creation. The form asks for what a specific role needs for a specific type of task, not every field Jira could ever ask for.
Compass task detail view (PO-402 Supplier integration) — role-aware task page with status pill, priority and delay chips, acceptance criteria checklist with progress bar, blocker warning card, meta panel with assignee/reviewer/sprint, activity feed and comment input.
Workflows reduced to the minimum number of states a process truly needs. The first design question for every migrated flow was "how many statuses can we remove without breaking this?"
Compass sprint board (Sprint 24) viewed as Manager — 4 Kanban columns (To do, In progress, In review at WIP limit 2/2, Done +18) with left-border accented cards, a 'blocked' badge, and an open Sprint 24 popover showing committed/done/at-risk stats plus Plan next / Open retro / Close sprint actions. Role banner 'Viewing as Manager' across the top.
Explicit ownership and next action. Users shouldn't have to interpret who owns a task or what should happen next — the UI says both.
Compass Team reports view for the Supplier Integration team — 4 KPI tiles (completion rate, cycle time, blocked time, items shipped) with sparklines, 6-sprint velocity bar chart, status mix donut, and a per-person breakdown table (shipped, in progress, blocked, cycle time, on-time rate). Date range chip and Export CTA in the header.
Role-based visibility of the same underlying data. A Process Owner sees compliance and exceptions where an Executor sees today's work.
Three side-by-side Compass sidebars showing how the UI changes for Employee, Manager and Admin roles — same entity model underneath, three different visibilities on top, with role chips, banners and nav items that appear or lock by role.
Empty, loading and error states designed from the start. A good portion of the perceived improvement over Jira lives in these states — the product feels considered rather than reactive.
The system: Meridian
Meridian — Halden's internal design system — was about half-built when I joined. Rather than treating it as a closed resource, my work on Compass became a two-way contribution: whenever a pattern didn't exist (a bulk-action table, a task detail side panel, an assignee selector that respected permissions), I'd design it first for Compass, then document it so it could enter the system. That back-and-forth did two useful things: Meridian grew on real needs instead of speculation, and Compass stayed coherent with the rest of Halden's internal products.
Where it stands today
Role, not feature
One entity model underneath, different visibilities on top. The same decision that solves "the same task means three different things to three different people" also makes governance scalable.
Compass notifications panel open over the My Work page — 4 tabs (All, Unread, Mentions, Requests) with counts, 3 unread notifications today (rejected review, mention, review request) and 2 earlier (approved, system blocker flag), each with avatar, actor, quote, timestamp.
Flexibility isn't neutral
In Jira, flexibility was the problem, not the solution. In Compass, we've gained adoption by removing options — flexibility lives in configuration, not in the UI.
Compass mobile task detail with the Quick Actions bottom sheet open — 5 actions (Mark as done, Send to review, Block this task, Reassign, Delete) each with icon, label and hint. Darkened background behind the sheet shows the task metadata.
States as first-class citizens
Empty, loading and error states were designed from day one, not after the fact. It sounds minor but it carries a disproportionate share of the perceived improvement over Jira — the product reads as considered rather than reactive.
Five research methods used to shape Compass — Mendix platform research, stakeholder interviews, end-user interviews, online survey, heuristic analysis — and the five key findings that drove the design before a single screen was drawn.
Simplify before optimising
The first design question for every migrated workflow was "how many statuses can we remove without breaking this?" Usually, many. A workflow with four clear states gets used; one with twelve gets avoided.
Meridian — Halden Group's internal design system — showing color tokens (primary and semantic), the Manrope type scale, and four components Compass contributed back to the system: bulk-action table, task detail panel, role-aware assignee picker, status popover.
Migrating at the organisation's pace
The migration from Jira is deliberately slow. Too many people depend on the tool daily and too much traceability has been built up to make an abrupt switch. We move teams off Jira when they're ready, not when the calendar says so.
Five design principles Compass kept returning to: role not feature, flexibility isn't neutral, states as first-class citizens, simplify before optimising, and migrate at the organisation's pace.
Current state & migration
Compass is in production. Ten departments at the Baar headquarters use it as their task-management tool. We continue iterating in parallel — adding coverage, refining flows, fixing what reality surfaces — while moving teams off Jira when they're ready.

The migration is deliberately slow. Too many people depend on the tool daily and too much traceability has been built up to make an abrupt switch. What I can't yet report with numbers in hand: exact adoption, tickets managed, time saved, error reduction, satisfaction. The metrics defined early are instrumented, but honest impact needs a stable usage base, and we're still mid-journey.
Try the interactive prototypeClick through Compass as Employee, Manager or Admin — same screen, three visibilities→
What I'm learning
In a low-code environment, UX quality depends on understanding the platform as much as understanding the user. Designing without knowing Mendix's constraints would have meant redesigning half the work.

Two other things keep showing up. Flexibility isn't neutral — in Jira it was the problem, not the solution, and in Compass we've gained adoption by removing options, not adding them. And an enterprise-scale redesign isn't measured at launch; it's measured in how the organisation moves over the eighteen months that follow. We're at month ten.
Current migration status: 10 departments live on Compass, 3 migrating, around 5 still on Jira. 15 department tiles showing Baar HQ rollout, with Compass expanding deliberately rather than on a fixed calendar.Three enterprise redesign learnings from Compass — low-code reality (~40% of early patterns reshaped by Mendix constraints), flexibility isn't neutral (12→4 statuses per workflow after simplification), and that enterprise redesign is measured in months, not launch day (10/18 months in).