Altinn Studio
Improving the Deployment Experience
Improving the Deployment Experience
Altinn Studio is a platform used by public sector teams to build and publish digital services.
This case shows how I worked to improve the deployment experience — a step that technically existed, but was often forgotten or misunderstood.
Altinn Studio is a platform used by public sector teams to build and publish digital services.
This case shows how I worked to improve the deployment experience — a step that technically existed, but was often forgotten or misunderstood.
Altinn Studio is a platform used by public sector teams to build and publish digital services.
This case shows how I worked to improve the deployment experience — a step that technically existed, but was often forgotten or misunderstood.
TL;DR
Redesigned the deployment experience to improve clarity, reduce errors, and guide users from build to publish with confidence.
Redesigned the deployment experience to improve clarity, reduce errors, and guide users from build to publish with confidence.
Case Overview
CONTEXT
Norwegian public-sector platform
Norwegian public-sector platform
Norwegian public-sector platform
SCOPE
Research, analysis, interaction design, prototyping
Research, analysis, interaction design, prototyping
Research, analysis, interaction design, prototyping
COLLABORATION
Product owner, developers, designers, end users
Product owner, developers, designers, end users
Product owner, developers, designers, end users
ROLE
UX Designer
UX Designer
UX Designer
STATUS
Ongoing work
Ongoing work
Ongoing work
Deployment page before changes
Original interface, blurred due to confidentiality
Original interface, blurred due to confidentiality
Structural overview of the deployment page
Conceptual wireframe illustrating structure, flow, and separation of concerns. Visual design and content intentionally abstracted.
Conceptual wireframe illustrating structure, flow, and separation of concerns. Visual design and content intentionally abstracted.
Why - The problem
Users often finished building an app without realising that deployment was a separate and required step.
Users often finished building an app without realising that deployment was a separate and required step.
This confusion was reinforced by:
The process started from right to left, which felt unnatural
The order of actions did not match users’ mental models
Error messages rarely explained what went wrong or how to fix it
The process started from right to left, which felt unnatural
The order of actions did not match users’ mental models
Error messages rarely explained what went wrong or how to fix it
How - Understanding the real user experience
To understand where users struggled, I mapped the deployment experience step by step.
To understand where users struggled, I mapped the deployment experience step by step.
Feedback was placed directly onto the journey and then grouped into themes. This helped separate isolated issues from recurring problems and made it clear where users lost track of progress or misunderstood system state.
Feedback was placed directly onto the journey and then grouped into themes. This helped separate isolated issues from recurring problems and made it clear where users lost track of progress or misunderstood system state.
I gathered input from:
Product owner
Who runs onboarding and training sessions and sees recurring issues first-hand
Who runs onboarding and training sessions and sees recurring issues first-hand
Designers
Designers who had observed users and experienced the deployment flow themselves
Designers who had observed users and experienced the deployment flow themselves
Users
Who runs onboarding and training sessions and sees recurring issues first-hand
Through direct feedback shared in Altinn´s external channel in Slack
Through direct feedback shared in Altinn´s external channel in Slack
Recurring patterns emerged:
The process started from right to left, which felt unnatural
The order of actions did not match users’ mental models
Error messages rarely explained what went wrong or how to fix it
The process started from right to left, which felt unnatural
The order of actions did not match users’ mental models
Error messages rarely explained what went wrong or how to fix it
Simplified journey map showing the deployment flow, expectations, and key pain points. Visuals are anonymised and abstracted
Simplified journey map showing the deployment flow, expectations, and key pain points. Visuals are anonymised and abstracted
Summary of all findings, grouped into shared themes. Different colours represent insight categories identified across user input.
Summary of all findings, grouped into shared themes.
Different colours represent insight categories identified across user input.
Summary of all findings, grouped into shared themes.
Different colours represent insight categories identified across user input.
Reframing the Challenge
How might we make deployment visible and self-explanatory — without adding friction for experienced users?
How might we make deployment visible and self-explanatory — without adding friction for experienced users?
The focus shifted toward:
Clear vibility of system state
Clear vibility of system state
A natural build —> publish sequence
A natural build —> publish sequence
Feedback users could understand and act on
Feedback users could understand and act on
This reframing moved the solution away from reminders or documentation and toward structure and guidance.
This reframing moved the solution away from reminders or documentation and toward structure and guidance.
Exploring a Clearer Structurer
With a clearer problem framing, I explored how the deployment experience could better support users through structure — without locking them into a rigid process.
With a clearer problem framing, I explored how the deployment experience could better support users through structure — without locking them into a rigid process.
The focus was on:
making progress and system state visible
making progress and system state visible
aligning the flow with users' expectations
aligning the flow with users' expectations
reducing cognitive load by separating guidance from technical detail
reducing cognitive load by separating guidance from technical detail
Early concepts that added friction or unnecessary complexity were intentionally discarded. What remained was a clearer structure that guides users through building and publishing, while still leaving room for advanced workflows.
Early concepts that added friction or unnecessary complexity were intentionally discarded.
What remained was a clearer structure that guides users through building and publishing, while still leaving room for advanced workflows.
Conceptual sketches and wireframes exploring different ways to structure the deployment flow.
Conceptual sketches and wireframes exploring different ways to structure the deployment flow.
Shaping a More Coherent Deployment Flow
The final direction focused on connecting building and publishing into one coherent experience.
The final direction focused on connecting building and publishing into one coherent experience.
To reduce confusion, the deployment experience was divided into two distinct tabs:
To reduce confusion, the deployment experience was divided into two distinct tabs:
Publish focuses on the step-by-step process of building and publishing an app
Publish focuses on the step-by-step process of building and publishing an app
Environment focuses on overview, version history, and control across environments
Environment focuses on overview, version history, and control across environments
Simplified wireframe showing the guided build and publish process, with clear next steps and visible system state.
Simplified wireframe showing the guided build and publish process, with clear next steps and visible system state.
This separation makes it clear when users are in a guided workflow — and when they are reviewing or managing existing deployments.
This separation makes it clear when users are in a guided workflow — and when they are reviewing or managing existing deployments.
The redesigned structure:
guides users from build to publish without relying on memory
guides users from build to publish without relying on memory
keeps system state visible before and after publishing
keeps system state visible before and after publishing
provides clear feedback about success, failure, and next steps
provides clear feedback about success, failure, and next steps
separates guidance from technical detail
separates guidance from technical detail
Both non-technical and experienced users are supported without added complexity.
Both non-technical and experienced users are supported without added complexity.
To make the flow understandable in practice, the structure is reinforced through clear status and feedback components.
To make the flow understandable in practice, the structure is reinforced through clear status and feedback components.
What Changed, and Why It Matters
Deployment is no longer a hidden technical step, but a visible and expected part of the workflow.
Deployment is no longer a hidden technical step, but a visible and expected part of the workflow.
The experience now supports users through structure rather than memory.
The experience now supports users through structure rather than memory.
As a result:
users can clearly see whether an app is built or published
users can clearly see whether an app is built or published
the transition from build to publish feels natural and intentional
the transition from build to publish feels natural and intentional
errors explain what went wrong and what needs to fixed
errors explain what went wrong and what needs to fixed
progress and responsibility are clearly communicated
progress and responsibility are clearly communicated
Simplified wireframe showing one state of the guided publish flow. Before-after conceptual flow comparison.
Simplified wireframe showing one state of the guided publish flow. Before-after conceptual flow comparison.
Reflection
This project reinforced how critical visibility and sequencing are in complex systems.
This project reinforced how critical visibility and sequencing are in complex systems.
When users can clearly see:
what has been done
what has been done
what remains
what remains
and what went wrong
and what went wrong
they feel more confident and are far less likely to miss important steps.
they feel more confident and are far less likely to miss important steps.
What I Would Do Next
This work is still in progress.
Next steps would be:
review and refine interface text together with a content designer
review and refine interface text together with a content designer
validate the redesigned flow through user testing
validate the redesigned flow through user testing
iterate further on feedback, error handling, and edge cases
iterate further on feedback, error handling, and edge cases
My Point of View
In complex public-sector tools, good UX is about clarity, continuity, and trust.
When systems clearly communicate state and expectations, users do not need to rely on memory — they can rely on the product.
In complex public-sector tools, good UX is about clarity, continuity, and trust.
When systems clearly communicate state and expectations, users do not need to rely on memory — they can rely on the product.