Turning the manual assembly of work readiness across 8 fragmented enterprise systems into a single planning view cutting a two-hour check down to minutes, for grid operations managers.
Grid operations managers rely on numerous interconnected systems to coordinate field work. Before any work can begin, multiple operational dependencies - materials, approvals, engineering reviews, scheduling - must all be completed across 8 disconnected enterprise systems. None of those systems talks to the others, so determining whether a single work item was actually ready to execute meant assembling the answer by hand, for every work request.
The process had become slow and frustrating for managers, making it hard to tell which work items were ready to start, and which were held up by blockers or pending dependencies in the source systems.
Sr UX Designer · working with grid operations managers, IT Leaders and a distributed engineering team · Owned discovery through release
The ask was a chatbot. Discovery showed managers didn’t need answers about one request — they needed to see readiness across all 15–20 a day.
Worked from IT’s data model and manager interviews to define a single readiness model both sides trust.
Explored two directions in Figma Make within days, then removed features the data couldn’t support, such as idle tracking.
Extracted design tokens and component rules from the Figma Make prototype with Claude, encoded them in design.md specs for the engineering team’s AI agents, then reviewed their output and signed off the front end.
Readiness assembly moved out of spreadsheets, notes and multiple enterprise systems into one view, complementing the existing work management system rather than replacing it.
The grid operations manager who first raised the problem advocated for the tool and drove its rollout.
The business owner fronting the operations–IT relationship is scoping additional work in the same shape.
Still Measuring: If this can also reduce redundant crew rollouts
The IT team was building an AI assistant for looking up work requests. It was far enough along to demo, and the operations leads who saw it weren't convinced.
The assistant was meant to be a faster way into a single work request: give it a number and it returned what the legacy system would otherwise take several tabs to show — the details, who it was assigned to, and whether it was complete or not started. It never touched the eight systems holding the dependencies that decide whether work can go ahead. Nobody had defined which data answers the only question a manager needs answered: is this work ready to execute?
It handled the narrow case: give it a work request number and it returned detail about that item. Nobody had tested that against how managers actually plan.
It reported on the work request itself, not on the dependencies that decide readiness. No follow-up question could get there, because those systems were never in scope.
Defining work readiness changed what needed to exist. Instead of a faster way to ask questions about a single work request, the solution computes the answer and puts it in one view — for managers who have to make the readiness call in real time.
The planning view follows how a grid operations manager actually works: see what is ready to execute, narrow to what isn't, open the blocker, and act on it without leaving the page.
Interactive — narrow to a management area, then open a work request to see what is holding it. Best viewed on desktop.
Detailed process ↓
I used AI to accelerate solution delivery and work as a solution builder rather than as a traditional designer.
Discover
Before designing anything, two things had to be established in parallel: what operations actually needed, and what the data could actually support.
Inputs to AI
Grid operations manager and IT stakeholder conversations.
Video from the discovery interviews.
Data models, architecture, and the 8 source systems.
Interview transcripts, IT's data model and the existing technical documentation, run through the company's AI portal, which already carried context on operations and data sources.
AI compressed weeks of transcript analysis into days, and I used my design judgement to refine and validate the output. Mostly filter and distill the information necessary for next stages based on business goals and timelines.
Outputs from AI
Validated patterns across operations and IT.
How grid operations managers plan work.
Explicit targets to build against.
I mapped the existing business process the users followed to understand their current-state workflow and how work readiness was deduced. The fragmented process they used involved a lot of manual searching for data across multiple sources, all of it fitted in between their other roles and responsibilities for their area.
Each work request carries its own set of dependencies- locates, staking, permits, gold tape, outage, SWO and material -held across 8 enterprise systems, the eighth being the CRM. Roughly 2 hours of manual checking to conclude whether one item is ready, against 20+ items a day.
Discover
Five patterns came out of the interviews and synthesis. Together they explain why a chatbot for asking questions about a single work request was not solving the problem for the users:
To assess operational readiness, users had to access 8 different complex systems and manually determine the status of each data point.
Each user maintained and accessed this information across 3-4 management areas, and covered additional areas whenever leads were out, amounting to hundreds of records.
Establishing whether an item was ready to execute, blocked on an incomplete data point, or not started at all was slow and entirely manual.
Users spent days tracking down the right person to clear a blocked work item, or to sign off on moving the next one into the pipeline.
Each manager handles 15–20 work requests a day while completing other responsibilities, and chasing that data by hand was chaotic. Planning and restoration slipped, causing redundant crew roll-outs.
Assembling readiness by hand was never quick. What changed was how much of it there was.
A platform migration moved operational data onto new systems and spread it across more of them. Checks that were a single lookup a couple of years ago became several, and every additional source was another place a manager had to visit before calling a work request ready. The job itself hadn't changed. The number of steps in it had.
That is what turned something these teams had absorbed for years into a problem worth solving -and it is also why a tool that answered for one work request at a time was never going to be enough.
Define
Mapping how readiness actually got assembled before the redesign:
Since this was an enterprise problem, I used a lean role based persona to empathize with the users:
Two roles, one problem: the area manager accountable for a region they cannot see in one place, and the grid operations manager coordinating across teams and systems that do not talk.
Area Manager
Delivery Assurance Lead
I am responsible for reliability across my region, and for keeping customers in power every day.
Goals
Challenges
Grid Operations Manager
Production / Operations Lead
I want to investigate faults efficiently and catch risks before they become outages.
Goals
Challenges
The assistant built by engineering wasn't broken. It did what it was designed to do, and the managers it was for still didn't want it. The research showed why: it had been scoped against an assumed problem rather than an observed one.
Readiness wasn’t a fact sitting in any one system waiting to be retrieved. It was an inference a manager had to construct by hand, every planning cycle, across 8 of them. That reframed the brief from retrieval to visibility, and changed what needed to be built.
A retrieval problem. Users can’t get to the data, so give them a faster way to ask for it.
A visibility and decision problem. Users can’t tell whether work is ready, and no system holds that answer.
The research pointed at five things. They were written to be arguable, each one rules something out, and each one is answerable against a finding.
If a manager has to reconstruct it by hand, the system hasn't done its job.
Managers plan across hundreds of work requests. Answering for one at a time was the chatbot's ceiling.
A blocker without a name is a search task handed back to the user.
Every exit to another system is a step where the picture goes stale.
A blocker found while planning is a decision. The same blocker found later is a delay.
These set the bar. What they didn't settle was what the thing should look like to people who spend their day in enterprise software — which is where ideation started.
Ideate & solution
With the problem defined, the work moved into deciding what the view should be — first by testing the fastest route available, then by steering it with what the research had established.
Five stages from first prototype to handoff. The loops matter more than the arrows: direction went back into Figma Make until it held, and the front end went back and forth with developers until the design.md matched what shipped.
Before settling what the view should look like, it was worth being precise about two things: what these managers already spend their day in, and what the view actually had to let them do.
Detailed design goals
Work requests per area manager, across one or two management areas at a time.
The state of a work request and every dependency on it, visible at once rather than opened one at a time.
Not just that something is outstanding, but which one is holding the work and what addressing it involves.
What is ready, not ready and blocked within a management area, without counting it up by hand.
Contact or notify whoever owns a dependency for status and an ETA, without hunting for who that is.
Every exit to another system is a step where the picture goes stale and the task gets abandoned.
A manager should close the view having acted, not holding a list of things to go and chase.
The fastest available route was to let the tooling try first. I used the existing chatbot to generate a prompt describing the problem and fed that into Figma Make. It returned two concepts, a dark operations console, and a lighter list-and-detail layout. Both worked. Neither was one these managers would use: each solved the brief generically, without the density or the patterns their day actually runs on.
The list-and-detail concept, marked up. Blue for what I took forward, red for what needed rethinking. Recreated for this case study; the original work is under NDA.
The operations console concept, marked the same way.
Neither was close to shippable. Neither followed our colour or interface conventions, and neither read as enterprise software — one looked like a consumer task app, the other like a control-room monitor. But between them there was enough right to be worth arguing with.
Users said the concept worked, but they felt overwhelmed. They didn't want more tasks or another application with multiple steps, and they showed us the tools they use day to day, whose interaction patterns they were already accustomed to:
Other feedback on interaction and UI elements
Feasibility in parallel
The technical team was kept in the loop throughout rather than consulted at the end, so feasibility concerns could surface while the design was still cheap to change. Their answer was that the data already existed; what it needed was APIs arranged to serve the view the users had agreed to.
Taken as inspiration
ignored
That was the point to stop prompting and start drawing. The concepts had given me a set of ideas worth keeping and a clearer sense of what was wrong, and the fastest way to hand that back was to wireframe it myself.
What the tool was missing was not capability but context. It had no idea what these managers look at all day. So I wireframed the structure myself, what sits at the top level, what expands in place, how a barrier names its owner, and what happens when you act on one.
Rather than discard the tool, I changed what I gave it. The second prompt carried the wireframes, the colour and type conventions of the systems these teams already work in, and references to the data tables and dashboards they use daily, the context the first attempt never had.
Re-prompting with the wireframes and the conventions of the tools these teams already use produced something structurally sound. It was a table, at the density managers work at, with dependencies as columns. Four things carried over from the research and stayed in the shipped product.
Rows a manager can scan at the volume they actually carry, instead of tiles sized for seven items.
Seven marks against each work request, so readiness reads across items rather than one at a time.
The first thing a manager does is narrow to the areas they cover, including a colleague's when covering for them.
Contacting the owner of a blocker without leaving the view, and leaving a record that the chase happened.
The structure held from here on. What it didn't settle was whether anything on the screen meant what it appeared to mean.
A dense table that looks authoritative is a liability if its numbers don't hold up. The next stretch wasn't visual. It was deciding what each element actually claimed, and changing the ones that couldn't support the claim.
Second direction. Structure right, claims wrong.
Next pass. The row now answers the question; three things on it still couldn't be trusted.
The same build, expanded.
Three things were designed, built, and taken out. Two because the data couldn't support them, one because I'd read a status wrong.
The last one cost a state, a marker, a rule and a demo scenario. A plausible reading of a domain term is still a guess, and checking it with someone who knows costs less than being wrong.
What the numbers claim and what the table shows now agree. Four ready and seven not ready against eleven, with one held aside. In the panel, three cleared, two pending and two blocked against seven dependencies.
Three counts that reconcile, the blocker and its owner on the row, and dependencies a manager can read without opening anything.
Seven dependencies in fixed order, each linking to the system that owns it. Notify appears only where there is a person to reach.
The second direction came back close to what shipped. The difference wasn't the tool. It was that the second attempt carried domain knowledge the first one couldn't have had.
The tool accelerated the making. It didn't decide what was worth making — that came from the interviews, and from knowing which patterns these teams already trust.
Deliver
Testing settled which direction held up under real planning work. I refined the chosen one against what the sessions surfaced, then specified it in enough detail to build.
Build & handoff
Handoff wasn’t a document drop. Because the engineering team was building with AI assistance, the design spec had to be something their tooling could consume directly — not a set of redlines a person would have to translate first.
Artifacts
Structure, states, and behaviour in readable form.
Real interaction, not static redlines.
Build validated against the design.
The Figma Make link went across as the working reference, and the design.md as the spec their tooling could read. What followed wasn't a review cycle. When the build hit something the spec hadn't anticipated, or the implementation surfaced a case the design had missed, it was resolved in the design.md rather than in a comment thread — so the file stayed accurate as the build moved.
Most of what came back wasn't a design question. It was the tooling generating something that didn't match, or an edit the spec described loosely enough to be read two ways. Tightening the wording fixed more of it than redrawing anything did.
Recreated for this case study; the original work is under NDA.
The sign-off was a judgement, not a checklist. I approved the build when it matched what the spec described and the gaps left were ones I was willing to ship for this version. Not finished — good enough for the launch we were making.
Reflection
AI now gets you to a working starting point quickly, and occasionally to something close to final. The work that remains isn't production — it's judgement: which direction is worth pursuing, which output survives contact with how people actually work, and what to throw away.
AI can build ideas and concepts quick, but as a designer steering it in the right direction is still our job.
With data-heavy systems and complex operational workflows, a vibe-coded design can produce a polished UI or organise the data, but it can't yet produce a coherent interaction pattern that fits how people actually work. That still has to come from the designer.
Writing specs a development team’s AI tooling could read directly was more useful than any redline file I’ve produced. I expect that to become the default rather than the exception.
KEEP EXPLORING
Here are a few more of my case studies.
.png)
