case study

Strangeworks Aura

How we turned optimization modeling — a slow, PhD-only craft — into an AI-assisted workflow, and what I designed and built along the way.

Aura is Strangeworks' proprietary toolset for solving complex optimization challenges: an agentic process science teams work through to take a problem from precise definition to production deployment. Around it sit Strange-UI, our design system, and the custom client apps it powers. I've led design across all of it for the last two years — from the first discovery interview to the production code shipping today.

It's also where I became a design engineer in practice: designing the thing, then building it in the front-end myself, and learning to work frontier models into how apps actually get made.

What follows is that story the way I'd tell it in the room: the research it started from, the vision it turned into, and the product shipping today.

At a Glance

Role, team, and where Aura stands today.

  • Principal Product Designer & Design Engineer, leading design across Aura, Strange-UI, and the client apps
  • Two years in — from the first discovery interview to the 2.0 shipping today
  • Embedded with about ten developers and our own science team of PhD consultants
  • Designed in Figma, then built in the repo with Tailwind, Cursor, and Claude Code
  • In production with science teams at Deloitte, Accenture, and Johnson & Johnson
+/\+
01

Research & Discovery

Interviewing our own PhD consultants to map how an optimization model actually gets made

Strangeworks formulates hard optimization problems for quantum, quantum-inspired, and HPC solvers. Discovery meant interviewing our own consultants: PhD physicists, a quantum ML scientist, people writing data science code against quantum hardware.

Two findings. The process repeated across clients, so it could be productized. And the make-or-break step was problem definition — that one steered the whole product.

Notion research hub — discovery workshop docs, consultant interviews, and insights
Problem → Analysis — phased flows and standardized formulation components in Figma
+/\+
02

Workshops & Wireframes

Finding the line between a digital science binder and a full data science IDE

The design question was where to land on a spectrum: a digital science binder at one end, a notebook IDE at the other. Too far toward the binder and scientists can't work. Too far toward the notebook and it's Jupyter with extra steps.

I wireframed across that whole range, then presented the vision at our quarterly offsite in Austin. Having the science team argue with it in person is what made the direction stick.

Sci Workflow board — pain points and opportunities across every phase, and the offsite deck
Prototype flow board — projects, research and methods, formulation, and solvers
+/\+
03

Building It in the Front-End

Straight into the repo, so our scientists could use it while we iterated

The dev team jumped into the app building agentic reasoning, and I jumped into the code with them. The app was called Workflows back then — it became Aura later.

Going straight to the front-end is what made the loop fast. Our own ten-scientist consulting team used it while we built, then science teams at Deloitte, Accenture, and Johnson & Johnson built their own models in it — people we hadn't trained, on problems we hadn't scoped. Their feedback landed back in the repo the same week.

Version one, Workflows, was a long linear march. Watching it get used showed us exactly where it broke down.

Workflows running in the front-end — the app the science team used

Define

redefine ↔ reanalyze
  1. 01
    Research & discovery

    Understand the business problem and what solving it is worth.

  2. 02
    Problem definition

    Write the problem down precisely enough to model it.

  3. 03
    Problem analysis

    Pressure-test the definition, find the gaps, go again.

Model

  1. 04
    Abstract model

    Get the variables, constraints, and weights right.

  2. 05
    Toy data

    Skeleton datasets to instantiate the model.

  3. 06
    Toy instance

    A concrete instance on toy data that actually runs.

Data

  1. 07
    Dataset build-out

    Assemble the real data, then the long work of cleaning it.

  2. 08
    Concrete instances

    Apply the real data to produce runnable instances.

Run

  1. 09
    Solver selection

    Match the formulation to the solver — QUBOs and BQMs for quantum, HPC for the rest.

  2. 10
    Compute & run

    Run on the hardware solvers and read the results.

+/\+
04

Aura 2.0 — Agentic Advancements

Working the problem back and forth with an agent until the definition holds

A year of beta testing showed us where users got stuck, and as the agents got better we jumped ahead of our own roadmap. 2.0 simplifies the whole thing, problem definition through to run.

Our first instinct was an agent per step. 2.0 flips it: the user works back and forth with a problem analysis agent until the definition genuinely holds. That's where the effort goes now. After that, the interface is mostly showing what's happening — formulation, solver selection, data cleaning, compute, run.

This is the end product, building optimization models today. And it's what the consultants told me in discovery two years earlier: the whole thing is that one insight, built.

Aura 2.0 — the problem-definition agent and AI-assisted results analysis

client science teams building their own models

Johnson & JohnsonDeloitteAccentureBPRTX (Collins Aerospace)
+/\+
05

Custom Client Apps Powered by a Design System

Strange-UI, our own system for standing a client's app up fast

Aura 2.0 builds the model — then the model has to run a business: staff scheduling, vehicle routing, cargo and freight, logistics.

So the last step is design work again. We're a consultancy, so every engagement ends in its own custom web app, built for that client's operation. Powering them is Strange-UI, a separate design system we built for exactly this: each operation differs, but the pieces repeat — schedules, constraints, scenario builders, solver runs. Strange-UI carries those components and the rules for assembling them, so a new client app starts production-ready instead of from a blank file.

Aura is live today behind the Strangeworks optimization practice — see the shipped product.

Strange-UI — the component library behind the client optimization apps
+/\+

What It Added Up To

An internal process, turned into a product, turned back into client work

We built an app that builds optimization models, and a design system for the interfaces that run them. Then we sit with each client and design the real thing, so somebody on the ground in operations can run their day with it.

A process we learned from our own consultants, turned into a product, turned back into how we serve clients. Full circle.

What I Did on It

  • Ran the discovery that surfaced the insight the whole product is built on
  • Presented the product vision to the company and got the science team behind it
  • Designed the end-to-end agent flow two years before the models could run it
  • Built the UIs in production code alongside a ten-person dev team
  • Led the product vision from research through the 2.0 the company ships today
  • Helped build Strange-UI, the design system behind every client interface