Manaswi Shukla argues that most AI failures are not algorithmic, but design failures rooted in a lack of trust, clarity, and user control. Drawing on two decades of experience, he outlines a framework where automation earns autonomy gradually, humans retain ownership of critical decisions, and recovery matters more than raw accuracy. His work reframes responsible AI not as a technical constraint, but as a design leadership responsibility that determines whether intelligence truly helps—or quietly harms—expert users.
In 2014, a startup built what should have been a breakthrough—AI that automated data placement to optimize cost and performance. The algorithms worked. The infrastructure scaled. But experienced data administrators rejected it outright.
“Lacking visibility into how decisions were made and control over the system’s behavior, the automation felt like a black box,” recalls Manaswi Shukla, who designed the system. “Instead of helping them, it actively undermined their trust.”
That failure taught him what two decades of successful projects had not. “In complex systems, design, not algorithms, is the limiting factor.” Now Global Head of UX at Bloomberg, Shukla leads multidisciplinary teams creating AI-driven solutions for complex financial platforms. His work spans predictive analytics, automation systems, and conversational AI—always with a focus on building intelligent systems that expert users actually trust.
His philosophy emerged from that 2014 failure: “The role of UX is to erase friction between human intent and machine execution, ensuring that efficiency never comes at the cost of clarity, trust, or control.”
Through years of shipping AI systems at Google, Twilio, VMware, and high-growth startups, Shukla has distilled four core principles:
These principles emerge from a simple reality: most AI failures are not model failures. They are design failures.
“Until you understand what success looks like for the user, it is impossible to place AI responsibly,” Shukla emphasizes. His input/output framework provides the first decision point.
Consider a sales workflow where AI drafted email responses based on customer history. “The system handled the heavy lifting on the inputs, such as research and initial drafting. But because the task was of high criticality and a hallucinated response could cost millions, the human agent had to own the output.”
“Even in lower-risk tasks, if users do not trust the system, they will verify the work anyway. This is why AI must earn autonomy over time rather than assuming it by default.”
But here is the tension. Earn trust too slowly, and adoption stalls. Earn it too quickly, and the first failure destroys credibility permanently. “When AI attempts to own outputs prematurely, it risks deskilling the user and stripping away necessary agency.”
Design leadership must calibrate not just where AI stops, but how quickly that boundary moves.
“I am a strong believer in experimentation, and I take pride in failed experiments,” Shukla says. “In complex systems, failure is how you surface the constraints that matter before scale amplifies them.”
At one company, nearly every team proposed an AI solution, most defaulting to conversational interfaces. “We eventually learned that chatting with a bot is not a catch-all solution for user problems. Intelligence was being sprinkled across products without a cohesive strategy, and users rejected these experiences outright.”
Design leadership intervened, killing multiple chatbot initiatives despite executive enthusiasm. This came at a cost—political friction, delayed launches, and visible disappointment. “In many cases, it was not a chat interface at all,” Shukla recalls. The teams re-centered on user journeys, identifying where intelligence could genuinely help and what form it should take.
This willingness to refuse deployment separates responsible AI design from feature theater. “Accuracy alone does not equal usefulness. If an experience does not reduce time to value, improve decision quality, or increase user confidence, it does not belong in production, no matter how impressive the model appears.”
When AI does ship, Shukla employs progressive automation. In one system, his team inverted conventional practice. “We turned off automation by default. Instead, we showed users what the system could do and gave them low-risk opportunities to opt in, allowing trust to build at the user’s pace.”
“To build trust, we need to move beyond merely surfacing insights and focus on helping users act on them. Predictive systems should provide clear next-best actions grounded in user intent so people are not left guessing what to do next.”
“Transparency does not come from long explanations. It comes from baking the ‘why’ and the ‘what’ directly into the experience. Users should feel why the system is confident through its behavior rather than being required to read an explanation panel.”
When explanations are necessary, Shukla designs around decision drivers, not model internals. “I highlight what signals mattered, what changed since the last recommendation, and what was intentionally ignored. This gives users mental models they can trust without overwhelming them with technical detail.”
But what happens when the system is consistently confident and consistently wrong? Shukla maintains a strict separation between prediction and action to prevent this failure mode. “Insights inform, whereas automation acts. The user must control the handoff.”
“If the system is right ten times in a row, users naturally begin to trust it. But trust collapses quickly if users cannot correct it when it is wrong. A system that allows recovery earns far more confidence than one that simply claims accuracy.”
The deeper insight is this: transparency without recovery is performance theater.
“Close collaboration across design, engineering, and data science is no longer optional. We must align from the very beginning to design, architect, and operate models toward a shared outcome.”
But alignment does not mean harmony. At one startup where Shukla worked, the CEO often said, “You figure out what data is right for the user, and I’ll make sure data science provides it.” The reality proved more complex. “In practice, it never worked that way. There was constant negotiation between design, engineering, and data science to balance what was feasible, what was accurate, and what was genuinely useful.”
“I learned that designing AI systems is rarely about delivering an idealized experience. It is about meeting users in the middle without compromising trust.”
Design’s unique value lies in translation and constraint-setting. “Design adds its most unique value by translating abstract model capabilities into concrete user intents, workflows, and decision moments. It also plays a critical role in defining guardrails, defaults, and failure modes that engineering alone cannot determine.”
“When organizations pick up a new hammer, everything starts to look like a nail,” Shukla says. “Every workflow suddenly feels like it should be solved with AI.”
The pattern reveals itself in telling ways. In one case, an executive asked why the team couldn’t just “AI the whole experience.” The question exposed a deeper problem: leadership had confused deployment velocity with strategic clarity. Intelligence was being treated as a feature to sprinkle across products, not as a capability requiring disciplined integration.
Design leadership must shift the conversation away from the excitement of AI and toward what users actually need. AI should be woven into the experience strategy rather than standing out as a novelty.
The opposite failure mode is equally damaging. “At the other extreme, I have seen organizations become overly cautious, especially in domains where data accuracy and risk are paramount. In these cases, design leadership can help by creating safe experimentation frameworks that allow teams to learn incrementally without jeopardizing trust.”
“Design leaders must set clear standards for what good AI implementation looks like from a user’s perspective and hold teams accountable to them. Trust does not automatically follow adoption. It must be designed deliberately, with clear ownership, override paths, and recovery mechanisms.”
“Early on, the focus needs to be on leading indicators like accuracy, usefulness, and reliability. This is why I strongly believe in releasing AI capabilities to a smaller cohort first and defining clear gating criteria before expanding adoption.”
But even defining the right indicators proved counterintuitive. “At a previous company, we initially expected users to actively rate AI output. That rarely happened. Users were focused on doing their jobs, not evaluating our systems.”
The team shifted from asking to observing. “We looked at whether AI-generated content was actually being used in daily workflows. Were users copying it as is, editing it heavily, or discarding it altogether?”
The behavioral signals revealed an uncomfortable truth: users were editing AI outputs far more than expected. “In the case of AI-assisted emails, we tracked whether messages were sent without modification or required significant rework. These signals proved far more reliable than self-reported feedback.”
The harder question followed: how do you distinguish productive editing from defensive editing? Teams began correlating edits with downstream outcomes—send times, response rates, and escalation patterns—to understand whether edits improved results or merely reduced perceived risk.
Measuring AI success requires creativity. Design leadership plays a critical role in defining these signals early and ensuring teams measure what truly matters before scale locks in the wrong outcomes.
The role of design shifts from shaping interfaces to shaping systems, behaviors, and decision-making dynamics. Design increasingly defines how intelligence is introduced, constrained, and governed rather than just how it is presented.
Design leadership must own three decisions in AI systems. Delegating them is a failure of leadership.
First, the decision to deploy AI at all. Design should never delegate the question of whether AI belongs in a workflow. This means being willing to kill AI features even when they are technically impressive, even when executives are excited, even when competitors have shipped similar capabilities.
Second, the metrics that define success. Design must define and own the leading indicators that predict whether AI will earn trust: accuracy in context, usefulness in workflow, reliability under edge cases, and recovery when wrong.
Third, the constraints that prevent harm. “We carry an ethical responsibility to advocate for AI that respects user privacy, preserves an open internet, and values human judgment rather than replacing it. Responsible AI is not an abstract principle. It shows up in everyday design decisions with real-world consequences.”
“Ultimately, the future role of design leadership is not just to decide how AI should behave, but where it should not intervene at all.”
The transformation of enterprise design through AI demands the courage to say no, the discipline to measure what matters, and the conviction to preserve human agency even when automation seems easier.
If design is not willing to refuse AI deployments that fail users, it is not ready to lead them.
The question is no longer whether AI belongs in enterprise products. The question is whether design leadership is prepared to own where it intervenes—and crucially, where it must not.
—
Manaswi Shukla is Global Head of UX at Bloomberg, where he leads multidisciplinary teams creating AI-driven solutions for complex financial platforms. With over two decades of experience at Google, Twilio, VMware, and high-growth startups, he has consistently focused on elevating design quality, advancing predictive and automation technologies, and strengthening cross-functional partnerships between design, engineering, and data science. His work bridges the practical realities of AI integration with human-centered design principles, demonstrating that measurable business outcomes emerge from well-orchestrated technology, strategy, and user empathy.
The startup aims to solve the investigative bottleneck in anti-money laundering by replacing manual analysis with autonomous, evidence-based AI agents.
Radhika Venugopal’s work leading federal Consent Order Remediation and enterprise Generative AI delivery rests on a conviction that most AI initiatives miss: the algorithm may be the brain of the system, but production readiness—the unglamorous work of network connectivity, governance, and cross-team accountability—is the nervous system that actually determines whether a pilot ever reaches users. Her core argument is that democratizing wealth management data isn’t really a technology problem at all; it’s a culture change disguised as one, where the real measure of success is whether advisors get back enough time to ask their clients the questions no algorithm ever could.
Sreema Rajendran’s two decades navigating enterprise AI at Bank of America have produced a deceptively simple diagnosis: most organizations don’t stumble because their pilots fail—they stumble because the architecture behind the pilot was never built to scale, and the hardest part of enterprise AI was never the model, but everything required to make that model communicate safely with decades-old systems. Her answer is a platform-first philosophy where compliance is governance-as-code, models are plug-and-play components, and developer empowerment is measured not by features shipped but by how broadly reusable the underlying patterns become across the enterprise.
