CS/02 — ENERGY · WORKFLOW ARCHITECTURE · AI-ASSISTED DESIGNCENSORED FOR THE SAKE OF HUMANKIND.

Leading workflow architecture for an AI-assisted grid platform

DOMAIN — POWER-GRID CONTINGENCY PLANNINGROLE — LEAD PRODUCT DESIGNER · WORKFLOW ARCHITECTURESCOPE — DOMAIN SYNTHESIS · WORKFLOW ARCHITECTURE · PROTOTYPING · AI EVALUATION · CROSS-FUNCTIONAL FACILITATION

THE CHALLENGE

Define a coherent product across simulation configuration, contingency analysis, violation investigation, mitigation planning, and scenario comparison while the technical requirements and product direction were still evolving.

WHAT I CHANGED

I led working sessions with engineers, subject-matter experts, and stakeholders; clarified the operational model; separated distinct workflow domains; and translated the result into scalable flows, interaction patterns, and high-fidelity prototypes. AI-generated artifacts were treated as testable hypotheses, never decision-makers in a blazer.

WHAT BECAME POSSIBLE

The team gained a shared product model, clearer operational boundaries, explicit validation points, and an implementation-aware direction that reduced cognitive complexity without flattening the engineering work underneath it.

THE SETUP

The product helps power-systems engineers configure simulations, analyze contingencies, investigate grid violations, plan mitigations, and compare scenarios inside an existing AI platform with its own technical and interaction constraints.

The source material at kickoff included workshop boards, technical notes, demo screenshots, transcripts, existing platform patterns, and AI-generated wireframes from the technical team. It was substantial but not coherent, a familiar enterprise condition. Different artifacts described different versions of the product, and several important relationships remained implicit.

The design question was not simply how to move quickly. It was how to move quickly without allowing speed to substitute for understanding.

LEADING PRODUCT DEFINITION UNDER AMBIGUITY

My role extended well beyond screen execution. I synthesized workshop findings, technical documentation, stakeholder feedback, and engineering requirements into the operational mental model, information architecture, and interaction logic for the product.

I led collaborative working sessions with engineers, subject-matter experts, and stakeholders to define five connected domains: simulation configuration, contingency analysis, violation investigation, mitigation planning, and comparative scenario review. As requirements changed, I restructured the workflow so those domains remained distinct enough to understand and connected enough to operate as one system.

The work included patterns for AI-assisted recommendations, topology insights, filtering, mitigation planning, and scenario comparison. Regular walkthroughs and product reviews made the prototype a shared decision surface: specific enough to expose disagreement, flexible enough to change before disagreement became expensive.

THE APPROACH

Alongside the workflow-architecture work, I framed uncertain design questions as a sequence of bounded experiments. Each had a question, a source set, an output, and a validation step. AI helped translate unfamiliar concepts, compare artifacts, synthesize evidence, generate prototype candidates, and interpret completed screens. But it did not receive decision authority.

AI outputs were treated as hypotheses, not answers.

That distinction changed the work. A generated screen was not progress because it looked plausible. It became useful only after its assumptions were visible enough to evaluate.

THE PIVOTAL FAILURE — A POLISHED WRONG ANSWER

One early AI-generated prototype imposed a linear progress model on the workflow. The screens looked credible: clear steps, familiar progress indicators, responsible enterprise posture. It looked like it had passed a committee. The problem was conceptual. The real work required users to revisit earlier decisions as results, fixes, and plan comparisons changed.

The prototype had translated uncertainty into a sequence it could render easily. It made the wrong mental model look finished.

That failure became the governing test for the project: every prototype needed to show not only what happened next, but what persisted, what could be revisited, where validation occurred, and which objects belonged to a violation versus a plan.

AI ASSUMPTION

One-way progress through a tidy sequence.

DOMAIN EVIDENCE

Engineers revisit inputs, fixes, and comparisons as results change.

DESIGN DECISION

Keep a five-step surface for orientation — preserve the nonlinear loop and persistent case state underneath.

FIG 01 — ASSUMPTION TO DECISION. The conceptual center of the project: the artifact’s claim, the domain’s rebuttal, and the design that honored both.

SELECTED EXPERIMENTS

EXP 01 — AI as domain translator

I used AI to translate contingency analysis, thermal violations, solver behavior, and legacy planning workflows into questions I could validate. The useful shift was not from ignorance to expertise. It was from "I do not understand this" to "I know exactly what I need to ask the experts and artifacts."

EXP 02 — AI-generated wireframes

Generated wireframes compressed early structural exploration from roughly forty minutes to ten or fifteen. The speed was real. So was the failure mode: the tool resolved ambiguity by importing familiar patterns, including a sequential workflow the domain did not support. The lesson was not to reject generated wireframes. It was to evaluate the product logic before rewarding the polish.

EXP 03 — More context does not mean better context

Larger prompts did not produce proportionally better results. They drifted toward generic enterprise conventions and flattened the domain’s important distinctions. I stopped maximizing context and began curating it: each design question received the smallest authoritative source set that could answer it. Contradictory or historical artifacts were introduced deliberately rather than blended into one enormous prompt.

EXP 04 — The legibility audit

I gave prototype screenshots to a clean external AI session and asked it to reconstruct the product: objective, workflow, objects, assumptions, background processing, and ambiguities. This was not a usability test and the AI was not the judge. It was an outside interpreter, and the gaps between its reconstruction and my intended model exposed where the prototype was relying on narration, familiar patterns, or invisible system behavior. That experiment became the basis for the Legibility Audit described in Paper A.

EXP 05 — Tools by cognitive role

No universal "best" tool emerged. One imposed linearity. Another scaffolded app-like workflows quickly. A third exposed how much interaction structure my prompt had left implicit. The meaningful comparison was not which tool produced the prettiest screen. It was which part of the designer’s thinking each tool made visible.

THE RESOLVED PRODUCT DIRECTION

The resolved direction used a five-step surface for orientation while preserving persistent case state and the ability to revisit earlier decisions underneath it.

GLOW contingency analysis — case loading step, anonymized

FIG 02 — CASE LOADING AND VALIDATION. Per-case file validation makes readiness visible before processing begins. The surface is sequential; the underlying case model is not disposable. Client branding removed; data synthetic.

GLOW AI model training results by case, anonymized

FIG 03 — TRAINING COMPLETE. Model results shown per case and checked against the physics-based solver. Similarity, precision, recall, and logs make validation part of the product rather than a backstage assurance.

THE OUTCOME

The work produced a clearer product model, scalable workflows, and explicit answers to questions that had remained abstract: where validation occurs, what persists across runs, when users revisit earlier decisions, and whether fixes belong to individual violations or to broader plans.

The final flows and high-fidelity prototypes established the product direction and gave engineering, domain experts, and stakeholders a concrete system to evaluate together. The engineering team responded strongly; one experience strategist summarized the work this way: “She does a great job turning very complex workflows into intuitive designs.”

The evaluation work also produced a reusable internal method for testing whether complex prototypes communicate their intended system before stakeholder review.

The durable outcome was not faster wireframing. It was a more disciplined relationship between generation and judgment.

KEY TAKEAWAY

AI was not the method. AI was the material being tested. The method was design judgment.

Speed is useful. Speed without judgment is faster nonsense.

Screens are sanitized recreations. Client data, naming, and internal terminology have been removed.

← INDEX
NEXT: CS/03 →