Altinn Studio
IMPROVING THE DEPLOYMENT EXPERIENCE
Altinn Studio is used by public sector teams to build and publish digital services. Deployment is the final step before a service goes live.
Users were often blocked at the final step because validation errors appeared too late. Many believed the build step meant they were finished, only to encounter issues when attempting to publish.
I redesigned the deployment experience to introduce continuous validation, clearer sequencing, and explicit readiness before publishing within existing technical constraints.
CASE OVERVIEW
Due to confidentiality, some visuals have been recreated to reflect structure and design decisions.
CASE SUMMARY
Project
Improving the deployment workflow in Altinn Studio
Role
UX designer in a cross-functional product team
Challenge
Users encountered errors late in the deployment process and lacked clear feedback.
Goal
Make the workflow more predictable by introducing clearer structure and earlier validation.
CHALLENGE
Deploy is the last step before a service goes live. In practice, users were often stopped at this stage.
They experienced:
Validation errors appearing only when attempting to publish
Build interpreted as completion rather than preparation
No clear indication of whether the service was ready to publish
Errors discovered too late in the process
Because validation logic was closely tied to backend rules and commit states, it could not simply be moved without careful coordination.
The challenge was to reduce late stage friction and make readiness visible earlier in the flow without disrupting existing release logic.
ORIGINAL BLURRED INTERFACE
Original deployment page combining build, validation, environments, and publish in one surface.
STRUCTURAL ANALYSIS
Originally, validation acted as a final checkpoint. Errors were discovered only at publish.
The redesign repositioned validation as an ongoing system state and introduced explicit readiness before release.
The change was structural rather than visual.
BEFORE VS AFTER STRUCTURAL DIAGRAM
Validation moved from the final publish step to an earlier and continuous state in the workflow.
UNDERSTANDING THE SYSTEM
Before changing the interface, I mapped how validation, build, commit states, and publishing interacted.
Through collaboration with product and engineering, and by reviewing onboarding feedback, I identified that:
Validation appeared too late in the sequence
Build success was mistaken for deployment readiness
System status was not clearly communicated
The order of actions did not match user expectations
The issue was not missing functionality. It was how the system communicated state and readiness.
EXPLORATION
I explored different structural approaches before deciding on a solution.
Key questions included:
When should validation occur
What defines readiness
How should system state be visible
How can publish remain controlled without adding friction
Separating publish from environment management clarified user intent and reduced confusion.
EARLY STRUCTURAL SKETCHES
Exploring clearer sequencing and separation of publish and environment.
KEY DESIGN DECISIONS
1. Separate Publish from Environment Overview
Clear separation between guided publishing and environment overview.
Publish requires a guided process.
Environment management requires monitoring.
Separating these reduced task switching and clarified user intent.
Introduce Continuous Validation
Validation now runs continuously rather than only at publish.
A global indicator displays validation errors at all times. A detailed drawer exposes issues from anywhere in the application.
On the Publish page, validation is combined with readiness signals:
Latest commit
Whether changes are shared
Current validation state
Clear indication of build eligibility
Build is blocked until required conditions are met.
Because validation depends on backend rules and commit states, this required close collaboration with developers.
Continuous validation and readiness signals prevent build until requirements are met.
Make Readiness Explicit
Build is no longer perceived as completion.
A clear readiness state signals when a service is fully validated and ready to publish.
This reduces uncertainty and supports confident decisions.
Simplify Terminology
Terminology was simplified to reduce ambiguity between build and publish and to reinforce the correct sequence of actions.
Clear language strengthens understanding in complex system workflows.
OUTCOME
The updated deploy flow introduces continuous validation, clearer sequencing, and visible readiness before publishing.
Users now move through a structured process where they can clearly see:
Whether validation issues are resolved
Whether changes are shared
Whether the service is eligible for build
After the redesign, readiness is visible earlier in the workflow, reducing surprise errors at publish.
Although the visuals shown here are reconstructed due to confidentiality, they accurately represent the implemented structural changes.
The result is a deployment process that feels controlled, predictable, and aligned with user expectations.
RECONSTRUCTED PUBLISH VIEW
Final publish structure showing real-time validation and readiness signals that guide users clearly to completion.
RECONSTRUCTED ENVIRONMENT VIEW
Environment overview separated from the guided publish flow.
IMPACT
The redesign reduced late stage errors in a critical workflow and aligned system behavior with user expectations.
It contributed to:
Earlier error discovery
Clearer ownership of configuration
Reduced uncertainty before publishing
Stronger collaboration between design and development
The primary change was structural rather than cosmetic. Next step would be to measure error rates after release to validate long-term impact.
REFLECTION
This project strengthened my ability to design within technical constraints.
In complex systems, clarity depends on sequencing and state visibility more than visual refinement.
I now approach system driven problems by understanding backend logic first and shaping the interface around it.
If continuing this work, I would measure publish error rates and user confidence after deployment to validate long term impact.