Embedded Files
Smart
SUMMARY
SUMMARY
0→1 design and delivery of a platform that acts as a 'system of systems' for large mixed-use spaces & campuses
A building technology company had a proven Smart City platform with 60+ deployments.
But a distinct segment was emerging in the pipeline it couldn’t serve: master developers of mixed-use communities who needed mission-critical operations capability at estate scale, without city-scale complexity or cost.
I led the UX to build this platform from 0-to-1.
Outcomes
🚀
~30% reduction in Average MTTR (pilot project)
🍃
-12% reduction in energy consumption (pilot project)
🌟
3 Projects won
My Contribution
I led a team comprising of mid-level UX and UI designers
Helped identify and defined the community-scale segment as distinct from the existing city offering
Led research and interviews; synthesised findings in product & design rationale
Helped define solution architecture
Designed and ran formative testing studies
Led creation of a composable dashboard design system
Led IA, interaction design, and UX writing across all operator and management interfaces
Stakeholder management: Worked closely with product, engineering and sales
Mentored mid-level designers through end-to-end delivery while remaining hands-on across all workstreams
PROCESS
PROCESS
THE FOUNDATIONAL PROBLEM
THE FOUNDATIONAL PROBLEM
We identified a gap that justified a new product. The goal was to move stakeholders from ‘can we just simplify the existing platform’ to ‘this is a categorically different design problem.’
> A category mismatch, not a feature gap
Mixed-use community operators were not running broken technology. Most had functional subsystems: BMS, SCADA, VMS, access control, street lighting, irrigation. The problem was structural. These systems operated independently, there was no unified operational picture, and connecting the dots across them during an incident was entirely manual.
At the same time, operations rooms at these sites bore no resemblance to city command centres. Leaner teams, shared spaces, fewer screens but the same volume of subsystem complexity to manage. Enterprise interfaces designed for dedicated multi-screen control rooms were a cognitive liability in this context.
“When something goes wrong in Zone C, I’m switching between three systems just to understand what’s happening. By the time I’ve pieced it together, ten minutes are gone.”
— Operations Supervisor, field interview
///
RESEARCH &
KEY FINDINGS
RESEARCH &
KEY FINDINGS
User interviews
Field visits
RFP analysis
Competitive review
Three findings that shaped the design direction
Finding 1
> Command centres are much leaner
Ops teams at community-scale sites were leaner and more generalist than enterprise models assumed. Multi-screen, data-heavy interfaces weren’t just impractical; they were a liability. The interface needed to deliver situational awareness at a glance, not after navigation.
Finding 2
> Each subsystem was an island
Customers had functional subsystems. The gap was that nothing talked to anything else. An incident touching two systems required two separate investigations. Cross-domain pattern recognition was entirely dependent on individual operator experience, with no platform support. The core value of a new product wasn’t replacement; it was integration.
Finding 3
> Intelligence was buried and expensive to retrieve
Operational reporting consumed 3 to 5 hours of weekly manual effort from a mid-level analyst. Senior decision-makers were working from data already 48 to 72 hours stale.
“I spend half my Monday pulling together a report my director looks at for four minutes.” — Operations Analyst, discovery interview
///
/
/
SOLUTION ARCHITECTURE
SOLUTION ARCHITECTURE
Rather than designing feature-by-feature, I anchored the information architecture to three operational domains derived from the research.
Three domains. One coherent system
1. Facility Operations
the physical and systems backbone, covering asset management, maintenance workflows, IoT and BMS integration, energy monitoring, workforce coordination, and alerting.
2. Operator Intelligence
the insight and control layer, surfacing unified system health, cross-domain KPIs, anomaly detection, and the AI-assisted features that replaced manual reporting and ticket creation.
3. Tenant and Occupant Experience
the human layer of the community, covering tenant onboarding, service requests, visitor management, community communications, and amenity access.
Cutting across all three: an Interaction Layer (role-appropriate surfaces per persona), a Workflow Layer (approvals, escalations, compliance logic), an Intelligence Layer (KPI engines, anomaly detection, predictive models), and a Data and Integration Layer (unified schema connecting BMS, ERP, CRM, and third-party subsystems).
/
/
DESIGN EXPLORATION & VALIDATION
DESIGN EXPLORATION & VALIDATION
The starting hypothesis: the existing City Suite platform could serve this new segment if sufficiently simplified.
Round 1
Three failure points emerged consistently:
Operators struggled to locate incidents spatially using the text-based alert system
The resolution workflow consumed the full screen, eliminating peripheral awareness at exactly the wrong moment
The underlying cognitive model was mismatched. The City Suite had been built for alert management at inter-departmental level. Community operators usually workflows are more informal, and require greater involvement in resolution procedures
Round 2
Reorganised the interface around a spatial model, mapping alerts to physical locations and introducing a map view of the campus. The reaction was qualitatively different.
“As soon as I could see it on the map, I knew what I was dealing with. I didn’t need to read anything.”
— Facility Operations Manager, prototype test session
Operators built situational awareness faster and with noticeably more confidence than they had with the alert-driven model. Two further findings shaped the final design: operators consistently wanted site-wide visibility while resolving an incident, which drove the split-context layout; and operators began repositioning and resizing panels unprompted, which became the direct brief for the composable dashboard system.
///
/
/
FINAL UI
FINAL UI
> Map-centric operator interface
The central design was interface paradigm with a spatially-grounded interface.
For operators managing a physical environment, location is the primary navigation model — not system category. Operators locate incidents by where they are. They dispatch by physical proximity.
Throughout tests, operators using the spatial interface located incidents and navigated to relevant camera feeds measurably faster than those using textual alert details.
Testing also validated a 2.5D god’s-eye view over both flat 2D maps and full 3D rendering: enough spatial depth for rapid orientation without the performance overhead. Full 3D digital twin was retained as an opt-in, partner-powered capability for customers requiring it.
> AI as an operational accelerator
We scoped AI it tightly against validated pain points. Three touch-points were prioritised:
Smart Highlights: auto-surfaced cross-domain summaries for management, eliminating the manual reporting cycle consuming 3 to 5 hours weekly.
Incident Summaries: context-compiled briefs drawing on sensor data, asset history, and prior work orders, so operators have a coherent picture without manually assembling it.
AI-Assisted Work Orders: suggested tickets pre-populated with asset history, likely fault type, and required equipment. Technicians arrive prepared; first-time fix rates improve.
> A composable dashboard design system
Research confirmed that operators want to customise their workspace: reorder, resize, and configure widgets to match their role and shift. Product and engineering wanted to solve this narrowly per screen, citing speed-to-ship. My position was that bespoke layouts would create a fragmented experience and a compounding maintenance liability as the product grew.
We resolved the tension by phasing delivery. The core widget set shipped in release one, with the composable architecture in place to extend it. The design system now underpins every dashboard surface in the product.
WHAT I’D DO DIFFERENTLY
WHAT I’D DO DIFFERENTLY
The platform tried to serve too many personas at full depth from the start. Built Space Operations, Tenant Experience, and Operator Intelligence are each substantial enough to be a product in their own right. In hindsight, I would have pushed harder for a sharper initial scope: validate the operator core deeply with one customer segment before expanding into the tenant-facing and AI layers.
This wasn’t purely a design failure; it reflected broader pressure to demonstrate range to prospects. But the consequence was a first release that spread design and engineering effort too thin. Some flows, particularly in the tenant experience domain, shipped at a lower fidelity than the operator interface. A more disciplined sequencing argument, made earlier and with clearer evidence, would have produced a stronger v1 and a more confident foundation for what came next.
Page updated
Google Sites
Report abuse