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 across IT stakeholders, grid operations managers, and a distributed engineering team from discovery through release.
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 accelretate 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 exisitng business process the users followed to understand their current state workflow and how work readiness was deduced. The messy fragmented process they use today had a lot of manual searching and finding data from multiple sources, and all this had to happen in between other roles and resposibilites 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 Chat bot to ask questions about a work request item was not solving the probelm 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 responsibilites, 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 mentioned it works as a concept, however they were feeling overwhelmed and suggested they do not want more work/task and an additional application with multiple steps, they showed a lot of other tools they use on a day to day basis whose interaction patterns they were already accostomed 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 would 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 operation workflows, a. vibe coded design can give a pretty looking UI or structure the data but it cannot create usefulness and a coherent interaction patter yet.
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.
Here are a few of more of my case studies.
