THE ARCHITECTURAL PIVOT
During the project, I identified a critical flaw in the infrastructure plan. The consultants were delivering static data files (ArcINFO coverages)—a literal "snapshot in time." Because the city's infrastructure is constantly changing, I knew that without a multi-user editing platform, this massive data delivery would be obsolete the day it launched.
The Problem:
Static ArcINFO coverage files could not support concurrent editing across departments. The moment the data was delivered, infrastructure changes would begin rendering it out of date—making the entire investment fragile and short-lived.
The Advocacy:
I successfully advocated for PWD to execute a sub-contract, extending the consultant's scope to translate these coverages into relational Geodatabases. This architectural pivot was crucial: it allowed for concurrent editing across departments, ensuring the system could actually keep up with the city's ever-growing backlog of infrastructure changes.
GIS Data Architecture Overview
The shift from static file deliveries to a live relational Geodatabase wasn't just a technical upgrade — it was a fundamental change in how the city could maintain its infrastructure data long-term.
- ArcINFO coverages were a point-in-time snapshot, unable to be edited concurrently
- Geodatabases enabled multi-user editing across departments simultaneously
- The system could now absorb the city's ongoing infrastructure changes without becoming stale
SERVING THE DATA
Data is only valuable if people can access it. To solve the challenge of serving heavy spatial data in a browser, I spearheaded the technical research and recommended Autodesk MapGuide as our foundation. I co-authored the RFP to secure a consultant for the initial build of the Engineering Records Viewer (ERV)—a secure intranet app deployed behind the PWD firewall. Following the successful launch, I apprenticed with the external developers to take over the codebase, ultimately acting as the sole maintainer and developer extending the app's capabilities as user needs evolved.
The Platform:
The Engineering Records Viewer (ERV) was a secure intranet web application deployed behind the PWD firewall, purpose-built to surface live geodatabase content to non-GIS staff across the department.
The Users:
Engineers, water records personnel, and city managers previously reliant on paper records or specialist GIS staff could now self-serve accurate, current infrastructure data directly from their desks.
The Impact:
By centralizing access through the ERV, we eliminated the bottleneck of routing every data request through GIS specialists — freeing up expert bandwidth and accelerating decision-making city-wide.
Engineering Records Viewer (ERV)
The ERV transformed how the city interacted with its own infrastructure data. Key capabilities included:
- Multi-layer map viewing of water mains, valves, and service connections
- Real-time data pulled directly from the live Geodatabase
- Secure access controlled behind the PWD firewall
- Queryable by address, asset ID, or geographic area
MY METHODOLOGY: UX BEFORE I KNEW THE TERM
The technical challenge was significant, but the human challenge—asking engineers to abandon decades-old paper workflows—was the real hurdle. Three deliberate strategies drove adoption across the department: (1) User Research (2) An Ambassador Network (3) Transparent Roadmapping
Deep User Research
Deep User Research
I didn't just help maintain the application; I went directly to the user base. I conducted continuous user interviews to understand exactly how different departments needed to query the data to do their jobs.
This meant sitting with engineers during their workflows, understanding what they were trying to find, and translating those needs back into ERV features and query configurations — the same practice I now apply to every enterprise product I design.
Building an Ambassador Network
Building a 'Power User' Network
To drive adoption, I identified "ERV Ambassadors" within different departments. I trained these power users first, allowing them to advocate for the system and provide localized feedback, easing the cultural shift.
Peer-to-peer advocacy proved far more effective than top-down mandates for a team of engineers who trusted colleagues more than IT directives.
Transparent Roadmapping
Transparent Roadmapping
Enterprise apps are never "finished." To manage expectations and frustration over missing features, I created a Project Improvement Form (PIF) system. Users could submit requests, and I maintained a transparent, public timeline of when those features would be deployed.
This gave users agency and visibility — transforming frustrated complainers into engaged stakeholders who felt heard and invested in the system's success.
LESSONS LEARNED
This experience is the foundation of my UX philosophy today. It taught me that enterprise software isn't just about the interface; it is about building scalable architecture, managing complex data, and ensuring that users feel heard and supported through massive technological shifts.
Architecture Precedes Interface:
A beautiful UI built on a brittle data model will fail. The most impactful design decision I made at PWD wasn't a screen — it was advocating for Geodatabases over static file exports.
Adoption Is a Design Problem:
Shipping the ERV was not the finish line. The real work was the human work — understanding workflows, building champions, and creating transparent feedback loops that gave users a sense of ownership.
Scale Demands Systematic Thinking:
250,000 documents and 6,620 miles of pipe cannot be managed by heroics. Scalable systems — geodatabases, Ambassador networks, PIF pipelines — are the only way to keep pace with a living city's infrastructure.
Enterprise UX Starts Before the UI:
Every enterprise project I take on today, I bring this lens first. Before touching a wireframe, I ask: Is the underlying architecture set up to support the people who will use this system for the next decade?