AMPS Lean UX Workshop

Design strategy for the platform that keeps PG&E's grid inventory honest

Role Lead Product Designer at World Wide Technology

Type Design strategy · Facilitated discovery

Evidence 83-page workshop record, retained

Measurement None retained; experiments handed off with pre-specified success criteria

Overview

Co-facilitator and breakout room coach on a five-day virtual Lean UX workshop for Pacific Gas & Electric's Asset Management Platform & Services (AMPS), the tool PG&E uses to inventory network, hardware, software, database, and bulk electric system cyber assets and hold NERC federal compliance. Eleven participants (stakeholders, subject matter experts, and AMPS users), worked through the full Lean UX arc in June and July 2022. I coached the ENOC Analyst breakout and co-authored the workshop record.

The Challenge

AMPS provided the basic functionality to maintain PG&E's asset inventory, but as asset information matured, the tasks of adding, managing, and monitoring assets grew cumbersome enough that users exported the data and worked elsewhere. Every export made the system of record staler, eroding trust in the data and the product, and putting grid safety and NERC compliance at risk. The engagement's job was not to redesign AMPS; it was to establish, with the people who own and use it, which improvements were worth building at all, and to teach a human-centered method PG&E could keep using.

Approach

Pre-workshop, we ran a structured problem-framing exercise with the sponsor and SMEs to land an approved product problem statement, and collected 20 business and user assumptions, each rated for value and risk. In the workshop, two breakout teams built proto-personas (Sean, a Telecom Engineer stewarding asset data, and Jason, an ENOC Analyst triaging outages), mapped their journeys, and marked the ten moments that matter most. Journey mapping surfaced a consistent emotional signature: relief on task resolution, anxiety wherever confidence in the data thinned. Teams converted assumptions into 19 hypotheses, each written with its cheapest viable test and a pass condition, then rigorously prioritized them to a top ten. A Design Studio session, rescheduled a week out after a real network outage pulled participants into response duty on the final morning, produced the sketches we refined into storyboards and wireframes for two concepts: Data Stewardship, and the Incident Impact Diagram.

Storyboard panels 1.4 through 1.6 of Sean's data stewardship narrative, ending with a thank-you note from a colleague who has not hit an incomplete asset record in days. — Storyboards translated the winning hypotheses into narratives PG&E could test with real users.

01 From journeys to a ranked backlog

Journey map for Sean, a Telecom Engineer persona, with an emotion curve crossing five numbered moments that matter. Green peaks mark verified statuses and meetings; red troughs mark repeated asset reviews and unexpected markups, each annotated with a quote and a business impact. — Where confidence in the data thins

Breakout A mapped the Telecom Engineer’s week and marked the five moments that matter, each carrying the quote that fixed it and the business impact behind it. The signature is consistent: relief at resolution, anxiety wherever the record might be wrong. The highest peak is a verified status in Service Onboarding; the deepest trough is another pass through the asset tabs.

untested Page 13 of the retained workshop record, mapped by the Telecom Engineer breakout from the participants’ own account of their work. The persona is a proto-persona, an archetype the room agreed on rather than a research finding, and nothing on the curve was sampled or validated.

Workshop page introducing the top ten prioritized hypotheses drawn from both breakout teams, with the first three set out in full (Incident Command, Diagram, and Accuracy scores), each pairing a business outcome, a user, a feature, and the test that would settle it. — Ten hypotheses, each with the test that would settle it

Rigorous prioritization merged both breakouts’ 19 hypotheses into a ranked ten, by risk and perceived value. Every one names a business outcome, a user, a feature, and the condition that would count as a pass: #2 wanted half an hour off standard resolution time, provable by a Remedy query, passing when a participant could articulate an incident’s total impact in under five minutes. #3’s target is still an unfilled “X mins”.

untested Page 36 of the retained workshop record; the first three of the ten are set out in full. The pass conditions were written before any test existed, which is what made them worth handing over; but they were fixed in a workshop deck, not registered, and no result against any of them is retained here.

02 Concept: Incident Impact Diagram

Storyboard panels 2.4 through 2.6 of Jason's incident diagram narrative: he identifies a failed network switch from the impact diagram, traces connected devices upstream and downstream, and tags them into an impact report. — Jason's outage, before it was a screen

Panels 2.4 to 2.6 of the ENOC Analyst narrative: a failed switch at a San Jose site named from the diagram, the devices above and below it traced, each one tagged into an impact report as he goes. The story was written first, so the concept had to answer to what an analyst does during an outage rather than to a layout.

untested Page 45 of the retained workshop record; Design Studio sketches from Jason's breakout, refined into storyboards. A narrative of intended use; nobody had used it.

Wireframe of the incident diagram on a laptop frame: a vertical network topology on the left with the failed application and server marked in red, and on the right the selected asset's record (the Gas Meter App, its line of business, MCP, CPUC compliance requirement and incident history), beside an ownership list of four named roles, each with a checkbox, and an empty Bridge Team column. — What broke, and who to call, in one view

Selecting the failed node opens it beside the topology: the application, the line of business it serves, the CPUC requirement attached to it, what has gone wrong with it before, and the four people who own it, each with a checkbox for pulling them onto the bridge. Hypothesis #2 put a figure on what that was worth: half an hour off standard resolution time.

untested Wireframe 1.7, page 56 of the workshop record. The hypothesis behind it also fixed its test: a participant identifying and articulating an incident's total impact in under five minutes. PG&E was handed the test; no result from it is retained here.

Wireframe one step further into the incident diagram: the selected switch, SW Data Center 01, lists its child connections (STARCOM01 marked Impacted, STARCOM02 Inactive), and its parent connections (RTR_Datacenter_01 marked Not Impacted, RTR_Datacenter_02 Inactive), with an Attach action on the node and one owner's initials now showing in the Bridge Team column. — Tagging the blast radius

The same incident, one step on. Every connection above and below the failed switch carries its own verdict (impacted, not impacted, inactive), and Attach pulls it into the incident; the owners checked on the right start appearing as the bridge team. The impact report assembles while the topology is being read, rather than after.

untested Wireframe 1.9, page 58 of the workshop record. Concept work handed off at the close of the engagement; this archive holds no record of what was built from it.

03 Concept: Data Stewardship

Wireframe of the data stewardship concept in AMPS: the Applications list on the left with Columbus Asset Data Tool selected, and a details panel open beside it, tabbed General, BIA, Ownership, DR, Network, Infrastructure, Certification and Feedback, showing 229 deployed production servers under Infrastructure. — The details panel stops closing

The deepest trough on Sean's journey map is reviewing assets tab by tab; “Why are there repeating rows for assets?” Here the application list stays put while the record opens beside it, tabbed by layer, so working through one application's 229 production servers is scrolling rather than navigation.

untested Wireframe 1.2, page 50 of the workshop record, refined from the Telecom Engineer breakout's Design Studio sketches. That it closes the loop is the workshop's argument from Sean's journey map, not a measured result.

Outcome

PG&E left with a ranked backlog of ten testable hypotheses, half of which pointed at integrations with systems like Remedy rather than at screens, a scoping insight the workshop surfaced before any build spend. The storyboards and wireframes gave them artifacts to run the riskiest experiments against, and a second, funded phase of work followed.

Measurement note

The hypothesis ratings, prioritization, and concept artifacts are preserved in the retained 83-page workshop book, and the figures here come from that record. No outcome measurement exists: the experiments were handed off with pre-specified success criteria and run, if they were run, after my involvement ended. The funded second phase is stated from my own account of the engagement; no scope document for it is retained in this archive.