Designing connected 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 platform combined complex business logic, large legacy databases, role-based access, privacy requirements, and services delivered by independent squads.
External users needed journeys that remained understandable despite the complexity of the rules behind them.
Internal teams needed reliable tools to monitor automated processes, investigate exceptions, manage records, review execution history, and intervene safely when automation was not sufficient.
The challenge was to design both sides of the service ecosystem:
clear digital services for external users,
effective control tools for the teams responsible for operating them.
Technical constraints added another layer. Some preferred interaction models could not be supported safely by the existing architecture, while fully manual alternatives would create excessive operational effort.
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
My impact was not a single solution, but a set of connected improvements across administrative workflows.
☞ Make system activity visible
Administrative tools allowed users to trigger actions without sufficient visibility into planned, active, completed, or conflicting processes, even though those operations could affect millions of businesses.
I introduced a control-tower model showing process status, execution history, failures, available actions, and reasons why an operation could not run. This improved operational control without exposing unnecessary backend complexity.
☞ Support long-running processes and exceptions
Some operations required background execution rather than immediate completion.
I designed progress states, notifications, execution history, and recovery paths so administrators could leave the page, return later, and investigate or resolve failed processes.
☞ Balance scale with technical feasibility
Global bulk actions were useful operationally but could not be supported reliably by the existing backend.
I proposed a filtered bulk-action model, allowing users to narrow the dataset and apply actions to all records within the result set. This preserved operational value while remaining technically feasible.
☞ Design for permissions and privacy
Role-based visibility, controlled search, limited identifying information, and permission-specific actions provided enough context to complete tasks without exposing unnecessary data.
OUTCOMES
Complex policy and business requirements translated into actionable product scope
Customer-facing and administrative flows prepared for delivery
Control-tower concepts for process monitoring and intervention
Patterns for background execution and exception handling
Feasible bulk-operation model within legacy constraints
Role-based access and privacy patterns
Reusable interaction models across connected services
Clearer implementation documentation for Product, Engineering, and QA
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.
