Turning Nav's struggling budget tool into “a dream tool” for 300 users
A 20% rise in user satisfaction at the Norwegian Labour and Welfare Administration, measured by an internal before-and-after survey.

Nav's digital budgeting and forecasting tool had launched with significant usability issues and a discouraged team. Over 13 months, I revitalized the team, introduced human-centered design practices, and redesigned the salary budgeting app from research through prototyping to launch. This case focuses on the salary budgeting app; in the same platform, I also worked on the forecasting and budgeting app for operational costs.
A chaotic launch, a discouraged team, and users stuck in Excel
Nav's budgeting and forecasting tool had been through a difficult first release: chaotic development, a stressful launch, and a product with serious usability and functionality problems. The team behind it was discouraged, cooperation had broken down, and there was no structured way to learn from mistakes or iterate.
For the ~300 budget users across the agency, the tool was hard to understand and frustrating to use. Language and screen names were unclear, layouts inconsistent, and the system gave no feedback on status or errors. Users didn't trust the numbers — the same value could show differently across screens. Worst of all, the budget process began before the tool was available, so users relied on Excel from start to finish; the tool added little value for anyone except leadership.
What I aimed to achieve
Restoring the team before redesigning the product
The instinct on joining a project with a troubled product is to fix the product. I chose to fix the team first — no amount of good design would land if the team couldn't collaborate.
I introduced agile ceremonies and methods incrementally, adapted to what the team needed. Each iteration we got better at cooperation, communication, and experimentation. The structure created a safe space to try things, fail, and learn without blame — and a framework for managing stakeholders and resolving critical errors in time.
In parallel, I began introducing a user-centered design process — small at first, then more consistently — so that as the team's confidence grew, our way of working was already shifting toward research-backed decisions and continuous user involvement.

The rest of this story is under NDA
The research artifacts, the service and process redesign, the prototypes, and the final interface are covered by an NDA. If you've received the password, enter it below to read the full study.
Don't have the password? Email ilya.g@me.com and I'll share access.
From unusable to “a dream tool”
I left the project shortly after the second version launched, but preliminary evaluations showed significant improvement. In the first version, users got lost between unclear screens, couldn't tell whether their work was saved, and fell back on support calls and Excel workarounds. In testing of the final product, those same tasks — finding the right screen, reading system status, trusting the numbers — were completed independently.
What I learned
Early and continuous developer involvement matters. When developers join research and prototyping from the start, feasibility is built into the design and handover risk disappears. Sharing research openly helps too: when developers understand why a decision was made, they make better micro-decisions during implementation.
The biggest insight was about structure and creativity. Agile ceremonies and design methods aren't bureaucracy; they're scaffolding. Structure creates safety, and safety enables innovation.