Unify the customer task
Municipal services can be fragmented by department, terminology and channel. Customers need to know which service fits their situation, what to prepare and what happens after submission. A coherent portal therefore needs more than a consistent visual surface.
The project focuses on the shared portal/mobile experience: service discovery, onboarding, request visibility and incident reporting. Trade-service products, the Seven-Star readiness initiative and reusable design frameworks have their own separate cases.
Research that shaped the experience
Explore the study plan, customer accounts and the recurring findings behind the Portal Unification direction.
Understand the task before choosing the solution
The study starts with the customer’s goal, the channel they choose and the obstacles they encounter. Its instruments distinguish professional, represented and individual service use.
Read the research plan analysis
Plan the research around channel choices and real tasks
The discovery plan asks why customers choose a channel, how they complete municipal tasks, what makes a request urgent and which information they need before acting. It also investigates awareness, motivation and recurring friction across the service journey.
Coverage includes government employees, business owners or employees, representatives such as PROs, individuals and service officers. Recruitment spans the website, app, WhatsApp, web chat, call centre and service-centre visits, with direct and represented customers considered separately.
The methods combine a proposed survey, in-depth interviews, short service-centre interviews and task walkthroughs. Separate scripts support business/consultant and individual contexts. The plan records consent for interview recording and anonymous handling of responses.
| Research question | Evidence sought | Decision it informs |
|---|---|---|
| Why this channel? | Preference, perceived speed, familiarity and task suitability | A channel role based on customer value |
| How does the task work today? | Walkthroughs, obstacles, handoffs and recovery | Journey structure and priority interaction states |
| What needs a fast response? | Urgency, expected resolution and support behaviour | Support routing and clear response expectations |
| What is hard to find? | Service names, requirements and missing guidance | Search, service cards and the help taxonomy |
| What would make digital useful? | Motivation, trust, awareness and unmet needs | Adoption hypotheses to test |
The drafts contain several provisional sample scenarios. A survey of 300 is subject to statistical confirmation; interview drafts refer to 24 or 40, and recruitment matrices contain 63 or 105 slots. These are planning alternatives, not completed participant totals.
Compare different customers and channels
Recruitment crosses customer segments with channels. The analytics request adds a quantitative perspective to investigate alongside the interviews.
Read the coverage analysis
Make recruitment coverage and data requests explicit
The recruitment matrix crosses customer segments with channels so that the team can compare different contexts rather than assume all customers behave alike. The pack contains an earlier 63-slot matrix and a later 105-slot alternative; neither establishes the actual number recruited.
The analytics request seeks month-by-month evidence from January 2024: channel traffic, incidents, service requests, most-used services, active users and dormant users. These requests define what the team wanted to investigate; the board itself does not contain those measured results.
| Requested data | Research use |
|---|---|
| Channel traffic and engagement | Understand reach, repeated use and channel preference |
| Incident and service-request volumes | Locate the tasks and service demand each channel handles |
| Most requested services and reported incidents | Focus research and scenarios on consequential tasks |
| Active and dormant users by month | Investigate adoption and return-use patterns |
Draft sample scenarios are kept separate from completed research activity and unique participant counts.
Different tasks reveal different experience needs
Professional users need reliable document and approval workflows. Urgent requests need visible follow-up. Everyday customers need clear preparation and access to the result.
The keyword is X. If I knew the thing that I need, what is its name, searching for it is easier.
Read the customer insights analysis
Qualitative discovery and the reported research activity
The previously documented September phase reports eight service-centre interviews and twelve in-depth interviews or walkthroughs. Those activity counts remain separate from the new recruitment drafts and the number of pages in the insight document.
The research pack combines customer accounts with a heuristic review of navigation, guidance, content structure, hierarchy, feedback and recovery. The original research findings are the baseline for the experience direction, while the opportunity statements identify changes to investigate.
Read the customer accounts before consolidating them
The supplied twelve-page customer-insight document records different needs across professional and individual service use. Its page count is a document property, not proof of twelve additional unique participants.
Professional users describe document-heavy work, service terminology, approvals, receipts and repeated follow-up. Individual service accounts include fishing-licence discovery, document gathering, preference for mobile access and difficulty viewing an issued document.
The evidence also includes positive and contrasting experience. Some routine applications worked smoothly once the required documents were available. Some people preferred the portal for complex work, while others wanted the convenience of the app. The design response therefore needs a clear task and audience context.
| Customer context | Reported friction | Experience need |
|---|---|---|
| Professional, document-heavy work | Large uploads, repeated submissions and payment uncertainty | Reliable desktop workflows, document context and clear confirmation |
| Consultant or construction-service user | Exact service names needed; return reasons were unclear | Intent-based discovery and actionable reviewer feedback |
| Project owner | Limited visibility of consultant/contractor submissions | Shared status and understandable responsibility |
| Representative managing company tasks | Dependence on owner access and difficulty maintaining profiles | Reviewed delegation, roles and visible update outcomes |
| Urgent operational request | Digital follow-up perceived as slower than calling | Acknowledgement, status and an appropriate escalation route |
| Individual, everyday service | Guidance found elsewhere; issued documents unavailable in the preferred channel | Clear preparation guidance and access to the result |
Supplied customer-insight notes. Reported technical issues are customer accounts, rather than independently verified engineering diagnoses.
The reported discovery activity remains eight service-centre interviews and twelve in-depth interviews or walkthroughs. These are activity counts, rather than a summed unique-customer total.
Turn recurring friction into experience priorities
The synthesis links discovery, preparation, permissions and post-submission visibility. Interface improvements sit alongside service, policy and integration opportunities.
Read the consolidated findings analysis
Consolidate the recurring themes into a service problem
Across the notes, friction extends beyond the interface: unclear requirements lead to appointments or visits, weak status visibility leads to repeat calls, and fragmented systems lead to repeated submissions and uncertain ownership.
The consolidated board groups those patterns into redesign opportunities. It supports a coherent problem statement: help the customer discover the right service, prepare confidently, act with the correct permissions and understand what happens after submission.
Recommendations such as workflow flexibility, document reuse, better integration and faster support still need the relevant service, policy and engineering owners. They are kept separate from the original interface designs and completed delivery evidence.
| Consolidated theme | Customer consequence | Design or service priority |
|---|---|---|
| Service discovery and terminology | Search requires prior knowledge of the service name | Goal-based entry, useful labels and guided discovery |
| Requirements and regulatory guidance | Customers visit or book an inquiry before they can start | Preparation information, examples, FAQs and contextual help |
| Rigid flows and repeated documents | Additional work across approvals or systems | Review rules and handoffs; validate reuse and continuity |
| Payments and receipts | Uncertainty about the transaction or its application | Clear payment status and a findable receipt record |
| Request status and service history | Calls and visits are needed to understand progress | Next action, responsibility and accessible request history |
| Support and urgent exceptions | The customer changes channels to obtain a response | Visible support routes, acknowledgement and escalation |
| Channel fit and issued documents | Switching channels interrupts completion | Define each channel’s task coverage and access to the outcome |
The board contains opportunities. It does not prove every recommended feature was released or that an outcome improved.
Connect the findings to a specific experience decision
The Portal Unification designs below make parts of the research direction tangible: a restaurant-opening guide starts from intent, service cards expose requirements, and Help and Support gives questions a usable structure.
Account recovery and profile changes address access and feedback. Workflow flexibility, receipt integration, shared status and delegation require additional service or engineering validation. A designed interface does not by itself prove those operating changes shipped.
| Evidence theme | Relevant case artifact | What to validate next |
|---|---|---|
| Exact service names are hard to know | Restaurant-opening guide and service discovery | Find the relevant journey from a customer goal |
| Requirements are hard to prepare | Service-detail and permit-selection screens | Understand the required documents and applicable permit |
| Support information is scattered | Help and Support landing and topic category | Find a useful answer and recognise when human help is needed |
| Account actions need clear feedback | Recovery and profile-change sequences | Complete the access/update task and recognise its outcome |
| Submission ownership and status are unclear | Request visibility and service-history direction | Identify who acts next and retrieve the same request |
| Repeated submissions and payment uncertainty | Service and integration opportunity backlog | Check rules, data ownership and end-to-end task reliability |
Keep the prototype test as its own measured baseline
The October prototype test asked eight people to sign up or log in, choose preferences, navigate the incident catalogue and report a stray dog. Five completed the mission and three dropped off. Screen-level evidence concentrated the next design work on category selection and incident selection, alongside onboarding. The category screen recorded a 75% misclick rate and about 67 seconds of dwell time; the incident list recorded 67% and about 81 seconds. These are screen-level observations from the formative test.
The documented average task time was 250.2 seconds. The mission concerned incident reporting; it does not validate every restaurant-guide or account-management screen shown in this case.
Formative task evidence from the original research record. Five completions out of eight and the screen-level observations describe the tested prototype, rather than a measured post-redesign improvement.
Connect the audit to the design decisions
The source assessment reviews the homepage, account access, registration, dashboards, service menus, submission and payment. It groups issues by usefulness, information architecture, navigation, visual presentation, interaction and performance.
Dense regulatory content and fragmented entry points made service discovery a priority. Weak feedback and contextual help made recovery and task continuity part of the experience work, alongside the visual redesign.
The supplied funnel excerpt reports about 205,683 authorisation-page visits and roughly 69,000 onward visits. That is a historical diagnostic signal. It does not establish the cause of each exit or a post-redesign improvement.
Translate service complexity into usable content and structure
The redesign connected UX and UI decisions to the service explanation, rather than treating interface styling as the full solution.
The service-card principles specified what a customer needed before starting: a visual procedure, required documents and examples, fees and when they apply, eligibility, related services, understandable terms, contextual support and practical FAQs. The content model addressed the research finding that uncertainty often drove a physical visit.
The unified design-system work covered tokens, themes, interactions, responsive behaviour, patterns, components, accessibility and content standards. Its purpose was to make the same service logic recognizable across channel interfaces and to reduce repeated decisions during implementation.
The resulting experience work included service discovery, dashboard and request tracking, account access and business administration. The customer guide documented UAE Pass, existing-account linking, business registration, verification, profile updates and company user management. That guide is evidence of the support and handoff work around the product.
| Customer question | Required experience content |
|---|---|
| What must I do? | Procedure, journey steps and the action required at each stage. |
| What must I prepare? | Document requirements, examples and where to obtain them. |
| Can I use this service? | Eligibility and relevant terms in understandable language. |
| What will it cost? | Fees, timing and payment guidance. |
| What happens after I submit? | Confirmation, progress, next action and contextual support. |
Portal service-card principles, design-system foundation and customer guide
A service finder that starts with the customer’s intent
The design distinguishes a standalone service card, a guided journey across services, and a customisable selection. This gives the portal a way to explain both a simple request and a business goal that spans several approvals.
The restaurant scenario shows the design logic in concrete form: capture the goal, ask relevant questions, then return a structured journey with requirements and help. The screens demonstrate the proposed interaction, rather than a live AI implementation.
The homepage offers search and service categories.
Search opens in context, without sending the customer to another system.
“I want to open a restaurant” becomes the starting point for guidance.
The guide asks whether the customer is considering opening or already running a business.
Location and premises context narrow the required journey.
A further condition helps shape the personalised guide.
The result groups the next steps, documents and support around opening a restaurant.
Original prototype screens. Use the steps or arrow keys to inspect the sequence, then enlarge a screen for detail.
Make the requirements usable before the application
The service-detail design places procedures, documents, fees and conditions in a structured page. A permit-type chooser makes the decision explicit before the application begins.
This is the connection between content design and interaction design: explain the service in plain language, expose the relevant choice, and offer a clear next action.
Scroll to explore the full design. Open the viewer to zoom.
Design for the actual conditions of use
Mobile designs include English and Arabic onboarding, location search and denied-permission states, nearby/new incident entry and evidence attachments. These states make the service understandable beyond its ideal path.
Language, permission and recovery decisions must work together. A person who denies location access still needs an understandable route forward; a person adding incident evidence needs to know what information is expected.
Explore the mobile states side by side. Scroll within the incident list, or open any screen to zoom.
Treat account recovery as a complete journey
Recovery is a sequence of choices and confirmations, rather than a single reset form. The design covers the account type, permission boundary, recognised verification destination, code entry, new password and final confirmation.
Each state should answer what the user needs to do next and what happened to the previous action. Permission messages and masked contact details in these screens are prototype behaviour, subject to security and implementation review.
UAE Pass and account sign-in share a clear entry point.
Forgotten-password and company-admin password tasks have distinct choices.
The prototype explains who may reset a company user’s password.
Masked SMS and email destinations help the user recognise a recovery route.
The code step includes timing and a resend action.
The new-password step keeps the requirements near the task.
Success gives the user an explicit route back to login.
Original prototype screens with masked or example contact data. They do not establish the current authentication policy.
Keep routine profile changes clear and consistent
The profile flow uses inline edit, verification and success feedback for mobile and email changes. Reusing the same pattern reduces the number of interaction rules a customer has to learn.
The surrounding layout retains account context and access to documents. The selected screens use demonstration account content.
Inline editing preserves the surrounding account context.
A verification dialog separates identity confirmation from the edit.
A success message confirms the saved change at the place the user expects it.
The same interaction pattern supports the email task.
Consistent feedback makes the end of the task recognisable.
Original design prototypes. Names, addresses and account values shown are demonstration content.
Organise support around real questions
The help taxonomy covers account access, delegation, payments, document handling, service-specific workflows and troubleshooting. It gives support content an information structure that can grow with the service catalogue.
The supplied help-page designs turn that taxonomy into a searchable support landing page and an account-management category. The design goal is a useful answer at the relevant moment, with a visible route to human support.
Scroll to explore the full design. Open the viewer to zoom.
Scroll to explore the full design. Open the viewer to zoom.
Connect design intent to delivery
Feature mapping, release planning and account-support material connect the experience to the teams implementing it. My broader Municipality responsibilities include backlog prioritisation and sprint/release decisions.
This case focuses on the applied customer experience. The full product-development SOP, governance framework, accessibility guides and PoD initiative are shown separately rather than mixed into the portal narrative.
Retest the task and follow the service after submission
A comparable retest should use the same task definition and report completion, wrong turns, time, effort and help needed. Discovery questions, prototype measures and production service measures answer different questions.
The research suggests additional service measures: first-submission completeness, avoidable return reasons, status-related contacts, receipt retrieval and access to issued documents. These are measurement priorities to operationalise with data owners, rather than achieved KPI improvements.
The supplied planning files do not include a completed survey dataset or matched post-redesign result. The case therefore retains its original baseline and shows the new evidence as research detail and design rationale.
Customer needs evidenced in the research
Need profiles synthesised from the supplied notes. These describe task contexts; they are not additional research participants or a validated demographic persona set.
Document-heavy professional
- Goal
- Complete permit and submission work accurately
- Friction
- Uploads, returns and receipts are difficult to manage
- Experience need
- Clear requirements, reliable submission and transaction context
Representative
- Goal
- Manage authorised company tasks
- Friction
- Access depends on another person and updates are hard to track
- Experience need
- Reviewed roles, delegation and explicit update feedback
Urgent operational customer
- Goal
- Get a critical request acknowledged and resolved
- Friction
- Digital status and follow-up are unclear
- Experience need
- Visible expectations, status and an appropriate support route
Everyday service user
- Goal
- Find guidance and access the issued result
- Friction
- Preparation and document access require a channel switch
- Experience need
- Preparation checklist, saved progress and a findable outcome
Complete portal homepage
Scroll to explore the full design. Open the viewer to zoom.
Outcomes and learning
Centre and in-depth interviews in the documented research phase
Participants in the separate prototype test
Task completions in that formative baseline
The work establishes an original research baseline, a coherent service-discovery direction and designed bilingual interaction states. Post-change usability and production outcomes remain distinct from that baseline.
Unification works when the product model becomes coherent—not only when the screens look consistent.
About the evidence
- Original 2024 interview and prototype-test reports, Portal/mobile Figma designs, feature mapping and delivery plans.
- The research is a team project record. Individual execution of every interview or screen is not claimed.
- Original project materials supplied in October 2026. Excerpts are integrated into the project story; targets and concepts are distinguished from released outcomes.
- October 2026 addition: a five-page planning pack, twelve pages of customer-insight notes and one consolidated insight board, supplied specifically for Portal Unification. File titles also mention the app because this research covers related municipal channels.
- The planning pack contains multiple sample alternatives (including 63/105 recruitment slots and a provisional survey target of 300). These are not completed participants or survey results.
- Customer quotes are recorded in the supplied insight notes. Raw interview recordings/transcripts were not supplied for this addition; anonymous source excerpts and task-level synthesis are used.
