No headings foundSelect the Frame that wraps your article content → open Accessibility → set Tag to main, article, or section.This message disappears as soon as headings are detected.

Designing 6 interconnected services for a government platform

Role

Company

Timeline

Product Management & UX

NDA – MENA gov platform

2025

Scope of work

Service design · Enterprise workflows · Admin tools · Stakeholder alignment · Legacy systems · Cross-functional collaboration

CONTEXT

I worked across six interconnected government digital services used by businesses, administrators, and internal operations teams.

The work involved translating complex policy, business rules, and technical constraints into clear product behaviour across customer-facing services and internal operational tools.

My role combined product discovery, service design, interaction design, administrative panels, control towers, permissions, system states, validation, and cross-functional delivery with Product, Business Analysis, Engineering, and QA.

CHALLENGE

The main challenge was designing within a complex legacy system where user needs, policy requirements, technical constraints and operational rules often overlapped.

Typical complexity included:

  • multiple user roles with different permissions and visibility

  • interconnected services sharing data and dependencies

  • validation rules and system states across long workflows

  • bulk and individual actions

  • scheduled, automated and manual process paths

  • edge cases driven by policy or legacy architecture

  • conflicting requirements from different stakeholders

The interface had to make this complexity understandable without hiding rules users genuinely needed to act on.

The core challenge became:

How do we turn fragmented business, policy and technical requirements into coherent end-to-end workflows across multiple connected services?

DISCOVERY

I led requirement and alignment meetings with Product Owners, Business Analysts, engineers, QA, and domain stakeholders.

These sessions were used to translate policy and business requirements into:

  • customer and administrative flows,

  • system states,

  • role-based permissions,

  • validation rules,

  • dependencies,

  • edge cases,

  • failure and recovery scenarios.

Discovery also included:

  • service-flow mapping,

  • system-state modelling,

  • permissions analysis,

  • technical feasibility reviews,

  • cross-squad alignment sessions,

  • stakeholder reviews.

I facilitated decision-making when user needs, operational requirements, privacy, and technical feasibility pointed in different directions.

Potential solutions were assessed according to user value, business and policy requirements, operational efficiency, privacy, performance risk, implementation effort, technical feasibility, and consistency across connected services.

SOLUTION

I designed workflows around the full service logic, not individual screens.

The work included:

  • role-based visibility and permissions

  • complex multi-step flows

  • validation and error handling

  • bulk and filtered actions

  • scheduled and automated processes

  • system states and notifications

  • edge cases and recovery paths

  • consistent interaction patterns across services

I translated business and policy requirements into implementation-ready flows that Engineering and QA could work from, while keeping the experience coherent for users moving between services.

Where possible, I also pushed for shared patterns so similar problems were not solved differently across the platform.

OUTCOMES

The main outcome was a more coherent and implementation-ready product model across 6 interconnected services, with clearer relationships between roles, states, actions and dependencies.

Because the project operated within a large legacy environment, the value was not only in individual UI improvements, but in reducing ambiguity across Product, Design, Engineering and QA before implementation.

REFLECTION

Designing public services requires continuous translation between policy, operations, technology, and user needs.

The strongest solution is not always the ideal interaction considered in isolation. It is the solution that preserves the most important value while remaining feasible, stable, and appropriate for the wider system.

This project strengthened my ability to manage complex stakeholder environments and balance desirability, viability, and feasibility within regulated and legacy-based systems.