Resource Monitor System
Enterprise platform focused on workforce planning, intelligent resource allocation, defect issue tracking, and operational visibility.
Enterprise SaaS
Operational Intelligence
Type
UX & Motion Designer
Scope
8 weeks
Platform
2 Enginners, 1 PM, me
Domain
Enterprise Web Platform
A global resource management platform designed to simplify operational scheduling through intelligent matching, workflow visibility, and motion-driven product storytelling.
Concept case study reimagining a real enterprise platform. Client identity and proprietary details anonymised.
Role | UX & Motion Designer |
|---|---|
Scope | User Research · Design Principles · Lottie Animations · High Fidelity |
Platfrom | Web · Tablet · Mobile |
Industry | Enterprise field-service operations |
Duration | June 2024 - Dec 2024 |
Overview
The system in one breath
A global hardware manufacturer installs complex equipment across customer sites worldwide.
Each install needs a certified engineer, in the right location, within a tight window, without burning the budget on travel or overloading the same few people.
That coordination used to live in spreadsheets, email threads, and people's heads. RMS (Resource Monitor System) replaces that with one connected platform: it pulls from every relevant data source, auto-matches engineers to installs, and produces a travel plan the whole org can trust. I owned both the product experience and the motion-driven product story.
The hard part was never the data. It was making a global, multi-constraint scheduling problem legible so a planner could look once and know what to do.
Objectives & Goals
Target audience
RMS serves three distinct user groups inside a global hardware organisation. Each has a different relationship with the system, a different device, and a different definition of success.
Research
Qualitative research
Before a single screen was drawn, I mapped the real workflow not the idealised version. The goal was to understand where value was lost, not just what features were missing.
Existing solutions audit
Before designing anything, I audited what people were already using to do this job. For an internal enterprise tool, the "competition" is not other companies it is the existing alternatives users relied on before RMS existed. Understanding why those tools failed is what made the design decisions defensible.
Tool / Approach | What it was use for | Why it Failed |
|---|---|---|
Excel / Google Sheets Highest friction | Main planning tool every cycle. Used to track engineer assignments, availability, and travel windows manually. | Out of date by mid-cycle. No live data, no constraint checking. One person's version never matched another's. |
Email & Outlook High friction | Used for overrides, escalations, and approvals between planners, managers, and engineers. | No audit trail. Context lost at every handoff. Decisions buried in threads nobody could search |
ERP / SAP Partial coverage | Source of truth for engineer profiles, certifications, customer data, and financials. | Not built for scheduling. No matching logic. Data existed but had no connected, actionable view. |
Generic field-service tools Low adoption | Tried in some regions for install tracking and dispatch. | No cert matching, no travel cost logic, no fairness distribution. The things that mattered most weren't there. |
Tribal knowledge Highest risk | Senior planners making decisions from memory, bypassing any system entirely. | Single point of failure. Invisible to leadership. When the person left, the knowledge left with them. |
Key findings
Visibility is the real product - The org already had all the data. The pain was that it lived in five different places. Nobody had a single view of who was free, certified, and geographically sensible.
Handoffs are where things break - When ownership changed from planner to engineer to manager context got lost. Issues were missed because nobody owned the in-between state.
Fairness was invisible and eroding trust - The same reliable engineers kept getting the hard, long-travel assignments. There was no mechanism to surface or correct this imbalance and people noticed.
Planners were human API calls - Every planning cycle required manually cross-referencing four systems. The planner wasn't making decisions they were doing data reconciliation.
"I spend the first three hours of every planning cycle just figuring out who's even available. By the time I get to the actual matching, I'm already exhausted."
— Resource Planner, interviewed during research
Define
User personas
Three distinct roles use RMS in fundamentally different ways, at different times, with different needs. Designing for all three meant fitting one system to three moments of use.
Empathy map — Maya (primary persona)
Built from interview notes to ground design decisions in real behaviour, not assumptions.
Problem statement
Resource planners at global hardware manufacturers need a way to match certified engineers to customer installations across regions satisfying constraints of cost, certification, proximity, priority, and fairness simultaneously because the current process of manual cross-referencing across disconnected systems is unsustainable, error-prone, and invisible to the wider organisation.
How might we…
HMW show a planner whether a plan is "good" before they commit to it?
HMW surface certification conflicts before they become scheduling failures?
HMW make workload fairness visible and correctable without extra effort?
HMW give field engineers enough advance notice to plan their lives?
HMW let managers see risk early enough to actually change the outcome?
Ideate
User flows
Six flows cover every path a user takes through RMS from auto-generating the plan to an engineer checking their mobile. Each flow was mapped before a single screen was designed.
Information architecture
Organised around three core mental models who is available, what needs doing, and where & when with a dashboard that surfaces the most urgent answer to "what needs my attention?" before any drilling down.
Design principles
Propose, don't just store - The system suggests the best match first. The planner stays in control but starts from a smart default not a blank grid.
One source of truth - Every data source the org already trusted flows into one place, so the plan always reflects operational reality.
Make trade-offs visible - Cost, fit, certification, and fairness are shown as signals on every assignment never buried in a post-cycle report.
Same platform, three contexts - Planners on desktop, managers on tablet, engineers on mobile. One system, fitted precisely to each moment of use.
Design
Style guide
A restrained enterprise design language confident typography, semantic colour, and a component library built to scale across new workflows without re-designing from scratch.
High fidelity
Designed responsive, across three contexts
Each screen is fitted to its moment of use the planner's command centre, the manager's quick review, and the engineer's on-the-go view.
Click on the images to view Figma File
Before & after
Results & Impact
What it was designed to move
RMS was built to shift four measurable outcomes that the old manual process could not. These are the intended impact goals the design was built around directly traceable to the research findings above.
Stated benefits from stakeholders
Maximise customer coverage and satisfaction the right engineer reaches every site within the SLA window.
Save costs domestic and regional matching is surfaced first; long-haul travel becomes the exception, not the default.
Reduce manual effort for planners the plan proposes itself; the planner makes judgment calls, not data-entry calls.
Ensure fair and equal distribution of work among engineers workload is surfaced, visible, and correctable before the plan ships.
Reflections
What I'd carry forward
In enterprise UX, visibility is the feature. The org already had the data the win was arranging it so one person could hold a five-constraint decision in their head and feel confident.
Designing the product and motion together changed both. If something was hard to animate, it was probably hard to understand a useful test.
Designing for complexity doesn't mean simplifying the domain it means making the complexity manageable. Those are very different things.
