DHCA Service Ecosystem — Case Study

/01 — Project overview

A complex ecosystem, one connected experience.

Dubai Healthcare City Authority operates a complex ecosystem that supports organisations and professionals across business setup, leasing, licensing, regulatory approvals, facility preparation and ongoing operations.

Although many individual services were already available digitally, customers still experienced the overall journey as fragmented. Different stages were managed by different departments, systems and external authorities. Customers often had to understand the organisation's internal structure before they could work out what to do, where to go or who was responsible for the next step.

As Service Design Lead, I helped the project team understand this end-to-end ecosystem, identify the structural causes behind customer friction and translate the evidence into a future-state service vision.

The work covered the public website, leasing, licensing through the MASAAR portal, fit-out approvals, permits to work and ongoing operational services.

/02 — The challenge

The customer journey looked sequential. It wasn't.

The customer journey appeared sequential from the outside:

Find a space
Establish a business
Obtain a licence
Prepare the facility
Begin operations

Internally, however, these stages were delivered through separate commercial, regulatory and operational functions.

Leasing was managed through a dedicated commercial process and CRM. Licensing was managed through MASAAR. Fit-out and Permit to Work involved engineering, asset management, health and safety, security, contractors and other approval teams. Some stages also depended on external authorities.

Each function had its own process, ownership model, terminology and system logic.

Current-state journey diagram 5 stages · 4 systems · multiple owners

Each stage was owned by a different team, system or authority — but customers saw a single journey.

This created several recurring customer problems:

Customers did not always know where their journey started.
Status updates were too generic to explain what was happening.
Ownership became unclear when a case moved between teams.
Customers were asked to provide similar information more than once.
Commercial commitment could begin before regulatory feasibility was fully understood.
Transitions between leasing, MASAAR, licensing, fit-out and Permit to Work were not always visible.
Customers had limited guidance on what they could prepare while waiting.
Escalation often happened outside the digital journey through emails, calls and personal contacts.

"The problem was therefore larger than the usability of a single website or portal. It was an ecosystem-level service design challenge."

/03 — My role

Leading the service design across the project.

I led the service design work across research synthesis, journey analysis, strategic framing and future-state experience design.

Synthesising customer research, surveys, interviews and operational evidence
Reviewing Standard Operating Procedures and internal process documentation
Mapping the end-to-end customer and organisational ecosystem
Developing customer personas and journey maps
Creating service blueprints across major service areas
Identifying pain points, root causes and capability gaps
Conducting regional and international benchmarking
Connecting customer experience findings with technical and operational constraints
Facilitating alignment around cross-functional service problems
Defining service design principles and strategic recommendations
Translating recommendations into future-state journeys, information architecture and conceptual wireframes
Supporting the executive narrative and stakeholder presentation

A key shift I drove

Helping stakeholders move from discussing isolated pain points to understanding the relationships between systems, processes, ownership and customer expectations.

/04 — Understanding the service ecosystem

DHCA didn't operate a single linear journey.

The experience consisted of three interconnected layers that were connected, but not always synchronised.

01

Commercial layer

Leasing enquiries, property options, viewings, offers, reservations, payments and lease progression.

02

Regulatory layer

Business setup, licence applications, security clearance, professional and commercial approvals, external authority requirements and compliance documentation.

03

Operational layer

Fit-out, engineering reviews, contractor readiness, Permit to Work, inspections, renewals, payments and ongoing compliance.

A customer could be progressing commercially while waiting for regulatory confirmation. A licensing application could trigger engineering or external authority sub-processes. A completed licence could lead into fit-out and Permit to Work journeys managed by different teams.

The service therefore needed to support continuity across organisational boundaries rather than treating each transaction as an independent digital service.

End-to-end ecosystem process map 3 layers · multiple hand-offs · external dependencies

The end-to-end ecosystem process map. Each layer connects to the next, but the connections are not always visible to the customer.

/05 — Research & evidence base

Grounded in three perspectives, not one.

Customer interviews and survey findings
Four behavioural customer personas
Five current-state journey maps
Six operational Standard Operating Procedures
Pain point, root cause and gap analysis
Technical assessment findings
Regional and international benchmark reviews
Five detailed service blueprints
An end-to-end ecosystem process map
Existing information architecture analysis
Stakeholder feedback and working sessions

The research allowed us to compare three perspectives:

A

What customers believed should happen

B

What operational teams were responsible for delivering

C

What the current systems actually enabled

The most significant service gaps appeared where these perspectives did not align.

/06 — Key findings

Where the experience broke.

01

The experience was organised around internal functions rather than customer intent

The public website and portal reflected organisational categories, departments and service structures. Customers, however, arrived with goals such as "I want to establish a healthcare business" or "I need a space for my facility" — and often needed to interpret internal terminology before finding the right starting point.

02

Digital processes did not create an end-to-end digital experience

Several individual transactions were available online, but customers still relied on email, phone calls and manual follow-up to understand the overall journey. The organisation had digitised many processes, but the experience itself was not yet fully orchestrated.

03

Status information lacked operational meaning

Generic labels such as "Pending" did not help customers understand progress. A pending status could mean waiting for payment verification, under security clearance, with an external authority, waiting for an engineering review, missing documentation, awaiting an internal approval, or ready for the customer's next action — all hidden behind one word.

04

Ownership became invisible during handoffs

Many problems appeared when a case moved between teams or systems. The customer could see that something was happening but not necessarily who was responsible for moving it forward. This ownership ambiguity increased follow-up calls and made escalation dependent on personal relationships rather than a defined service pathway.

05

Customers were not sufficiently prepared for upcoming stages

The service typically focused on the customer's current transaction. Customers also needed guidance about what would happen next — during leasing they could prepare licensing information; during licensing they could begin organising contractor details, drawings or external approvals. Without forward visibility, customers waited passively and only discovered new requirements after completing the previous stage.

06

The highest-risk moments were transitions, not individual forms

The most significant experience failures often occurred between services — website to leasing, leasing to MASAAR, reservation to licensing, licensing to engineering, commercial licence to fit-out, fit-out to Permit to Work, approval to ongoing compliance. These handoffs were vulnerable to inconsistent data, unclear responsibilities, duplicate requests and mismatched customer expectations.

/07 — Reframing the problem

From a website redesign to an ecosystem challenge.

Initial framing

Website redesign & portal usability

An interface-level problem. Improve navigation. Clean up screens. Add help text.

Reframed

Ecosystem-level service orchestration

DHCA did not primarily lack digital services. It lacked a visible orchestration layer connecting its commercial, regulatory and operational services.

Rather than proposing that all functions should be merged into one system or owned by one team, we focused on creating a coherent experience across existing organisational boundaries. The objective was not to remove the distinction between leasing, licensing, engineering or compliance — these functions have different legal, operational and commercial responsibilities. The objective was to make their relationship understandable to the customer.

/08 — Design principles

Six principles that guided the future-state.

01

Design around customer intent

Navigation and service entry points should reflect what customers are trying to achieve, rather than requiring them to understand the organisation's internal structure.

02

Make the journey visible

Customers should see their current stage, completed stages, upcoming stages and key dependencies across the wider journey.

03

Make ownership explicit

Every significant stage should indicate which team, authority, contractor or customer currently owns the next action.

04

Explain status in operational language

Statuses should describe what is happening and why, rather than using generic labels.

05

Prepare customers for what comes next

Customers should receive forward-looking guidance, readiness checklists and parallel preparation tasks.

06

Protect cross-system handoffs

Transitions should include validation of customer details, controlled account creation, data confirmation and visible handover responsibility.

/09 — Design response

How the strategy became a service.

01

A clearer public website and discovery experience

The public website was repositioned as the front door to the wider DHCA ecosystem. The proposed information architecture prioritised major customer intentions: set up a business, explore leasing opportunities, access MASAAR, find a healthcare facility, understand licensing and regulation, and connect with the community and partnerships.

Each service entry point was designed to clarify who the service was for, what the customer needed, who owned the process, which system or channel would be used, and what would happen after starting. This created a clearer transition from public information into transactional journeys.

Future-state IA · homepage wireframe

02

A visible leasing journey

The future-state leasing experience introduced a single journey view covering enquiry submitted → viewing scheduled → offer accepted → reservation confirmed → MASAAR activation → lease active. Customers could see their current stage, the owner of the current action, expected processing time, required actions and documents, payment status, key customer and company details, the next stage of the journey, and support and escalation options.

This was particularly important around reservation. A reservation is a commercial milestone, but customers could interpret it as confirmation that the wider regulatory journey had been approved. The proposed experience clarified the difference between commercial commitment and regulatory approval while making the upcoming licensing transition visible.

Leasing journey wireframe

03

A controlled leasing-to-licensing handoff

We did not recommend merging leasing into MASAAR because the two services represented different commercial and regulatory functions. Instead, the design introduced a validated handoff layer. Before MASAAR activation or licensing initiation, critical customer information could be confirmed: authorised signatory, email address, passport or identity details, company information, intended activity, and relevant leasing information.

This reduced the risk of incorrect account creation, identity mismatch and payment reconciliation issues being carried into the regulatory journey. The customer would also receive a clear explanation that leasing had reached a specific milestone and that licensing was now beginning as a connected but separate process.

Handoff validation flow

04

Stage-level licensing visibility

The proposed MASAAR experience replaced broad status labels with meaningful stage-level updates, such as payment awaiting finance validation, security clearance in progress, external authority approval requested, engineering review in progress, final documents required, notarisation scheduled, or commercial licence ready for issuance.

Each status could answer four questions: what is happening, who owns the next step, does the customer need to act, and what happens afterwards. This transformed the portal from a transaction repository into a journey guidance tool.

MASAAR stage-level status UI

05

Readiness before submission

The future-state licensing concept introduced three modes: Prepare → Review and Submit → Track. Before submission, customers could use a readiness checklist showing completed requirements, missing documents, documents under validation, requirements that did not apply, upload actions, outstanding external approvals, and submission deadlines.

This reduced uncertainty before submission and created an in-portal pathway for resolving missing or rejected information. The concept also helped distinguish between documents that were technically uploaded and an application that was genuinely ready for review.

Readiness checklist UI

06

Clearer fit-out and Permit to Work journeys

Fit-out and Permit to Work were often perceived as one process, although they served different purposes. Fit-out confirms that a proposed design has been reviewed from an engineering and asset perspective. Permit to Work confirms that physical work can be performed safely by the correct contractor, within the approved scope and under the required safety controls.

The proposed experience clarified this distinction and guided customers from one stage into the next when both were required. Customers could see whether fit-out, Permit to Work or both were required, the current approval stage, the responsible team, contractor registration status, required drawings and method statements, safety documentation, inspection readiness, upcoming actions and dependencies, and escalation routes.

Fit-out & PTW journey map

07

Persona-based future-state validation

Four behavioural personas were used to test whether the future-state service supported different experience needs — from the efficiency seeker who wanted quick renewals, to the escalator who became active when progress stalled. The personas confirmed that the design was not based on one idealised customer journey.

4 persona cards

/10 — Future-state personas

Validating that the design works for everyone.

Four behavioural personas — each with different needs, different risk tolerance, and a different relationship to the service.

A

The efficiency seeker

Routine, speed, low friction

This customer wanted to complete routine activities quickly, particularly renewals and ongoing operational tasks. The future state prioritised saved information, clear requirements, quick validation and minimal repeated effort.

B

The uncertainty-sensitive applicant

Reassurance, milestones, guidance

This customer needed reassurance during high-risk transitions such as reservation to licensing. The future state prioritised stage visibility, clear distinctions between commercial and regulatory milestones and guidance on what happened next.

C

The visibility seeker

Detail, ownership, dependencies

This customer was comfortable completing complex tasks but needed to understand ownership, dependencies and progress across fit-out and Permit to Work. The future state prioritised detailed tracking, parallel preparation and clear responsibility.

D

The escalator

Escalation, accountability, history

This customer became increasingly active when progress stopped or information became inconsistent. The future state prioritised meaningful status explanations, defined escalation pathways, contact history and accountable ownership.

/11 — Deliverables

A connected set of strategic & design outputs.

The outputs were designed to work together — the ecosystem map established structure, research identified problems, blueprints revealed dependencies, recommendations addressed root causes, and wireframes showed how the strategy becomes a real experience.

End-to-end service ecosystem map

Customer personas

Current-state journey maps

Service blueprints

Pain point & root cause analysis

Cross-journey opportunity map

Benchmarking analysis

Existing & future-state IA

Design principles

Journey-specific recommendations

Future-state experience maps

Conceptual wireframes

Executive transformation narrative

Prioritised implementation roadmap

/12 — Outcome

A shared strategic view of the customer ecosystem.

The work created:

A clear articulation of the end-to-end customer problem
A service model connecting commercial, regulatory and operational journeys
Evidence-based priorities for improving transparency and ownership
A future-state vision for the public website and MASAAR
Practical concepts showing how recommendations could be implemented
A foundation for future product, process and governance decisions

"It shifted the conversation from improving isolated screens to designing continuity across teams, processes and systems."

As the recommendations had not yet been fully implemented during the engagement, the value of the project was represented through the clarity of the strategic direction, the alignment created across stakeholders and the implementation roadmap provided to the organisation.

/13 — Reflection

Complex services cannot be improved by interfaces alone.

This project reinforced that complex digital services cannot be improved by focusing only on interfaces.

The most important customer problems often sit between screens, systems and departments.

A well-designed application form cannot compensate for an invisible handoff.
A progress tracker cannot create confidence if the underlying status has no clear owner.
A website cannot feel simple if customers must first understand the organisation's structure.

The role of service design was therefore to connect customer needs with operational reality.

The final vision did not attempt to make every journey identical or place every service into one platform. Instead, it created a coherent experience across specialised functions by making the journey, ownership, status and next steps visible.

That shift — from digitising individual processes to orchestrating the complete service experience — was the central design contribution of the project.