Commercial Space
& Facilities Platform

Commercial Space
& Facilities Platform

Product design for a global enterprise client

Product design for a global enterprise client

A multi-module platform for managing office spaces, leases, maintenance and service requests across a distributed organization.

A multi-module platform for managing office spaces, leases, maintenance and service requests across a distributed organization.

Overview

My role: Senior Product Designer
Team: Product Manager, process owners, developers
Timeline: 1 year
Scope: Process architecture, UX flows, UI design and developer handoff across desktop and mobile experiences.

My role: Senior Product Designer
Team: Product Manager, process owners, developers
Timeline: 1 year
Scope: Process architecture, UX flows, UI design and developer handoff across desktop and mobile experiences.

The platform brings together several business functions in one enterprise environment, helping employees, administrators, tenants and contractors manage requests throughout their lifecycle.

The system includes:

  • Space Management — office space requests and cost-centre changes.

  • Commercial Leasing — lease-in and lease-out workflows, including a dedicated tenant portal.

  • Maintenance & Contractor Portal — reactive and planned maintenance, including PPM.

  • Interior Design Requests — internal requests for design and fit-out services.

  • Facilities Analytics — dashboards for SLA performance, PPM and audits.

My responsibility was to translate complex business processes into consistent, role-based experiences across desktop and mobile interfaces.

The platform brings together several business functions in one enterprise environment, helping employees, administrators, tenants and contractors manage requests throughout their lifecycle.

The system includes:

  • Space Management — office space requests and cost-centre changes.

  • Commercial Leasing — lease-in and lease-out workflows, including a dedicated tenant portal.

  • Maintenance & Contractor Portal — reactive and planned maintenance, including PPM.

  • Interior Design Requests — internal requests for design and fit-out services.

  • Facilities Analytics — dashboards for SLA performance, PPM and audits.

My responsibility was to translate complex business processes into consistent, role-based experiences across desktop and mobile interfaces.

The Challenge

Space and facilities management across headquarters and multiple locations relied on emails, call-centre interactions and offline coordination.

This created three major problems:

Limited visibility
Teams lacked a unified view of request status, making it difficult to identify delays and understand who needed to act next.

Limited SLA transparency
Although contractor agreements defined service-level requirements, SLA compliance was not systematically tracked throughout the request lifecycle.

The platform also had to support approximately 19 user roles, each with different permissions, location access and responsibilities.

The challenge was to create a consistent experience without designing a separate interface for every role and module.

Space and facilities management across headquarters and multiple locations relied on emails, call-centre interactions and offline coordination.

This created three major problems:

Limited visibility
Teams lacked a unified view of request status, making it difficult to identify delays and understand who needed to act next.

Limited SLA transparency
Although contractor agreements defined service-level requirements, SLA compliance was not systematically tracked throughout the request lifecycle.

The platform also had to support approximately 19 user roles, each with different permissions, location access and responsibilities.

The challenge was to create a consistent experience without designing a separate interface for every role and module.

Context & Key Insights

Before designing the interfaces, I mapped the existing business rules, data dependencies and operational constraints.

Existing business rules shaped the experience.
HRMS supplied employee and cost-centre data, while the Service Matrix defined contractor assignment and SLA requirements based on work type, location and request class.

Different roles required different experiences.
Back-office teams worked with dense tables, filters and task queues. Contractors needed a simpler interface focused on individual tasks and quick actions in the field.

Exceptions were part of the main workflow.
Requests could be returned, reclassified, reopened or put on hold. These were legitimate process branches, not edge cases.

Key insight: The platform needed a shared request lifecycle across modules, combined with role-specific permissions and workflows.

Before designing the interfaces, I mapped the existing business rules, data dependencies and operational constraints.

Existing business rules shaped the experience.
HRMS supplied employee and cost-centre data, while the Service Matrix defined contractor assignment and SLA requirements based on work type, location and request class.

Different roles required different experiences.
Back-office teams worked with dense tables, filters and task queues. Contractors needed a simpler interface focused on individual tasks and quick actions in the field.

Exceptions were part of the main workflow.
Requests could be returned, reclassified, reopened or put on hold. These were legitimate process branches, not edge cases.

Key insight: The platform needed a shared request lifecycle across modules, combined with role-specific permissions and workflows.

My Approach

Process first, screens second

Process first, screens second

I worked with process owners and business analysts to establish a shared taxonomy of request statuses, workflow phases and exception paths before moving into detailed UI design.

The common process model followed four phases:

Request Initiation → Assignment → Execution → Closure

This provided a consistent foundation for multiple modules while preserving their specific business rules.

I worked with process owners and business analysts to establish a shared taxonomy of request statuses, workflow phases and exception paths before moving into detailed UI design.

The common process model followed four phases:

Request Initiation → Assignment → Execution → Closure

This provided a consistent foundation for multiple modules while preserving their specific business rules.

A modular system, not separate mini-products

A modular system, not separate mini-products

I established reusable patterns for the product shell, request cards, status indicators, tabs, lists and filters.

Each module retained its own fields and workflow requirements, while familiar structural patterns helped users navigate the platform consistently.

I established reusable patterns for the product shell, request cards, status indicators, tabs, lists and filters.

Each module retained its own fields and workflow requirements, while familiar structural patterns helped users navigate the platform consistently.

Designing around roles and context

Designing around roles and context

I considered how the same request would be created, approved, executed and monitored by different users.

This meant designing not only individual screens, but also the relationships between roles, permissions, process states and available actions.

I considered how the same request would be created, approved, executed and monitored by different users.

This meant designing not only individual screens, but also the relationships between roles, permissions, process states and available actions.

Key UX Decisions

One status model across modules

One status model across modules

I established a shared request lifecycle:
Submitted for review→ Review in progress → Rejected/Returned/Waitlisted → Approved

The same status indicator was used across request types, allowing users to understand progress without learning a different status system for every module.

The model also provided a consistent foundation for implementation and future module development.

I established a shared request lifecycle:
Submitted for review→ Review in progress → Rejected/Returned/Waitlisted → Approved

The same status indicator was used across request types, allowing users to understand progress without learning a different status system for every module.

The model also provided a consistent foundation for implementation and future module development.

SLA tracking with controlled pauses

SLA tracking with controlled pauses

The Put on Hold action pauses the SLA timer and notifies the responsible team.

This accounts for legitimate delays, such as waiting for site access or replacement parts, while keeping the pause visible to the people responsible for the request.

The goal was to make SLA tracking reflect the actual process rather than treat every delay as a contractor failure.

The Put on Hold action pauses the SLA timer and notifies the responsible team.

This accounts for legitimate delays, such as waiting for site access or replacement parts, while keeping the pause visible to the people responsible for the request.

The goal was to make SLA tracking reflect the actual process rather than treat every delay as a contractor failure.

Role-based visibility within one interface

Role-based visibility within one interface

Different roles see different data according to their responsibilities.

For example, Department Admin users can access their assigned locations, while operational teams such as the Call Centre, Security and Maintenance Team can access a broader set of locations.

This approach supports multiple permission models within a shared interface instead of requiring a separate application for each role.

Different roles see different data according to their responsibilities.

For example, Department Admin users can access their assigned locations, while operational teams such as the Call Centre, Security and Maintenance Team can access a broader set of locations.

This approach supports multiple permission models within a shared interface instead of requiring a separate application for each role.

A reusable request structure

A reusable request structure

I defined a common request-card structure with consistent headers, status indicators and tabs for Request, Comments and Attachments.

The pattern was reused across Cost Centre Change, Office Space Request, Interior Design Request and Maintenance workflows, with module-specific fields changing as needed.

This established a familiar interaction model while keeping the underlying UI system modular.

Mobile designed for on-site work

Mobile designed for on-site work

The desktop Contractor Portal supports dispatchers managing task queues, while the dedicated mobile version is designed for contractors working on-site.

Instead of shrinking the desktop form, I structured task completion as a step-by-step workflow:

Location & Materials → Work Checklist → Documents / Photos → Task Details → Confirmation

Key actions were placed in a bottom-sheet menu, and the mobile experience supported updating task status and capturing photos directly from the device.

Shared status indicators and task identifiers maintained continuity between desktop and mobile.

The desktop Contractor Portal supports dispatchers managing task queues, while the dedicated mobile version is designed for contractors working on-site.

Instead of shrinking the desktop form, I structured task completion as a step-by-step workflow:

Location & Materials → Work Checklist → Documents / Photos → Task Details → Confirmation

Key actions were placed in a bottom-sheet menu, and the mobile experience supported updating task status and capturing photos directly from the device.

Shared status indicators and task identifiers maintained continuity between desktop and mobile.

Product / UI

Contractor Portal| Desktop

Contractor Portal| Desktop

The desktop experience supports task assignment, scheduling and queue management, giving operational teams an overview of work across requests and contractors.

Contractor Portal| Mobile

Contractor Portal| Mobile

The mobile experience focuses on completing an individual task in the field, with a guided workflow, quick actions and access to photos and supporting documents.

Space Management

Space Management

Office space requests and cost-centre changes follow the shared request structure while retaining their own business-specific fields and approval steps.

Interior Design Request

Interior Design Request

A dedicated workflow supports internal design and fit-out requests within the same platform architecture.

Facilities Management & Analytics

Facilities Management & Analytics

Operational dashboards provide visibility into maintenance activity, SLA performance, PPM and audit reporting.
Across these modules, the shared UI patterns create a consistent experience without forcing every workflow into an identical form.

outcome

The design established a consistent interaction model across multiple enterprise workflows, user roles and device contexts.

Key design outcomes included:

  • A shared request lifecycle and status language across modules.

  • Reusable request structures and UI patterns for different business processes.

  • Role-based access and location visibility within a common interface framework.

  • A dedicated mobile workflow for on-site contractor tasks.

The resulting design provided a structured foundation for implementation across the platform while accommodating the distinct needs of employees, administrators, tenants and contractors.

The design established a consistent interaction model across multiple enterprise workflows, user roles and device contexts.

Key design outcomes included:

  • A shared request lifecycle and status language across modules.

  • Reusable request structures and UI patterns for different business processes.

  • Role-based access and location visibility within a common interface framework.

  • A dedicated mobile workflow for on-site contractor tasks.

The resulting design provided a structured foundation for implementation across the platform while accommodating the distinct needs of employees, administrators, tenants and contractors.

key takeaways

Complex enterprise UX starts with process architecture.
When multiple roles and modules share the same business processes, statuses, permissions and data relationships need to be defined before detailed UI design.

Consistency comes from intentional reuse.
A shared interface structure helps users build familiarity across modules and gives developers a common foundation, provided that reusable patterns are validated against real workflows.

Business rules need to become usable interactions.
SLA requirements, returns, reclassification and legitimate pauses cannot remain abstract rules. They need to be represented as clear, manageable actions within the user journey.

Complex enterprise UX starts with process architecture.
When multiple roles and modules share the same business processes, statuses, permissions and data relationships need to be defined before detailed UI design.

Consistency comes from intentional reuse.
A shared interface structure helps users build familiarity across modules and gives developers a common foundation, provided that reusable patterns are validated against real workflows.

Business rules need to become usable interactions.
SLA requirements, returns, reclassification and legitimate pauses cannot remain abstract rules. They need to be represented as clear, manageable actions within the user journey.

Projects

Self-service portal

Wellness app & Oracul

SalaryGuide online

Admin panel

Business Class Digital

Design system

Projects

Self-service portal

Wellness app & Oracul

SalaryGuide online

Admin panel

Business Class Digital

Design system

Projects

Self-service portal

Wellness app & Oracul

SalaryGuide online

Admin panel

Business Class Digital

Design system