UI & UX DESIGN · PUBLIC SECTOR · 2025 - 2026
Altinn Studio is a tool developed by Digdir that lets public sector teams build and publish digital services and forms for Norwegian citizens. Deployment is the final step before a service goes live — and it was also where everything fell apart. I redesigned the deployment experience to introduce continuous validation, clearer sequencing, and an explicit readiness signal.
Due to confidentiality, some visuals have been recreated to reflect the structure and design decisions accurately.
CASE OVERVIEW
FIRST ENCOUNTER
CHALLENGE
Deploy is the last gate before a service reaches the public. In practice, it was also where things fell apart.
Validation errors appearing only when attempting to publish
Build being interpreted as completion rather than preparation
No clear indication of whether the service was ready to publish
Errors discovered too late in the process
The challenge was reducing late-stage friction and making readiness visible earlier, without disrupting the underlying release logic.
The original deployment page combined build, validation, environments, and publish in one surface.
UNDERSTANDING THE SYSTEM
Feedback from the product owner, designers, and end users shared in Slack confirmed what the mapping suggested: users consistently interpreted a successful build as the final step, not a precursor to publish.
The order is confusing
Users complained that build appears to the right of deploy, even though you build before deploy.
Forgot to deploy after build
Want a visual indicator when there is a newer build that has not been deployed.
Error messages are unclear
Error messages provided little concrete information about what actually went wrong.
Technical info overwhelms
Suggestions to hide technical details so that non-technical users are not overwhelmed.
Mapping the relationship between validation, build pipeline, deploy pipeline, and error states.
EXPLORING & PROTOTYPING
I explored several structural approaches before landing on a solution, working through questions like:
When should validation run?
What actually defines readiness?
How do we surface system state without adding noise?
How do we keep publish intentional without adding friction?
From whiteboard to full prototype — mapping all states and flows before implementation.
KEY DECISIONS
01
Separate Publish from Environment Overview
Publish is a guided, intentional action.
Environment management is monitoring and maintenance. Combining them on a single surface forced users to context-switch mid-task. Separating them reduced confusion and gave each action a clear purpose.
Environment overview separated from the guided publish flow, with publishing history and version status.
02
Continuous Validation
Validation now runs in the background at all times. A persistent global indicator shows validation state from anywhere in the application, and a detailed drawer lets users investigate issues without navigating away.
On the Publish page, validation is combined with readiness signals:
Latest commit status
Whether changes have been shared
Current validation state
Build eligibility
Build stays blocked until all conditions are met, and users can see exactly why.
The validation drawer surfaces errors clearly and blocks build until issues are resolved.
03
Explicit Readiness State
Build no longer looks like the finish line. A clear readiness indicator tells users when a service is fully validated and eligible for publishing, removing the uncertainty that was causing errors in the first place.
When there is nothing to build, the interface explains why and guides the user through the correct sequence.
04
Clearer Terminology
The language around build and publish was causing real confusion. Simplified terminology reinforces the correct sequence and makes the system easier to reason about, especially for users who don't work in the platform every day.
OUTCOME
The updated flow gives users continuous visibility into validation state, a clear sequence to follow, and an unambiguous signal before publishing.
My contract ended before the redesign shipped, so I don't have post-release metrics. What I do have is validation from the process itself. The solution was reviewed and approved by developers, designers, and the product owner, and was prioritised for implementation because it addressed issues that had been raised repeatedly by both users and service owners.
The final publish view, environment overview after success, and two-step unpublish confirmation.
IMPACT
Earlier error discovery reduced failed publish attempts
Clearer ownership of configuration steps
Reduced uncertainty before publishing
Stronger collaboration between design and development
Next step is to measure publish error rates post-release to validate long-term impact.
REFLECTION
