2026 · PORTFOLIO CONCEPT

CONFIGURABLE
SERVICE
WORKSPACE.

TYPE
Portfolio concept study
ROLE
Independent Product Designer
SCOPE
Facilities-service coordination workspace
REFERENCES
Public ServiceNow, Microsoft and Salesforce documentation

WHY I EXPLORED THIS

HOW CAN SERVICE COORDINATORS ACT WITHOUT LOSING CONTEXT?

A broken lift, a water leak or a ventilation failure can quickly disrupt the working day in a commercial building. Behind each maintenance request, someone has to piece together what happened, coordinate the response and follow the work through to resolution.

I designed a workspace that brings together communications, documents and tasks so the coordinator can understand the situation and organise the next steps. This independent concept draws on public documentation; scenarios and data are fictional.

THE CHALLENGE

ONE REQUEST, MULTIPLE RESPONSIBILITIES

A maintenance incident needs one shared record, but resolving it can involve separate tasks, owners and decisions.

Keeping everything in one record makes individual responsibilities and progress harder to distinguish. Splitting the work into independent tickets risks fragmenting the context.

My challenge was to make each piece of work clear and actionable, with enough context to support a decision without overwhelming the current task — while keeping it connected to the overall request.

USER JOURNEY

SERVICE COORDINATOR JOURNEY

This is a proposed journey for an independent concept. The persona and emotional curve illustrate the scenario and assumptions to explore further.

Riley Cruz, internal service coordinator, and an eight-stage journey: triage, understand, assign, investigate, follow up, coordinate, verify and close. Rows show goals, actions, touchpoints, thoughts, an emotional curve, pain points and opportunities.

COMPETITIVE LANDSCAPE

REFERENCE PRODUCTS FOR SERVICE COORDINATION

The map compares workflow flexibility and service scope, from handling requests to coordinating work on site. The closest references are highlighted in green. Placement reflects a qualitative review of public product documentation.

COMPETITOR POSITIONINGService coordination & case managementCONFIGURABLE WORKFLOWSSTANDARD WORKFLOWSCASE & TICKETHANDLINGON-SITE WORKCOORDINATIONCLOSEST REFERENCESCreatioServiceJira Service ManagementAtlassianFreshserviceFreshworksZendeskCustomer serviceHubSpotService HubZohoDesk + FSMServiceNowCSM + FSMMicrosoft Dynamics 365Customer Service + Field ServiceSalesforceService Cloud + Field ServiceOracleService + Field Service

INFORMATION ARCHITECTURE

AN OVERVIEW, A SHARED RECORD, SEPARATE WORK TICKETS

I organised the concept into three levels, each answering a different question:

What needs attention?
Request overview
A queue of requests with priorities, statuses and deadlines helps the coordinator choose where to begin.
What is happening?
Request
The shared incident record brings together site and equipment details, communications, files, activity and linked work tickets.
What work is assigned, and to whom?
Work ticket
A defined task has its own owner, status and completion requirements, and stays linked to the request.

For example, the ventilation request contains an issue-assessment ticket assigned to Riley Cruz and a site-access approval ticket assigned to Elliot Ward. Assessment brings questions and supporting evidence together; access approval records contact and authorization confirmations. Both remain connected to the same incident.

The trade-off: separate work tickets make ownership and progress explicit, but introduce another level of navigation. The interface therefore keeps the request reference visible and provides a route back to its ticket list.

This structure connects the coordinator’s journey to the interface: the queue supports prioritisation, the request keeps context together, and linked tickets make individual responsibilities and completion requirements explicit.

KEY DESIGN DECISIONS

WORKING WITH CONTEXT

The coordinator needs to assess the whole situation before closely inspecting communications or documents. I chose two modes with a one-button switch: collapsing panels one by one adds clicks, while freely configuring the whole layout adds setup effort. Within tabs, splitters and expandable panels support detailed work without rearranging the whole screen.

Request overview
Request overview ↗
Expanded context
Expanded context ↗

Details when needed. To avoid showing everything at once, I used progressive disclosure: message or file information opens on demand, and related sections open alongside one another for comparison. Panel state persists when switching files so unexpected layout changes do not interrupt the work.

Message information on demand
Message information on demand ↗
Files alongside communication
Files alongside communication ↗

PROPOSED VALIDATION · NOT YET CONDUCTED

DOES THIS MODEL FIT THE WAY COORDINATORS WORK?

I would start with five facilities-service coordinators, asking each to walk through a recent incident: how work was divided, where context was kept and what allowed the next step to proceed. They would then use the fictional ventilation scenario to assess the evidence, identify responsibilities and decide what should happen next.

The model would be worth developing further if it reflects real coordination needs and helps participants make these decisions without guidance. I would look for three signals:

Work has the right structure
Participants can map a recent incident to a shared request and separate work tickets, with a clear reason for separating tasks. If tickets duplicate work or a checklist would be sufficient, I would simplify the model.
Context supports a decision
Participants can compare the relevant sources, explain what is known and identify what still needs checking. Side-by-side panels are one possible aid; successful assessment matters more than using a particular view. If participants still need to reconstruct context elsewhere, I would revisit how information is grouped.
The next step is clear
Participants can identify who owns the next action, what approval is outstanding and how ticket progress relates to the overall request. Confusing a completed task with a resolved incident, or overlooking a required approval, would trigger a revision of the hierarchy and dependency cues.

I would record where participants act independently, need help or reach an incorrect conclusion, and compare their explanations with their real working practices. Consistent evidence across accounts and tasks would support another iteration; recurring workarounds or mismatches would challenge the model itself. This first round would guide design decisions, without establishing productivity gains or readiness for implementation.

OPEN QUESTIONS

WHERE THE MODEL MAY NEED TO CHANGE

  • When does work need a separate owner and ticket, and when is a checklist within the request enough?
  • What context must survive a handover, an interruption or a change of responsibility?
  • Who can approve and close work, and what should block progress when related tasks are incomplete?

AI summaries and integration requirements would need separate investigation after the core workflow has been tested.