Autodesk: one owner for two experiences

Every company eventually outgrows the system it was built on. Autodesk had reached that point with its ERP — the software that quietly runs how offers are composed, how prices are set, how a quote becomes an order, and how a signed contract becomes a usable subscription. The old stack was aging, heavily customized, and a brake on digitization. The answer was a ground-up replacement program, internally called Apollo. I came on as a UX Designer IV through Applicantz and owned the experience layer end to end — across the customer-facing path and the dense internal platform behind it. That "both sides" is the whole story.

I stepped in at the moment that's both the best and the hardest to join a program like this: the vision existed and an outside vendor had done early work, but the experience layer needed an owner who could carry it end to end. Picking up after a vendor also meant archaeology. Legacy ERP problems are rarely one ugly screen — they're accumulated logic: years of exceptions and assumptions baked so deep nobody could fully see them. I had to surface those before I could safely build on top of them.

Apollo touched the parts of the business where money actually moves. A confusing pricing control or an ambiguous quote-to-order handoff isn't cosmetic — it feeds pricing, revenue recognition, and export compliance downstream. In this system, an over-simplified screen isn't a kindness; it's a risk. So the goal was never "make it prettier." It was to modernize without simply reprinting the old complexity in a new coat of paint.

It was becoming the connective tissue of the program. Apollo had many stakeholders, each holding one true piece of the picture. On a program this size the failure mode isn't bad design — it's five groups quietly designing five different products, each coherent and mutually incompatible. So I set up and facilitated the design cadences and made myself the central point of contact between them. That's how I could catch a pricing rule that broke a quoting flow, or a pattern two teams were about to reinvent differently, before either became rework.

The work spanned the whole spine of the quote-to-order journey — eight-plus flows that had to read as one continuous path. Configure offer is the heart of CPQ — an attribute-based model where an offer is composed from products, services, programs, and discounts, with a live price summary always in view so a rep never leaves to do the math.

Finalize is where the guardrails become visible on purpose: pricing authority within limit, export control cleared, two-reviewer approval, the linked Salesforce opportunity — because in this system, hiding them is the risk.

And the eStore checkout is the customer pole: the exact same deal the internal CPQ was enforcing, shown as one clean transaction the customer can finish without a manual.

Underneath the rebuild, the business model itself was moving — from fixed seats you renew to Flex, a consumption model where customers buy tokens and draw them down. That changes what a quote even is: access tied to a live balance that stops at zero and resumes on purchase, with no renewal moment. So the quoting and access experience had to express consumption, not just a seat count — and reporting had to make it legible: tokens purchased, used, and expired, plus deferred revenue and retention. Finance lived there, and their needs shaped the data model as much as any screen.

Where a flow needed a component that didn't exist, I built reusable ones and contributed patterns back into Autodesk's newly launched design system, so the next designer inherits the pattern. Almost every decision was a negotiation between two poles: simple and guided versus dense and deliberate, because getting it wrong moves money.

July through December 2021, a large body of experience design across the Apollo CPQ and quote-to-order program — flows, wireframes, prototypes, and reusable design-system contributions that gave the platform a coherent experience where there had been inherited fragments and legacy logic. Honestly: the source describes scope and responsibilities, not program metrics; the screens are clean recreations with sample data, and I'm not quoting numbers I don't have.

The conviction it sharpened: on a program with this many stakeholders, the highest-leverage design skill isn't the artifact — it's the alignment. And ERP UX, I came to believe, is the art of deciding which complexity to hide and which to make the user look at on purpose.

See the full case study → https://design-case-studies.vercel.app/autodesk