Finding patterns in complexity
Finding patterns in complexity
NAV, the Norwegian Labour and Welfare Administration, manages a large number of digital application forms developed across different services and over many years. This project explored recurring patterns across these forms to identify where greater consistency could improve the overall experience.
NAV, the Norwegian Labour and Welfare Administration, manages a large number of digital application forms developed across different services and over many years. This project explored recurring patterns across these forms to identify where greater consistency could improve the overall experience.
Role
Role
UX designer
Team
Team
4 designers
Timeline
Timeline
8 weeks
Methods & Tools
Methods & Tools
System analysis
Pattern analysis
Figma
Why this project matters to me
Why this project matters to me
What interested me about this project was the scale and complexity of the problem. NAV's services are used by a large part of the Norwegian population, meaning that even small improvements have the potential to affect many people.
What interested me about this project was the scale and complexity of the problem. NAV's services are used by a large part of the Norwegian population, meaning that even small improvements have the potential to affect many people.
I was particularly interested in the connection between internal systems and the end-user experience. The project challenged me to look beyond individual interfaces and consider how decisions made across many different forms shape the experience as a whole
I was particularly interested in the connection between internal systems and the end-user experience. The project challenged me to look beyond individual interfaces and consider how decisions made across many different forms shape the experience as a whole
My contribution
My contribution
I led the analysis of existing application forms, identified recurring patterns and helped develop the conceptual model used to discuss consistency across the ecosystem.
I led the analysis of existing application forms, identified recurring patterns and helped develop the conceptual model used to discuss consistency across the ecosystem.
Research process
Research process
Research process
01 Mapping the forms
We collected and mapped a broad selection of NAV application forms to understand the existing landscape and create a basis for comparison.
We collected and mapped a broad selection of NAV application forms to understand the existing landscape and create a basis for comparison.
02 Comparing flows
We compared similar application flows to identify differences in structure, sequence and how the same types of information were handled.
We compared similar application flows to identify differences in structure, sequence and how the same types of information were handled.
03 Identifying recurring patterns
We grouped similar elements and interactions across forms to understand where the same needs were being solved in different ways.
We grouped similar elements and interactions across forms to understand where the same needs were being solved in different ways.
04 Identifying opportunities
We used the recurring patterns to distinguish necessary variation from inconsistency and identify where greater standardisation could be valuable.
We used the recurring patterns to distinguish necessary variation from inconsistency and identify where greater standardisation could be valuable.
Key findings
Key findings
Key findings
Our analysis revealed three recurring themes across the application forms. Some differences reflected genuine service needs, while others had developed without a shared structure or design approach.
Our analysis revealed three recurring themes across the application forms. Some differences reflected genuine service needs, while others had developed without a shared structure or design approach.
01 Different structures
01 Different structures
Forms often contained similar information, but organized it under different labels and in different sequences. This made similar tasks feel less consistent across applications.
Forms often contained similar information, but organized it under different labels and in different sequences. This made similar tasks feel less consistent across applications.
Forms often contained similar information, but organized it under different labels and in different sequences. This made similar tasks feel less consistent across applications.
Application A
Application A
About you
About you
Circumstances
Circumstances
Work and income
Work and income
Children
Children
Application B
Application B
Circumstances
Circumstances
About you
About you
Work
Work
Relations
Relations
Application C
Application C
Financial situation
Financial situation
Personal information
Personal information
Family
Family
Situation
Situation
02 Similar information, different interactions
02 Similar information, different interactions
Forms sometimes asked for similar information through different interaction patterns. For example, one service required users to enter their current address, while another displayed their registered address for confirmation. In this case, the difference was necessary because the services had different information needs.
Forms sometimes asked for similar information through different interaction patterns. For example, one service required users to enter their current address, while another displayed their registered address for confirmation. In this case, the difference was necessary because the services had different information needs.
Registered legal address
Retrived from the National Registry
Must be correct in the National Registry
Cannot be changed directly in form
User confirms or updates the information
Current address
Where the user is currently staying
Used to route the application correctly
Can differ from registered address
03 Necessary differences vs. inconsistent design
03 Necessary differences vs. inconsistent design
Not every difference was a problem. Some variations were required by the purpose of the service, while others appeared to result from forms being developed independently without a shared system. The challenge was therefore to distinguish necessary flexibility from avoidable inconsistency.
Not every difference was a problem. Some variations were required by the purpose of the service, while others appeared to result from forms being developed independently without a shared system. The challenge was therefore to distinguish necessary flexibility from avoidable inconsistency.
Necessary Differences
Necessary Differences
Different information needs
Different service requirements
Different interaction needed to complete the task
Avoidable inconsistencies
Avoidable inconsistencies
Different terminology for the same information
Different structures for similar tasks
Different interaction patterns without a clear functional reason
The outcome
The outcome
The outcome
The analysis showed that consistency did not mean making every application form the same. By separating decision logic, structure and interaction, we developed a framework for identifying where variation was necessary and where a more consistent approach could be valuable.
The analysis showed that consistency did not mean making every application form the same. By separating decision logic, structure and interaction, we developed a framework for identifying where variation was necessary and where a more consistent approach could be valuable.
The analysis showed that consistency did not mean making every application form the same. By separating decision logic, structure and interaction, we developed a framework for identifying where variation was necessary and where a more consistent approach could be valuable.
The framework gave the team a shared way to discuss application forms across services and identify opportunities for greater consistency, while preserving the flexibility required by different services.
The framework gave the team a shared way to discuss application forms across services and identify opportunities for greater consistency, while preserving the flexibility required by different services.
The framework gave the team a shared way to discuss application forms across services and identify opportunities for greater consistency, while preserving the flexibility required by different services.
What I learned
What I learned
What I learned
This project changed how I think about consistency. I learned that standardisation is not about making every service behave the same way, but about understanding which differences are necessary and which create unnecessary complexity. It also showed me the value of stepping back from individual interfaces and looking at the system they belong to.
This project changed how I think about consistency. I learned that standardisation is not about making every service behave the same way, but about understanding which differences are necessary and which create unnecessary complexity. It also showed me the value of stepping back from individual interfaces and looking at the system they belong to.
This project changed how I think about consistency. I learned that standardisation is not about making every service behave the same way, but about understanding which differences are necessary and which create unnecessary complexity. It also showed me the value of stepping back from individual interfaces and looking at the system they belong to.