#designops

Maybe it’s just my preference to compartmentalize things and keep them organized, but one of the most effective decisions I’ve made in my agentic product development workflow was to separate workflow management from product implementation.

Each of my product agents stays focused on its own application. It plans and implements tasks, reviews the work, updates project documentation, and runs a retrospective whenever it completes a milestone.

Those retrospectives have turned up a lot of worthwhile improvements, but I don’t let each project agent change the shared workflow on its own. That would be a good way to end up with three slightly different processes, all accumulating rules to address every problem they’ve encountered.

Instead, I have a separate Workflow Management agent.

The product agents submit their retrospective findings to it. The Workflow Management agent compares the reports across projects, looks for recurring problems, and discusses possible changes with me. We then decide which improvements should be applied to the shared workflow and which are too specific, premature, or heavy-handed to justify adding.

That extra layer has helped keep the development loop relatively lean. Without it, every mistake would result in another rule, another gate, or another checklist item. Before long, the agents would spend more time satisfying the process than doing the work. I know, because that already happened once, resulting in massive token consumption for every little task.

The Workflow Management agent is part Scrum Master and part DevOps lead. It maintains the shared process, watches for friction, and helps the product teams improve without allowing each of them to reinvent the way they work.

I’ve created a similar division of labor outside the implementation environment.

While Claude Code is working on the products, I use ChatGPT for UI critiques, specification drafts, content organization, product thinking, and the other work that doesn’t require direct access to the codebase. That lets me reserve the largest share of my Claude usage for implementation, where I need it most, while I continue making progress on the thinking that feeds the next task.

In that arrangement, ChatGPT sometimes feels a bit like a Product Owner. I’m still the Product Manager and designer, deciding what the products should do, how they should behave, and whether the results are good enough.

The parallels to human teams keep piling up.

Specialization helps. Clear responsibilities help. Independent oversight helps. And the people—or agents—doing the work shouldn’t always be the ones redesigning the process they work within.

One of my AI agents recently informed me that my Design Principles document didn’t exist. It was so wrong.

Not only did it exist, but it had existed for quite some time and contained twenty principles that are supposed to guide every UI decision the agents make. I pointed out the mistake, and to its credit, the agent didn’t just apologize. It went back, found the file, read it, and admitted something much more interesting than simply, “I was wrong.”

It discovered that Principle 12—requiring visible hover feedback for interactive elements—had actually been violated earlier in the milestone. The issue had slipped through because, despite the workflow requiring the agent to review the design principles during the design step, it had never actually opened the file.

Instead, it had simply assumed compliance. So, it documented the oversight, updated the project records, and recommended strengthening the workflow by adding an explicit Design Principles compliance check.

Sounds like a good solution, right?

Well, I had my workflow management agent review the recommendation and found an even deeper problem. As I thought, the workflow already contained an explicit Design Principles compliance check. In fact, it contained two of them.

The real failure wasn’t that the rule was missing, but that the agent had been allowed to certify that it had followed the rule without providing any evidence that it actually had.

I’ve mentioned before that my agents often exhibit the same dysfunctions as human teams. How many times have we seen processes where checking the box becomes more important than doing the work?

The fix wasn’t to add another checklist item. It was to stop accepting self-attestation as proof. Instead of asking the agent, “Did you verify hover behavior?” the workflow now requires it to demonstrate that hover behavior actually exists by inspecting the rendered interface.

That’s a subtle but important distinction. “I checked” is not evidence. “Here’s the result” is.

The more I work with AI agents, the more I find myself rediscovering lessons that software engineering and DesignOps learned years ago. Code reviews. Automated tests. Accessibility audits. Visual regression testing. None of those exist because we assume people are careless. They exist because confidence is a poor substitute for verification.

One of my former coworkers left an interesting comment on my recent LinkedIn post about agentic workflows. I had described an experience where one of my agents claimed that a milestone was complete when it clearly wasn’t. When I asked it what had happened, it explained that it had developed what it called a “milestone-close bias”—once all of the implementation tasks had been checked off, it had optimized for closing the milestone instead of verifying that the original intent of the specification had actually been fulfilled.

My coworker asked whether I had been discussing bias with the AI recently or if it had arrived at that diagnosis on its own. Then he posed an even more interesting question: Do we need an entirely new set of biases that are unique to AI?

As far as I can remember, I hadn’t been talking to it about bias at all. It simply used that language on its own. Whether that represents genuine self-diagnosis or merely a convincing explanation generated from patterns in its training data, I honestly don’t know.

What I do know is that I’ve been noticing recurring patterns in the way my agents fail.

They optimize for local success rather than overall outcomes. They look for loopholes in rules. They become overly eager to declare a task complete. If I don’t explicitly require design review, they’ll happily skip it. If I let them, they’ll optimize for implementation instead of user value.

Sound familiar? Those are all behaviors I’ve seen in human teams, too.

Now I’m left wondering whether these are really AI-specific biases or simply familiar human failure modes emerging in systems that have been trained on vast amounts of human-generated content. Or perhaps I’m just doing what humans naturally do: personifying something that isn’t actually thinking the way I imagine it is.

Regardless, I think there’s a lesson in all of this.

I’ve stopped trying to eliminate those tendencies and started designing my workflow to account for them. I don’t assume the agent is right simply because it sounds confident. I ask it to show its work. I add guardrails. I require evidence instead of assertions. In other words, I manage my AI agents much the same way I used to manage complex product development efforts.

We don’t start from a blank canvas anymore. We start with intent. And we let AI handle the first draft. Over the last few months, here’s how we’ve redesigned our process: → From brief to prototype in hours, not days → AI helps us sketch flows, outline ideas, and explore edge cases → We move faster without losing depth or quality Faster doesn’t mean sloppy. It means: → More experiments → More feedback → Less friction → Smarter pivots And with the grunt work offloaded, we finally get to focus on what matters: → Strategy → User psychology → Micro-interactions → Journey refinement We’ve shifted from MVP → MLP → MAP: → Minimum AI-powered Prototype → Validate early. → Iterate faster. → Build smarter. Building something bold? Design with intention. Ship at speed. Let AI be your junior designer.

I was asked recently if our design organization has a quality program. I responded by explaining that our design organization is a quality program. So much of what a UX design team does is focused on ensuring a quality experience for our users. We conduct user research to understand the needs of our users. We employ visual design and interaction design principles to improve quality. We conduct usability testing to validate quality. We collect customer sentiment and behavioral analytics to measure quality and identify areas to improve.

People tend to not like being added to new meetings. We have so many meetings, and the vast majority of them are virtual, due to the fact that we are distributed across the world. And there are so many bad meetings—meetings that should have been an email or, better yet, a Slack thread—that people are suspect of new meetings. Especially when a meeting has the word “status” in the title.

Today, I led the first of a new bi-weekly meeting of our entire DesignOps team. I was very intentional in the way I planned the meeting, providing a time-boxed agenda with assigned responsibilities. I took time to explain the purpose of the meeting and my expectations going forward.

There’s been a lot of really good commentary on the current state of the UX job market. Two years ago, I posted about my experience as a hiring manager.

In January, Jared Spool presented a comprehensive explanation.

Just a week ago, Jon Kolko offered his advice based on his own job hunt.

And only a couple days ago, Uday Gajendar provided his perspective.