Oct 31, 2025
Equitable design patterns
This sounds like a fable. A stranger comes to a town with three families. The stranger visits each family and tells them a story. “The future is dark and unknown. There aren’t enough resources for all of the families to survive. The day is coming when one of the families will disappear. I can help you survive. Together we can prosper and all of the remaining resources will be ours. You don’t need them anymore, trust me.” The stranger visits each family one by one and makes them the same promise. He plays all sides against each other and at the end, emerges as the only survivor.
If this sounds familiar, it’s the premise for Yojimbo, For a Fistful of Dollars and Last Man Standing. Its also the dynamic that I feel I’ve seen as the triad of product, design and engineering grapple with the role of AI in product development. The market is eager to deliver a set of magical tools that promise to save everyone time and offer them independence. A number of these tools offer to extend each functions existing skills, so they overlap with their counterparts and blur traditional roles and responsibilities.
For healthy and mature teams, this is very exciting. I‘ve read about large organizations with well established workflows extending the power of collaboration and existing systems, finding ways to align on best practices for responsible application of AI on internal workflows and within the products they create.
Unfortunately, I fear these are the exceptions rather than the rule. The following is based solely my own observations and experience working on cross functional product teams.
Many teams are still young and have yet to formalize their principles, culture and collaboration efforts. Some teams are made up of insecure humans trying to get their heads around if their role or function will survive the change that they fear is coming. Designers, product managers and engineers don’t know if robots or another team member using a robot will make them obsolete. Some teams are made up of conflicted humans who have doubts about the usefulness or reliability of these new tools, but are being told they do not have a choice. The company mandate says, find a way to use them.
Meanwhile tool makers are doing what software makers have always done. They are selling. Selling requires understanding your potential market’s motivations, needs and fears. The same insecurity that exists within each function, seems to be playing out with software makers. “Will a design tool start generating code well, or will a coding tool start designing well, or will a general purpose tool do both?” The sentiment has software providers pivoting from code or design only tools into hybrid MCP powered systems that blur traditional categorization. “Multi modal product development tools?”
And so it happens, the mysterious stranger approaches you and makes a promise. “As far as I can see, you’re the one who’s truly unique. You don’t need a team, I can give you the power to make magic all by yourself.”
How can we take care of ourselves and each other? Its been refreshing to see champions in this space strive for new ways to collaborate. I've been to several demos from members of the design and engineering worlds actively looking for ways to bring everyone closer together. I’ve seen designers create high fidelity prototypes as a way of delivering their intent to engineers who then take things much further much faster. I’ve seen design systems engineers build connections between design and coded assets that feels like true parity and the hope of a single source of truth really is possible.
My fear is that there’s still a big and widening gap. The subtleties of the examples I describe take a lot of infrastructure and support to really pull off at scale. I’m afraid these details are lost on the ears of eager individual contributors entering the market looking to stand out in a highly competitive space, and business drivers who are looking for ways to do more with less.
Try take care of yourselves and others.