00:00 AM

When "Neat" Becomes "Noisy"

A while back, I was brought on as a consultant to help a team refine their design infrastructure. We hit a milestone I was genuinely proud of: we made the entire design system LLM-friendly. It was neat: components had a definition and a purpose, our variables were well defined, and the core design principles were taken into consideration via a skill system. It felt like we’d built something truly elegant and future-proof.

But looking back, it feels like we’d accidentally opened a door we weren't ready for.

Somehow the product managers got word of that workflow and started using it to generate their own designs, and the collaborative workflow started to haunt us. They started using it to generate their own designs, sometimes bypassing the entire design validation phase. It added more noise to the process—my design versus the PM design—plus some things weren't taken into consideration, like responsive views or dependencies with other flows. It just became a ping-pong between the PM asking the engineering team, "just made this. Can you do that?"

The most jarring part was the surprise. I’d walk into reviews or join a discussion only to find entirely "new" designs popping up that I’d never seen before. I get that this stems from culture, organizational processes, and even ego issues, but I genuinely felt the quest was disrespected, and frankly felt quite upset and surprised. It was frustrating to see screens being treated as a commodity, ignoring the years we’ve spent learning how to actually solve problems.

Navigating the Mess

Working through that project taught me that when a system becomes this accessible, the way we work together has to fundamentally shift. It wasn't about reclaiming control; it was about evolving into a more open, shared process.

1. Establishing a "Dynamic Check" for Everyone

We moved away from the idea that every screen appearing in a meeting had to be a "final proposal" from a designer. Instead, we started treating those high-fidelity AI designs as valid starting points, no matter who brought them to the table. We stopped "validating" the PM's work and instead set up a dynamic check at the handover to development. This check applied to everyone—designers, PMs, and even developers. Interestingly, the engineering team welcomed this; they felt their own ideas were finally being invited into the conversation rather than just being told what to build.

2. From "Calling the Shots" to Building Hand-in-Hand

We had to stop dictating who was in charge of specific outputs. We shifted the focus entirely toward building a better product, regardless of who pushed the pixels or who wrote the PRD. It became a hand-in-hand effort where authorship mattered much less than the end result. By removing the "shot-caller" mentality, we turned what felt like a competition into a genuine collaboration where we were all just trying to get the best version of the product out the door.

3. Drawing the Line on Automation

The most important lesson was realizing we had to define exactly where the "neat" system should lose control. We had to draw a clear line where automation ended and human judgment had to oversee the result. It was about identifying the moments where the system’s logic wasn't enough—where empathy, intuition, and a deep understanding of the user were required to make the final call.

That project was a tough one, and it didn't end with a "happily ever after." It ended with a better understanding that while tools make things faster, they don't make the human part of building products any easier. We just had to keep showing up and advocating for the craft, even when the noise felt overwhelming.