The situation
In a strategic partnership with NAES, the largest independent power plant operator in North America, a team of Geckos had been exploring how to create value for NAES's plants through software. A year into the partnership, the team was jumping between projects without clear direction, and with a contract renewal approaching.
What I did
I joined the team, got up to speed on what they'd been building, and traveled with them to learn firsthand at NAES power plants and a remote control room.
Immediately after our visit, I shared my learnings with the team, proposed a change of direction, a major design revision to support the change, and a list of PR-sized chunks of work to make the design real. Then I switched hats, contributing code to knock out several PRs myself, and pairing on other engineers' branches to directly implement specific design details.
Within 3 weeks of the visit, we'd shipped the revision, earning customer raves and winning our team a major contract renewal.
What I learned
Power plants run on thousands of pages of documents: blueprints, schematics, OEM manuals for every piece of equipment. These documents come from dozens of manufacturers, contractors, and vendors, and they're scattered across OEM portals, shared drives, and in many plants, literal reams of paper. Answering even simple questions, like "what's upstream of that valve," means hunting through multiple systems and traversing many documents. Every user I spoke with, across roles, dealt with this daily.
The prototype
Gecko's subject matter expert in power plants had already vibe-coded a prototype to help with this: it could parse thousands of pages of user-uploaded documents and link them together, so users could jump from one drawing to the next. This generated huge excitement in user demos, but it wasn't a focus of active work for the team. Instead, the plan was to build an agentic AI workflow to help expert users analyze time series data. The team was busily building toward parity with users' existing time series tools, and then they'd add AI on top.
Making the case for a change of direction
I felt this plan was risky: it could take a year to match the features and usability of mature tools these expert users depended on, and the value of hypothetical AI features was still unproven.
I argued the team should ship the most unique value that it could as quickly as possible, and this meant shifting work to the documents app.
It would solve a daily problem across nearly every role and use case at the plant. Users on site reacted strongly: "did 30 minutes of work in 1 minute," "would pay $100K/year for this," "I like this better than other vendors who are courting us." And the document ingestion work would be a prerequisite for the AI roadmap anyway; the documents contained all the context to build the asset graph that would power higher-order workflows.
The team reoriented around this direction.
What I designed
The prototype was a bespoke tool that worked impressively well, but had poor usability. I redesigned it to follow familiar interaction models: a file browser for finding documents, and a web browser for viewing and navigating them.
Finding the right doc: OS file explorer
The prototype dropped users into an empty viewer; users needed to locate an "advanced search" button, then find a document to get started.
In my design, users start on a page where the familiar patterns of OS file browsers get them into the right document as quickly as possible.
- Recent and favorite documents are prominently displayed for quick access
- The full library of documents can be quickly cut down in big chunks via quick filters and search
- Select a document to preview it; arrow-key through the list to find the right one
- Double click or hit Enter to open a document; add command/ctrl to open in new tab
Viewing and navigating docs: Web browser
In the prototype, document pages were annotated with boxes drawn around text recognized by the OCR engine. Selecting these boxes allowed users to unfurl a list of other documents with the same tag.
Some boxes were special "off-page connectors," denoting areas where the document explicitly references another document: "This pipe continues on document 498.G-2". Selecting these boxes revealed a button to navigate to the linked document.
My design simplified this system with a familiar interaction model: all boxes on the page were hyperlinks. Hover to see a preview of where you'll go on click. "Off-page" boxes go straight to the linked page, and tags go to the file browser, filtered to display all the documents referencing that tag. Add command/ctrl to open in a new tab.
Performance as interaction design
Users needed to use this tool to do their jobs, so the app had to feel fast. I identified specific performance goals for a few key interactions, and worked with engineers to hit them.
For instance, the backend didn't support pagination, so we implemented client-side pagination to cut initial load from 5–10 seconds to under 1 second. I also ensured we were rendering and caching appropriately-sized thumbnails so document previews load in under half a second, enabling a workflow-critical interaction of arrow-keying around a list of docs to find the right one before opening it.
Even the design choice of in-app tabs came from a performance constraint: our app took 8+ seconds to LCP, so opening a new browser tab would break the context users needed to hold in mind as they moved between documents. Our team couldn't directly address the load time, so we chose in-app tabs to mitigate the context breakage.
Putting on my dev hat
To communicate the change to the team, I made a loom video talking through the new design, and a document where I detailed the changes and broke them up into PR-sized chunks. Then, I jumped in with the engineers to build a few of the PRs myself, and collaborated with them on their branches to pair on certain interaction details that I wanted to build a specific way, like middle-truncating long document names.
Outcome
We shipped the updated design within three weeks of the last site visit. Our test users at the power plant had a lot to say:
"I just did 30 minutes of work in one minute."
"You guys are way faster and more attentive than [other vendors]."
"This is the first program that we've demoed that feels like a useful real life use. We're going to actually benefit from this."
NAES signed a $5M one-year contract extension, a significant contribution to Gecko's FY26 revenue goals. The team has a clear path forward through H1 2026, and product-eng collaboration is the strongest it's been.