Major Agricultural Machinery Manufacturer

— Infrastructure of Design

There's a particular kind of challenge that doesn't show up in a brief. It lives underneath the product work, in the processes that don't exist yet, the workflows nobody has defined, the question of how a historically physical industry learns to trust software design as a core value driver. You can't prototype your way out of it. You can't run a workshop and call it solved. You have to show up, consistently, and build the infrastructure that makes good design possible before you can make good design.

That's what this engagement was really about.

The context

A major American agricultural machinery manufacturer was building a new aftermarket digital product — software for the dealers and parts specialists who keep their machinery running in the field. This wasn't a consumer app. It was a complex, multi-layered tool for people who spend their days moving between physical parts books, digital systems, and their own hard-won expertise to diagnose problems and find solutions for customers standing in front of a broken machine.

I was brought in to pair with the Product Principal, working alongside a client design leader and a program that spanned multiple products and workstreams. I had two program-wide designers on my team, placed to support across streams rather than anchored to any single one — which meant managing at a scale and spread that required as much systems thinking as it did design craft.

What I saw in the field

Early in the engagement I had the opportunity to do on-site observations with parts dealers — watching them work through real customer problems in real time. A farmer calls. Something on the machine isn't right. The dealer moves between a physical parts book, a digital tool, their own memory, and whatever institutional knowledge they've accumulated over years of doing this work. The process is slow, fragmented, and deeply reliant on individual expertise that lives in people's heads rather than in the systems they're using.

Watching that, I knew in my bones that we could help. Not in an abstract "design will solve this" way. In a specific, grounded way — if we got the experience right, we could reduce the cognitive load of a genuinely hard job and give dealers back time and confidence they were currently spending on friction.

The flipside came later, when a first version of our solution was shared with dealers and they could use it intuitively — navigating a complex, multi-layered experience without needing to be taught how. That moment, watching people move through something we built with ease and recognition, is one of the things I work for.

Building the Blueprinting Process

One of the first things I recognized was that the program needed a structured, consistent way to take ideas from conception to validated prioritization. Without it, good ideas would stall, bad ideas would move forward on momentum alone, and the design team would spend more time reacting than shaping.

What became known as the Blueprinting Process emerged from a genuine three-way collaboration between myself, the Product Principal, and the Technical Principal. That's not a detail — it's the point. A framework built by design alone would have solved a design problem. A framework built across all three disciplines solved a program problem. Each of us brought our lens, our constraints, and our deep expertise to something none of us could have built as well independently. Think of it like weaving. Product, Design, and Technology each brought their own thread — distinct in texture, weight, and color. The Blueprinting Process was what emerged when we learned how to work the loom together. The result was a repeatable path for taking an idea through structured exploration and validation before it ever reached a development team — giving product owners the confidence to move forward, or the clarity to pause and revalidate. It also became an upskilling tool for newer product owners, giving them techniques to break down and structure ideas in a way that made them stronger partners to design and engineering alike.

It was one of those pieces of work that doesn't show up in a portfolio the way a beautiful screen does. But it changed how the program operated. And it only worked because three principals brought the full depth of their craft to a shared problem — and trusted that the combination would be stronger than any single perspective. It was.

DesignOps and design quality at program scale

Alongside the Blueprinting Process, I was asked to weigh in on and eventually own the program's DesignOps — the tooling, the processes, the ways of working that would allow a distributed design team to produce cohesive, high-quality work across multiple products simultaneously.

My bread and butter. There is nothing I find more energizing than helping to align work across multiple products and workstreams so that the overall experience lands correctly — not as a collection of individually designed screens, but as something coherent and intentional that a user experiences as one thing. Sometimes that meant empowering the program-wide designers to manage alignment themselves. Sometimes, depending on the complexity or the politics of a situation, it meant stepping in directly. Most of the time it was about finding how design could flex and morph to enable the work to move forward without sacrificing the integrity of the overall experience.

The crucial conversations

My counterpart relationship with the client design leader was one of the most important of the engagement. The conversations we had weren't always easy — but they were always necessary.

Some of them were about the ongoing case for design in a company that had spent most of its history making physical things. Software design, experience design, the idea that how something feels to use is as important as what it does — these weren't intuitive truths in this environment. They had to be demonstrated, argued for, proven through the work. That's the hill design keeps climbing in organizations that are new to it. I'm comfortable on that hill. I've learned to bring evidence, bring empathy for where the organization is coming from, and bring patience for how long genuine cultural change takes.

Other conversations were about people — how to grow the designers on the team, how to find the right contexts for them, how to give feedback in a way that lands and sticks. Those conversations require the same radical transparency I bring to everything, and the same belief that honest, caring feedback is one of the most generous things a leader can offer.

What this project taught me

The most important design work on this engagement wasn't a screen or a flow or a component. It was a process that helped a program think more clearly, a DesignOps foundation that let a team work more cohesively, and a set of relationships built on trust and honesty that made difficult conversations possible.

Design leadership at program scale means accepting that your impact is often invisible — embedded in how a team operates, how decisions get made, how quality is maintained across work you didn't personally touch. That invisibility used to feel uncomfortable. Now it feels like the point.

When that dealer moved through our solution intuitively, navigating complexity without friction — they didn't know about the Blueprinting Process or the DesignOps framework or the crucial conversations that shaped the work. They just knew it worked.

That's enough.