Kravbase: case management tool
Kravbase is a case management tool designed for municipal tax case handlers at Skattekontor Oslo, Norway.
This project is a self-initiated concept exploring operational workflows, interface clarity, and information hierarchy.
Case study and prototype in progress.
Context
Oslo Tax Office handles thousands of property tax objections every year. When a citizen disputes their assessment, a case handler reviews the objection, reads the supporting document, and registers a formal decision, which is then sent automatically to the claimant via Altinn, Norway's national digital communication platform.
It sounds straightforward. In practice, the workflow is fragmented: information lives across multiple sections, the case list gives no indication of urgency, and logging a decision requires more steps than the decision itself.
Kravbase is a redesign of that workflow.
The challenge
High-volume case management, designed for clarity. A tool that moves at the pace of the people who use it.
Kravbase is a UX concept redesign for a municipal tax objection system built to reduce friction for experienced case handlers who process dozens of cases daily. The challenge wasn't simplifying the work. It was making sure the tool never gets in the way of it.
Who is the user?
Lars Eriksen is a senior case handler at Oslo Tax Office with 12 years of experience. He processes 30–40 tax objections a day and knows exactly what decision to make before he opens most cases.
"I already know what decision to make. It takes me 10 minutes to find everything I need to document it."
Design decisions
Four modules, one shared flow. Each objection type has its own entry point and case-specific fields, but the path from list to decision to confirmation is consistent across the entire system.
The primary flow follows a case handler from login through to decision —> eight steps covering authentication, dashboard orientation, case triage, document review, and decision registration. Each step surfaces only what's needed at that moment, with no unnecessary navigation.
A case handler at Oslo Tax Office processes 30 to 40 objections a day. That's not 30 to 40 simple tasks, each case requires reading a legal document, cross-referencing property or payment data, applying procedural logic, and registering a formal decision that has real consequences for the person on the other side.
The volume is unforgiving. And the systems that exist to support this work often make it harder, not easier: information scattered across sections, no visual sense of what's urgent, and decision workflows that add steps instead of removing them.
The core design challenge for Kravbase was not about making the interface look cleaner. It was about understanding how someone moves through 30 cases in a day and designing a system that moves with them, surfacing the right information at the right moment, reducing the distance between context and action, and making the path from opening a case to registering a decision as short as it can possibly be.
That meant consolidating everything relevant to a case into a single view instead of spreading it across tabs. It meant sorting by urgency by default, so Lars doesn't have to decide where to start. It meant building a decision panel that lives exactly where the document review ends. And it meant giving the dashboard a role, not as a landing page, but as a daily briefing that tells Lars what the day looks like before he opens a single case.
The tool doesn't make the decisions. Lars does. But it can make sure that by the time he needs to decide, everything he needs is already in front of him.
This case study captures one flow, but Kravbase as a system is much larger than that.
Tax objections are just one type of case. The same handlers work across property assessments, payment disputes, and escalated cases that go to formal review.
Designing the full system would mean thinking through role permissions, case assignment logic, bulk actions, reporting, and how the archive scales over years of closed cases.
That's the part I find most compelling about this kind of problem —> it's not a product you can finish. It grows with the institution that uses it, and every edge case reveals something new about how people actually work inside bureaucratic systems.
The flow shown here is a starting point, not a conclusion.