Blend Optimizer
Replacing a decades-old Excel-based blend planning workflow with an AI-powered web application, turning oil-well fluid optimization from a manual spreadsheet exercise into a fast, auditable, ML-driven process.
help Plant Operations Managers run fluid blend optimization faster and more accurately, without losing the nuance and institutional knowledge currently locked inside a complex Excel model?
The Problem with the Legacy Spreadsheet
The client, a global oil-field services company, operates in completion fluids: engineered salt brine solutions used to maintain pressure in oil and gas wells. Their existing blend optimization process ran through a proprietary spreadsheet model, where engineers manually input well parameters, cross-reference chemical inventories, and calculate optimal formulas for each job.
The model was powerful but brittle: only a few specialists could operate it correctly, results weren't trackable across runs, and every approval workflow ran through email threads and printed sheets. The client's data science team had already built a Machine Learning proof of concept that outperformed the manual approach. The challenge was turning that PoC into a production-ready tool their field ops teams would actually adopt.
The production application is client-confidential. See the interactive recreation further down this page for an illustration of the resulting interface.
UX Lead on a Cross-Functional Team
SoftServe was brought in to build the full-stack application: React + Next.js frontend, Python APIs, Azure infrastructure. As UX Lead, I owned the interaction design and prototyping from discovery through Phase 2 MVP handoff — consolidating three disconnected systems into one workflow, working alongside a cross-functional project team.
Four discovery sessions with the client's operations and data science teams established that the primary user, the Plant Operations Manager, needed a workflow anchored to Jira tickets (the existing job tracking system) and connected to the client's internal plant monitoring system. Every design decision had to make sense within that mental model: jobs → pilots → blend results → approval → lab validation.
Prototyping with Claude
This project became an active experiment in AI-assisted UX work. Rather than produce static Figma screens, I used Claude (Anthropic) as a design collaborator, describing interaction patterns, iterating on component states, and generating functional HTML prototypes directly from conversation.
The approach compressed iteration cycles significantly: a full-fidelity interactive mockup could be reviewed by engineers and stakeholders within hours of a discovery session, rather than days. By v7, the prototype had accumulated the product's full brand token system, all major user flows, and was close enough to production quality that it directly informed the React implementation.
| Stage | 01 · Discovery | 02 · Prototype v1–v3 | 03 · Feedback loops | 04 · v7 Handoff |
|---|---|---|---|---|
| AI role | Session-note synthesis | Design collaborator, generates working HTML from conversation | Iterates screens live against reviewer notes | Produces near-production, React-ready markup |
| Tools | Claude | Claude, product brand tokens | Claude, Figma (annotation only) | Claude, React-ready component spec |
| Process | 4 workflow-mapping sessions with client Ops + Data Science | Interaction patterns described in chat, working screens generated the same session | Ops + Data Science review a working prototype, not slides | Full token system + every flow consolidated into a dev-ready spec |
| Key question | What does the legacy spreadsheet model actually get wrong today? | What should this look and feel like, fast enough to react to? | Does this match how a blend actually gets approved? | Is this literally buildable, not just believable? |
How AI Compressed the Design Loop
The diagram maps the real flow of inputs, AI-augmented work, and deliverables across the BlendOps engagement. Link weight reflects dependency intensity: client domain knowledge was the bottleneck that determined AI quality. Hover any node or link for context.
From Ticket to Approved Blend
The core workflow follows a Project → Pilot → Run → Approve loop. Each project can hold up to three pilot blends; only one can be approved for production. The production application is client-confidential. Below is an interactive recreation with generic labels and fictional data illustrating the same interaction pattern.
Illustrative recreation: interface rebuilt from memory in plain HTML/CSS/JS. Product name, org names, and data are fictional.
| Ticket | Location | Type | Cost/bbl | Avail |
|---|---|---|---|---|
| BX-2201 | Site A · Tank 4 | CI/B | $206.95 | 1,000 |
| BX-2214 | Site A · Tank 2 | CI/B | $143.85 | 1,000 |
| BX-2255 | Site B · Yard | CI | $34.29 | 2,400 |
Building the BlendOps UI Kit
Alongside the prototype work, a dedicated Figma component library was built to give the engineering team a clear, token-driven reference for every UI surface in BlendOps.
The kit covers form controls (dropdowns, number inputs, inline validation), data table patterns (sortable columns, status chips, inline edits), modal flows (confirmation dialogs, optimizer progress, approval submission), and the three-panel shell itself.
Design tokens follow the product's brand palette directly: primary blue for structural authority, cyan for interactive accents, and citron reserved exclusively for commit actions. All components carry accessibility annotations, contrast ratios, and keyboard interaction specs ready for developer handoff.
Why These Choices
Used Shadcn/ui + Tailwind as the component base, building on top of Radix primitives. The interface is data-dense: dense tables, inline chemical formulas, multi-state status chips. That density needed a system that could scale without visual debt, and Shadcn's unstyled base let us apply the product's tokens cleanly.
The product's brand palette maps naturally to information hierarchy: #005495 primary blue for authority and nav, #38C6F4 cyan for accent and topbar stripe, and #DAE24C citron reserved exclusively for primary CTAs such as Run Optimizer, Save to Jira, and Submit for Approval. The citron stands out against both dark and light backgrounds and signals "this commits to action."
Montserrat for UI surfaces (authority, legibility at small sizes in data tables) paired with IBM Plex Mono for values, ticket numbers, chemical formulas, and any data that needs character-level precision. Engineers read mono; it signals trustworthiness for numerical output.
Left sidebar for job navigation (All Jobs → Current Job → Pilot tabs), center for the active workflow form, right panel for the optimizer result and comparison table. This maps to how operations managers actually work: they hold the job context in their head while checking results against targets. The layout externalizes that mental model.
Technical Context
BlendOps is a standalone Azure-hosted web application. The frontend is React + Next.js; Python APIs handle ML orchestration, Jira sync, and plant-monitoring data retrieval. From a UX perspective, the architecture meant designing around API latency: the optimizer takes 1–2 minutes to return results, requiring explicit loading state design and a clear "run in progress" pattern that doesn't lock the interface.
What surprised me most was how productive the AI-assisted prototyping workflow became once the domain was well-established. The first few iterations were mostly me learning the chemical vocabulary: what density means in ppg vs kg/L, what TCT (Thermodynamic Crystallization Temperature) constrains. Once that was solid, the AI could generate accurate UI scaffolding because I could describe the domain precisely. The quality of the prototype was a direct function of the quality of my domain knowledge. That's a lesson I'll carry forward.