Oman.om — Redesigning a National E-Government Portal Around People, Not Institutions

Project Overview

Oman.om is the official e-government services portal of the Sultanate of Oman, bringing together public services, information, initiatives, and resources from multiple government entities.

The challenge was not simply to redesign individual pages. The portal needed to support very different audiences — including citizens, residents, investors, people with disabilities, elderly users, students, parents, low-income users, people living in rural areas, and small business owners — while helping them navigate a large and complex government ecosystem.

As the Senior Product Designer, I worked on the UX planning and redesign of the portal, with a particular focus on user research, persona development, information architecture, service discovery, accessibility, content structure, and interface consistency.

My Role

Senior Product Designer

My responsibilities included:

Planning and conducting user interviews
Researching multiple audience groups
Creating personas based on research findings
Identifying major usability and information architecture problems
Redesigning the portal’s information architecture
Moving the experience away from an organization-centered structure
Designing service discovery patterns
Redesigning service detail pages
Improving accessibility considerations
Creating more consistent page structures
Designing key portal experiences across different content and service types

The Challenge

The previous portal reflected the internal structure of government more than the mental model of the people using it.

Users often needed to understand which ministry or government entity owned a service before they could find it.

This created several major problems:

1. Services Were Hard to Find

Users often knew what they wanted to accomplish, but not which government organization was responsible for it.

A person might want to:

renew a document
find financial assistance
access a health-related service
start a business
find information related to education
complete a family-related task

But the portal structure required them to think in terms of government entities rather than personal needs.

2. The Information Architecture Was Organization-Centered

The existing architecture was primarily based on ministries and government organizations.

This might make sense internally, but it creates additional cognitive effort for users.

The design opportunity was to move toward a structure based more closely on:

Who are you? → What are you trying to do? → Which service or information do you need?

rather than:

Which ministry owns this service?

3. There Was Too Much Information

Government pages naturally contain large amounts of information, including:

eligibility criteria
requirements
procedures
supporting information
regulations
references
related services
supporting documents

In the previous experience, this information could become overwhelming and difficult to scan.

One of the goals of the redesign was therefore to introduce clearer hierarchy and make important information easier to identify.

4. Accessibility Was Weak

A national government portal needs to work for users with very different abilities, levels of digital literacy, devices, and access conditions.

Accessibility was therefore not treated as an isolated feature.

It influenced decisions around:

navigation
content hierarchy
readability
interaction patterns
service guidance
support
page consistency

5. Page Structures Were Inconsistent

Different sections and services could present information in different ways.

This increased the learning effort required from users because they could not easily build expectations about where important information would appear.

The redesign introduced more predictable structures for services and content.

Research

Understanding a Diverse Public Audience

Because Oman.om serves an entire population rather than one narrowly defined user type, one of the most important parts of the project was understanding the diversity of its users.

I conducted approximately 15 user interviews across the portal’s major audience groups.

The research included users representing:

Citizens
Residents
Investors
Small business owners
Elderly users
People with disabilities
Parents
Students
Retired users
Low-income users
People living in rural areas

The goal was not only to understand what services people used, but also:

how they looked for information
what they expected from government websites
what confused them
what prevented them from completing tasks independently
how comfortable they were with digital services
what kind of guidance they needed

Persona Framework

Based on the interviews, I created a broader persona framework representing different citizen and audience segments.

Each persona included:

Demographic information
Background and context
Behaviors and habits
Goals and motivations
Pain points
Representative user needs

The personas helped the team move away from a generic concept of “the user.”

Instead, we could discuss specific situations.

For example:

An elderly citizen may need to access government services from home but have limited confidence using digital systems.

A person with a visual disability may rely heavily on assistive technologies and need predictable, accessible page structures.

A rural user may have limited access to government offices and therefore place greater value on remote access to services.

A parent may be less interested in which ministry owns a service and more interested in finding services related to their family.

A small business owner may need clear guidance across services owned by several different government entities.

Example Persona: Citizen — Elderly

One of the audience groups highlighted through the research was elderly citizens.

Typical challenges included:

limited familiarity with complex digital systems
difficulty navigating large amounts of information
fear of making mistakes when completing online processes
reliance on family members for assistance
a strong need to avoid unnecessary travel to government offices

For these users, simplicity was not just a usability improvement.

It directly influenced their ability to access services independently.

Example Persona: Citizen — Disabilities

Accessibility research also highlighted different needs among users with disabilities.

For example, visually impaired users may depend on:

screen readers
audio interfaces
predictable navigation
accessible forms
properly structured content

Users with physical disabilities may experience a different problem: digital services can significantly reduce the need to travel to physical government locations.

This reinforced the importance of treating accessibility as part of the core product experience.

Example Persona: Citizen — Rural Areas

Users living outside major cities may face longer travel distances to government facilities.

For these users, the portal represents more than convenience.

It can become an important access channel for:

information
permits
financial assistance
public services
government procedures

This reinforced the need to design the portal around tasks rather than institutional structures.

Key Research Insight

The strongest insight from the research was relatively simple:

People think about their needs. Governments think about organizations.

Users typically did not approach the portal thinking:

Which ministry provides this?

They thought:

I need to start a business.

I need help with a family-related service.

I need to renew something.

I need financial assistance.

I need information about education.

This difference became one of the foundations of the redesign.

Rethinking the Information Architecture

From Ministry-Based Navigation to Audience-Based Navigation

The original portal structure was heavily influenced by ministries and organizational ownership.

The redesign introduced a stronger audience-oriented layer.

At the top level, users could identify themselves through major groups such as:

Citizen
Resident
Investor

From there, content and services could be organized into more understandable categories.

For citizens, examples included:

Family
Health and Prescriptions
Work and Labor Relations
Traffic
Disabled People
Money and Property

This reduced the need for users to understand the internal structure of government before finding a service.

Designing Around Service Discovery

One of the main design goals was to make services easier to explore from several different entry points.

A government portal cannot rely on a single navigation model because users approach it with different levels of knowledge.

Some know exactly what service they need.

Others only know their situation.

Others need to browse.

The redesigned concept therefore supported multiple discovery paths.

Service Categories

Services were organized into recognizable categories such as:

Business and Entrepreneurship
Education and Training
Family and Life Events
Jobs and Workplace
Vehicle and Transportation
Tourism, Culture and Entertainment

This created a more human-readable entry point into the service ecosystem.

Popular Services

Frequently used services could be surfaced separately.

This allowed users to reach common tasks without navigating through the full information architecture.

The idea was to reduce unnecessary navigation for high-frequency needs.

Life Events

Another important concept was organizing information around life situations.

Examples included experiences such as:

having a baby
getting married
becoming a vehicle owner
dealing with health-related situations

Life-event navigation can bring together services that may technically belong to different government organizations but belong to one user journey.

This approach better reflects how people think about public services.

Search and Filtering

For users who preferred a more direct approach, search and filtering were also important.

The service experience included filters such as:

Service Category
Service Type
Service Language
Location
Availability
Service Order

This supported users who already had a general idea of what they needed but wanted to narrow a large set of services.

The important principle was to support both:

guided browsing and direct search.

Redesigning the Service Detail Experience

Finding the right service is only the first part of the user journey.

Users also need to understand:

what the service does
who it is for
whether they are eligible
what they need before starting
what steps are involved
what it costs
how to get support

The service detail page was therefore redesigned to communicate this information in a more structured way.

Service Summary

Important service information could be surfaced early, including:

Target audience
Service duration
Service channel
Service cost

This allows users to quickly decide whether the service is relevant before reading the full content.

Steps, Prerequisites and Support

Instead of hiding procedural information inside long paragraphs, important guidance could be separated into dedicated areas.

For example:

Steps

What the user needs to do.

Prerequisites

What is required before starting.

Customer Support

Where to get help.

This improves scanability and reduces the cognitive effort required to understand the service.

Improving Content Hierarchy

Government content can become very long.

The redesign explored ways to make longer pages more manageable through:

clearer section titles
stronger visual hierarchy
content grouping
table-of-contents navigation
cards and containers
progressive reading patterns
clearer separation between primary and supporting information

The objective was not to remove necessary information.

It was to make that information easier to understand.

Related Information and Services

Government services rarely exist in isolation.

A user looking at one service may also need:

related services
related regulations
reference material
supporting information
relevant initiatives

The design therefore introduced contextual recommendations and related content.

Instead of requiring users to return to the main navigation after every task, the interface could help them continue their journey.

Accessibility and Inclusive Design

Accessibility was especially important because the research included users with disabilities and users with varying levels of digital literacy.

The redesigned experience considered accessibility through:

clearer information hierarchy
simplified navigation
predictable page structures
readable content
visible accessibility controls
reduced complexity
support for audio or assistive experiences
easier access to help

The goal was to make the portal more usable for people who may otherwise need assistance to access public information and services.

Help and Guidance

Research also showed that some users may not be able to complete tasks using navigation and content alone.

For this reason, the redesign explored additional support experiences.

Help Center

A dedicated help center could provide answers to common questions such as:

How can I renew a passport?
What is the status of my application?
How can I pay government fees?
How can I access personal records?

Users could search for answers and browse common topics.

Direct Support

The concept also explored conversational support for users who needed more direct guidance.

The intention was to provide another path for users who became stuck during a government-service journey.

This was particularly relevant for:

less digitally confident users
complicated processes
users who could not find the correct information
users requiring additional guidance

Designing for Consistency

A key part of the redesign was establishing more consistent patterns across the portal.

Instead of allowing every page type to behave differently, the design introduced clearer patterns for:

Service pages
Information pages
Initiative pages
Search and discovery
Cards
Related content
Filters
Navigation
Support
Footer and global navigation

Consistency reduces the learning burden.

Once users understand one service page, they should have a reasonable idea of how another service page will behave.

Iterating the Interface

The project went through multiple design iterations.

Early concepts focused heavily on structure and information placement.

Later iterations refined:

visual hierarchy
spacing
service cards
filtering
content containers
navigation
service metadata
related-content patterns
page composition

The visual direction gradually became cleaner and more focused while preserving the information density required by a government portal.

eParticipation and Government Information

The portal was not only a directory of transactional services.

It also included broader government content such as:

eParticipation initiatives
policies
open data
sustainability
government information
digital transformation content

This meant the design system had to support both:

task-oriented service experiences

and

information-heavy public content.

These two content types required different presentation patterns while still feeling like one coherent portal.

Design Outcome

The project did not include a formal usability-testing phase or post-launch quantitative measurement that I can reliably attribute to the redesign.

For that reason, I do not present unverified performance metrics for this work.

The design contribution was the creation of a more user-centered foundation for the portal, including:

A research-informed audience model
Personas representing multiple population segments
A shift from ministry-based navigation toward audience- and need-based information architecture
New service discovery patterns
Service category exploration
Life-event navigation concepts
Search and filtering patterns
A redesigned service-detail structure
Accessibility considerations
Support and help-center concepts
More consistent content and interface patterns

The project demonstrated how a large public-sector digital platform can be approached not simply as a collection of government pages, but as a product serving people with very different needs, abilities, and levels of digital confidence.

What I Learned

1. Large public platforms require multiple mental models

There is no single “government portal user.”

The product must work for people with very different:

goals
capabilities
life situations
digital literacy
accessibility needs

Research becomes essential when designing at this scale.

2. Information architecture can be a product problem

For complex platforms, UI design alone cannot solve findability.

If information is organized around the wrong model, visual improvements will have limited impact.

In this project, restructuring the way services were organized was one of the most important design decisions.

3. Users should not need to understand the organization behind a service

Organizational structures are useful internally.

They are not always useful navigation systems.

Designing around user intent creates a more natural bridge between government complexity and everyday needs.

4. Accessibility benefits more than one audience

Accessibility decisions made for users with disabilities also improve the experience for:

elderly users
users with low digital literacy
mobile users
users under cognitive load
users unfamiliar with government processes

Inclusive design is not an edge case.

It improves the core product.

5. Consistency becomes more valuable as a platform grows

The larger the platform, the more important reusable patterns become.

Consistent structures help both users and product teams manage complexity.

Final Reflection

Oman.om was one of the most complex information architecture challenges I have worked on.

The project required thinking beyond individual screens and considering the portal as an ecosystem of:

people
services
government organizations
information
accessibility needs
life situations
support journeys

My main contribution was helping shift the design perspective from:

“How is government organized?”

toward:

“How do people actually look for help, information, and services?”

That shift became the foundation for the redesign.

Project Details

Product: Oman.om — Official E-Government Services Portal
Industry: Government / Public Services / GovTech
Role: Senior Product Designer
Focus: User Research, Personas, Information Architecture, Service Discovery, Accessibility, Interaction Design, UI Design
Research: Approximately 15 user interviews across multiple audience groups

Keywords:
GovTech · Product Design · User Research · Information Architecture · Service Design · Accessibility · Public Services · Multi-Audience UX · Complex Systems

Table of Contents