PG&E PSPS

Public Safety
Power Shutoff
(PSPS)

| PSPS
UX/UI Designer &
Data Engineer

April 2021 - May 2024
Techniques
Research, Strategy, Empathy, Design, Prototyping, Evaluation
Tools
Jira, Palantir Foundry, ArcGIS, Figma, Sketch, Microsoft Office, CoPilot, Dynatrace
Project Length
3 Years
Location
Remote/Bay Area

About the PSPS project

What is PSPS?
It stands for Public Safety Power Shutoff.

Severe weather, such as high winds, can cause trees or debris to damage equipment. If there is dry vegetation, this could lead to a wildfire. That's why PG&E might need to turn power off temporarily to keep everyone safe. This temporary outage is called a Public Safety Power Shutoff (PSPS).

Fig. 1 Learn more about PSPS at: pge.com/psps

Because of this, the PSPS division of PG&E relies on applications that serve complex data to chart and pinpoint the exact scope of the power shutoff. PG&E provides natural gas and electricity to 5.2 million households in the northern two-thirds of California, from Bakersfield and northern Santa Barbara County, almost to the Oregon and Nevada state lines.

The applications used to identify scope, report data on company assets and customers affected as well as notifying the customers during these events are the applications I supported in their design and experience.

Challenges & Issues

When it comes to the flow of PSPS application experience, the process involves 3 major steps: 1. Scoping, 2. Customer Notifications/Reports and 3. Share Portal. The challenge was to improve the user’s flow through each area of the process on three different applications each with their respective platforms listed below.

Major pain points came about managing tasks in and out of these PSPS enterprise tools together with Microsoft Office applications. Another main issue throughout each application was the inconsistency of design that resulted in unstructured information leading cluttered interfaces. Users expressed overwhelming sensory overload that made it difficult to easily adopt a process and complete tasks without the guidance of an expert.

Card image cap
1. Scoping

The Scoping Tool is used to isolate areas of the power grid, called polygons, by loading shape files and generate data payloads of the affected power lines and assets.

Card image cap
2. Customer Notifications/Reports

The Customer Notifications/Reports tool uses the affected power lines and assets data and joins customer details, location details and other medical emergency data.

Card image cap
3. Share Portal

The Share Portal uses the combined data to generate public and media reports and notifications to announce the potential of a power shutoff.

My Role

As a hands-on contributor, I was responsible for the workload of 3 product teams simultaneously. Development was structured in Agile with standard stand-up, user story grooming, business stakeholders and technical analyst daily alignment meetings. To empathize with the users, PSPS Scoping Specialists, I managed various interviews to understand existing painpoints as well as gathering feedback and auditing usability tasks for new UI designs using click-through prototypes. Design deliverables were created in Sketch and Figma then shared links posted to assigned Jira tasks while other out of scope tasks were added to the backlog. I helped improve information design by understanding the process, user needs, focusing on findability by organizing content for various roles efficiently and effectively.

As a lead, I provided the PSPS product managers and owners assessment, feedback and consultation for improving UX maturity, user-centered design practices and methods. As a PSPS applications subject matter expert in Palantir Foundry and Contour, I was tasked to organize and produce training video walkthroughs as part of the "PSPS 2023 required training" for the active event participants.

Fig. 2

Agile/SAFe Methodologies

Application development was set in an Agile workflow for all teams. While the framework was Agile, the process was more of a combination with Waterfal where limited time and resources made it difficult for iterating on features that had been pushed to production. The development was set in 2 week sprints that was planned by stakeholders and IT teams in quarterly PI planning.

Discovery

UX Maturity

When asked, "How do we improve the user experience for our products?", I immediately queried how much focused user-centered design was being applied in the product and feature design process. Before my involvement, the PSPS Applications Business and IT stakeholders consisting of the Directors, Product Managers, Owners and Analysts had come to the point in time they needed to improve the user experience for the PSPS products and the team brought me in to help.

To objectively understand where the PSPS product teams were in UX Maturity, I turned to the NNGroup as reference to the UX Maturity Model to measure the PSPS products' user-centered design practices across teams. This model determines which of the 6 stages an organization is at in their efforts as seen in Fig 6 below. Before gathering the data, I asked the stakeholders involved to share what Stage of the UX Maturity Model they thought their individual product team was currently at. To then gather the data for the assessment, I utilized a combination of Microsoft tools to poll and survey the teams and to present the findings.

When I initially asked for the team to share what Stage they thought their product was at, all combined the teams guessed they were at Stages 4-5 in the UX Maturity Model out of 6. When the actual results were gathered and combined as a whole, it became clear there was a need for more user-centered design practices within the existing processes each product that was evaluated. The actual score based on their data had the group as a whole at Stage 2.

Similarly, for Business stakeholders, I applied the McKinsey Design Index that measures how focused design practices affect business success. Using this index, the PSPS products measured low in the 4th quartile with a 33 total MDI score out of 100. Helping business stakeholders understand how investing in good design practices correlates with improved financial performance can be a good motivating factor in buying into more user-centered design practices.

PSPS Product Teams UX Maturity Scores

Stage 2 - Limited
UX Maturity Model
4th quartile - 33 total MDI score
McKinsey Design Index
Fig. 4 UX Maturity Model Analysis
Fig. 5 Methods of Evaluation
Fig. 6 The NN/g UX Maturity Model
Fig. 7 McKinsey Design Index (MDI)

Strategies - UX Workshop

To start applying more user-centered design practices, I conducted a UX and UI workshop that provided various methods of generating ideas and solutions. I also wanted to create a sense of collaboration that allowed everyone to feel empowered with these practices by developing user empathy.

Fig. 8 UX Standards and Practices
Fig. 9 Methods Used
Fig. 10 Planning
Fig. 11 Integration into Agile

Discovery & Strategy Highlights

Plan
Align business requirements with UX Design practices and UI patterns by including a UX stakeholder.
Create
Design mockups and prototypes for new features and products to user needs.
Feedback
Identify areas of improvement as described by both users and business owners.
Integrate
Enable lean design integration in Agile and SAFe development methodologies.

Getting To Know The User

Personas

During onboarding and training, comments from the Product Managers, Owners and the Director were that the application was "confusing", "cluttered" and needed overall consistent design improvements. While I performed cognitive walkthroughs during onboarding on all products and documented heuristic evaluations, the interviews from actual users, the PSPS Scoping Specialists, validated the assumptions.

I gathered as much qualitative data by conducting general and feature-specific user interviews tailored for each application. Data was organized in Excel allowing me to store feedback and rank and sort the issues by priority and severity.

User's Journey

The visual graphic below shares the journey of a PSPS Tech Specialist during a PSPS event. It follows the user's journey from the time there is a potential severe weather forecast and lists the tasks and experience the user goes through within each step in the PSPS event Scoping and Notifications/Reports process.

To outline and visualize the user journey, I shadowed PSPS Tech Specialists during annual PSPS Full-Scale Event (FSE) exercises that spanned for an entire week and evaluated task-based walkthroughs during moderated usability exercises gathering qualitative feedback along the way.

Key Findings

Assumptions were validated as the majority of the users primarily wanted to reduce cognitive load from inconsistent design and UI interaction patterns across their workflow. Other major pain points users thought were important were the length of time it took for page loads and some processes as well as the lack of system feedback and knowing where they are at in the process.

User Interface

Inheriting Design Challenges

The biggest design challenge I faced was helping transition some Product Owners and Business Analysts from driving and making design decisions. It required more effort to create additional mockups and slides to demonstrate different approaches that would eventually perform better with business users. I encouraged collaboration in user-centered design practices for new tools and features by involving stakeholders in planning and work sessions.

While newer design processes were fully adopted, I still had to work within the same design process helping mock up screens and prototypes for developers. In some tools, content had started to be added endlessly on to their page, so I audited and performed heuristic evaluations on the UI for each product, atomically organizing and sorting content and features. From the hands-on design tasks perspective, I also inhereted Sketch files in poor organizational state to work with while setting up a proper design system to use. Even though most of the features in the Scoping tool were custom components, the previous designer was creating UI elements each time over for every UI design task instead of reusing components within a design system. Taking on the task of building the PSPS product design systems took a lot of effort, but proved worth it and collectively took about a quarter of an Agile development calendar.

The figures below show a few examples of the inherited Scoping and Notifications/Reports tools I was tasked to help improve.

Fig. 14 Heuristic Evaluation for PSPS Scoping Tool
Fig. 15 Heuristic Evaluation for PSPS Scoping Visualizer
Fig. 16 Heuristic Evaluation for PSPS Customer Notifications/Reports Tool
Fig. 17 Heuristic Evaluation for PSPS Communications Dashboard

Information Design

The interface and navigation was overwhelming so to help reduce the cognitive load, I audited and outlined all content within each page to identify hierarchy as well as relationships between information, functions and navigation flows. I collaborated with Business and Product owners to validate a leaner navigation structure.

I was responsible for restructuring and documenting content by transferring knowledge into the Atlassian Confluence portal. There, I was able to use the tree structure helping to easily outline the application content structure and demonstrate UI and other features with screenshots, video walkthroughs and other visual support. This effort was a great win for onboarding new team members.

Fig. 18 Product Documentation
Fig. 19 Product Documentation

UI Design, Components and Patterns

To aid in rapid prototyping, I had to set up a design system for the Scoping and Notifications/Reports tools. The Scoping tool is a custom application utilizing the Material UI framework and the Notifications/Reporting tool from Panatir Foundry uses Blueprint. Both design systems are based on the Atomic Design Framework where its methodology creates interfaces from building blocks to build components and patterns.

Part of this task was not only to build and set up reusable components and patterns to improve my workflow, but also to improve visual consistency between the two applications. The Scoping tool layout was reconfigured to match the Notifications/Reporting tool and colors were updated for brand purposes. Business users expressed the need for a dark mode UI option for situation room use during PSPS events so the design system had to support both light and dark mode.

With tools and features being added, the design system included visual dashboard components, patterns for system processes and annotations. For making interactive prototypes, components also consisted of variants for various states of the elements.

Below is a snapshot of some of the components put together for the Scoping and Notifications/Reports design systems.

Mockups & Prototypes

The design process to inlcuded the creation of visual mockups and interactive prototypes. Mockups were built using the design systems using the UI components to set up the page layout, content and features. For smaller updates and content, mockups could only consist of single static pages. For more complex features, patterns and flow, I build hi-fidelity interactive prototypes that looked and worked just like a real application.

Figma to Jira

To get early feedback from business and technical stakeholders, preview links from Sketch and Figma were linked into comments within the Jira tasks and stories. This process allowed for documenting task updates, kept the team informed and allowed the collaboration for smoother handoff from UX to Agile development.

01.
Design Styles
Fig. 1a
02.
Auto Layout
Fig. 2a
03.
Component and Variant Management
Fig. 3a
04.
Prototyping
Fig. 4a

Examples

The mockups below are examples created using the design systems for the Scoping and Notifications/Reporting tools. The components are pixel perfect to actual size and also contain auto-layout properties for flex positioning.

01.
Scoping Tool
Fig. 21
02.
Visualize
Fig. 23
Fig. 24
03.
Customer Notifications/Reports
Fig. 25
Plan Administration
Customer Notifications/Reports
Fig. 27
Fig. 28
Fig. 29
Fig. 30

Learnings

From the perspective of the domain, I pretty much learned everything about the entire electric and natural gas power shutoff process during a weather emergency. I managed to quickly onboard through the FEMA certification required training and shadowed all teams during full-scale exercise drills.

In Data Engineering - understanding the shutoff process and reporting different types of customer data sets using expressions within the Foundry Analyze tool. Creating templates and saving reusable expressions for personal and team use.

From the User Experience perspective, I learned a great way to set team maturity goals by first introducing UX concepts, meanings and establishing the current UX maturity level. It was interesting to see survey results from team leads and managers before going through a maturity scale checklist vs results from after.

Another thing I learned was to keep visibility and have my own documentation of work whatever new design updates or concepts I kept creating I needed to keep creating my own tasks in Jira and add them to the backlog for both documentation and visibility.

I would of not been able to apply these techniques without the support of the Director of IT/PSPS Applications, product owners, PSPS Scoping Specialists and their collaboration towards our common goals.