Forward Deployed Designers: From FDE to FDD

Summary: Forward Deployed Engineers (FDE) can build powerful AI systems, but enterprise transformation requires more than technical deployment. Organizations need Forward Deployed Designers (FDD) who can map business outcomes, redesign decision rights, and convert AI capability into operational change.

(All images in this article made with GPT-Images-2)

The OpenAI Deployment Company (often called DeployCo) is OpenAI’s new consulting venture to help enterprises design, build, and productionize AI systems using OpenAI’s AI models. They recently announced a $4 billion investment in DeployCo and partner agreements with several big (if legacy) consulting companies, including Bain & Company, Capgemini, and McKinsey & Company. More interesting than the old-school collaborators is the deal for DeployCo to acquihire 150 Forward Deployed Engineers from the more leading-edge consulting company Tomoro.

A Forward Deployed Engineer (usually abbreviated “FDE”) is a software engineer who does not sit in a siloed product team at a remote headquarters. Instead, the FDE embeds directly with client organizations to design, customize, and deploy a company’s technical platform in the client’s real operating environment. This is one of the best ideas to come out of Silicon Valley recently, because the FDE becomes a discovery mechanism for features to build into the product.

Sitting with customers on the front lines and experiencing firsthand what works and what fails beats any amount of speculation by designers or product managers sequestered back at headquarters. This is especially true for domain-specific, complex enterprise apps, whether that involves tracking logistics on a massive shipping port, managing supply chain reconciliation in a pharmaceutical plant, or navigating compliance auditing in a global financial institution. Context is king, and the FDE breathes the context daily.

Context is King: being on-site beats sitting back at HQ and speculating on what customers need.

But context has a dangerous side. The person who lives inside a workflow can become over-adapted to it, accepting the organization’s weird rituals as facts of nature rather than fossils of past constraints. The best field work does not merely absorb context; it must also create enough distance to challenge context. This is the crucial difference between being an embedded outside expert and being existing company staff.

Question the rituals. Tradition is rarely a reason to keep doing things the old way, especially when conditions change radically, as they do with AI.

DeployCo claims that their FDEs will have access to the next generation of AI models from OpenAI, enabling them to build customer solutions that leverage where AI is going rather than where it has been, as most enterprise IT teams do.

The Trap of Local Optimization

Embedding technical talent directly with clients is a brilliant model for traditional software, but engineering alone isn’t enough to unlock the true value of generative AI. In traditional software design, we aim to identify users’ pain points in their existing workflows and design a UI that enables them to get their work done faster and more easily. If an accounts payable clerk spends three hours manually matching invoices to purchase orders across two clunky systems, traditional software attempts to digitize, integrate, and streamline that manual process.

A good FDE can spot these friction points in the field and communicate them to a UX team back at HQ, where they can be transformed into polished product designs. (Some of that polish is added through traditional user testing, where we easily see if, for example, a command name violates the users’ mental model. If so, change it and save a few hours of training time.)

With AI, the old workflows must no longer be treated as the design brief; they must be questioned at the root. AI is, in fact, a great productivity enhancer even when used in the traditional way to increase the efficiency of individual employees performing the same tasks as always, just faster and better. A paralegal can summarize a legal brief in seconds; a junior developer can write boilerplate code instantly; a digital marketer can generate campaign copy with a single prompt. We can typically improve that employee’s performance on those specific rote tasks by roughly 40%.

But at the company-wide level, such local productivity gains rarely translate into substantial profit gains and shareholder value. When you have a long chain of steps and optimize only a few, the delay simply shifts to the remaining steps, which will dominate the overall time to solve the underlying problem.

Local fixes to specific tasks are fine, as far as they go, but they don’t go far enough to revolutionize business. We must take a wider view and redesign the full workflows for the new AI opportunities.

Consider an enterprise commercial loan approval process. The workflow consists of data gathering from the client (Task A), initial risk assessment (Task B), legal compliance review (Task C), pricing formulation (Task D), and final managerial sign-off (Task E).

If an FDE embeds with the initial risk assessors and builds an AI-powered tool that speeds up Task B by 40%, the business may assume it has achieved a corresponding operational win. But if Task B was never the ultimate systemic bottleneck, the overall cycle time won’t improve. If Task C (the legal compliance review) remains constrained by traditional, unoptimized human limits, the newly accelerated risk assessors are simply piling up completed assessments at the door of the legal department faster than ever before. The overall time it takes for the customer to receive a loan decision may only have been shortened by a few minutes. You have fundamentally changed nothing about the business model; you have merely hurried up the process of waiting. The business value of that 40% speed boost on Task B is swallowed by the friction of the legacy workflow.

Increasing the speed of one step won’t buy you much overall efficiency if the other steps remain slow.

The correct unit of analysis is therefore not task efficiency but system throughput. A company does not get paid more because one employee finished one intermediate activity faster. Profits only grow when the entire value stream moves faster, with fewer defects, less rework, and less managerial expediting. Local AI often increases work-in-progress inventory: more partially completed cases, more pending approvals, more items waiting in queues. This can even make the organization feel busier while making the customer experience no better. The FDD’s job is to redesign the flow, not celebrate the acceleration of a single eddy in the stream.

AI-Native Workflow Redesign

Full workflow redesign is required to take advantage of AI’s new capabilities for removing steps entirely and designing human limitations out of the system.

Historically, corporate workflows were designed to accommodate human cognitive and physical limits. (In fact, that was our traditional goal in human factors engineering — thus the name.) Humans are mostly serial processors: we do one cognitively demanding thing at a time, have sharply limited working memory, require sleep, and operate within work schedules, burning out if we work more than 60 hours per week for any length of time. Well-designed legacy corporate processes reflect these constraints.

We used to design to overcome human limitations, which have remained constant over the decades, leading to stable usability guidelines. Now, we will be designing harnesses to compensate for AI limitations, which change annually, if not faster, so our UX guidelines for AI design will likely need to be updated frequently.

We introduced rigid approval hierarchies because a single human can only review so many documents in an hour and is likely to make errors. We created siloed departments because human expertise is narrow and specialized. We built complex status dashboards because human managers cannot keep the real-time state of 10,000 concurrent operations in their heads.

Agentic AI systems do not share these limitations. An advanced multimodal AI model can read a 500-page regulatory filing in seconds, cross-reference it against 10 years of historical company data, verify it against complex policy documents, and make an instant probabilistic risk assessment. It can process thousands of these files in parallel. And it works 24/7, vastly facilitating international business operations across time zones.

If we simply use AI to help a human read the document faster, we are leaving the vast majority of the technology’s potential on the table. We must completely abandon the old workflow. The new workflow shifts the human out of the data processing phase altogether, elevating them to the role of an orchestrator, strategic decision-maker, or exception-handler.

Once AI removes the cognitive bottleneck, a different bottleneck appears: authority. The limiting question becomes not “Can the system know what to do?” but “Is the system allowed to do it?” AI-native workflow design must therefore redesign decision rights, escalation rules, audit trails, and accountability boundaries. Otherwise, the organization merely replaces slow human cognition with fast machine recommendations waiting for the same old human permission structure.

AI is fast. Humans are slow. This means that if humans have to approve every last thing the AI has done, we won’t realize the needed workflow efficiencies.

Permission structures will need continued redesign as AI becomes more capable with each release. As the banner says, it’s a design choice which AI actions require human review. Too many, and nothing gets done, plus safety is undermined by overwhelming the humans, leading them to approve without sufficient reflection.

I don’t believe most FDEs are capable of such revolutionary workflow redesign. Their training, incentives, and core competencies are rooted in technical problem-solving, systems architecture, algorithmic optimization, and code execution. Give them a defined problem, and they will build a flawless technical solution. But asking them to fundamentally reimagine the operational blueprint and human dynamics of a Fortune 500 company is outside their mandate. They are trained to optimize the “how,” not fundamentally question the “why.”

The obvious objection is that the best FDEs will say they already redesign workflows, and in a limited sense they do. There’s no monopoly on human factors thinking. But engineers’ redesign typically begins from the computational affordances of the platform: where data resides, where APIs connect, where latency appears, where a model can be inserted. The FDD begins one level higher, with the social contract of the work: who is allowed to decide, who must be informed, who bears risk, and which organizational ritual exists only because yesterday’s tools were dumb. That is not a smaller version of engineering. It is a different starting point.

Equally, I don’t believe most current UX professionals can do this either, limited as they are in their thinking by years of designing pre-AI solutions. For four decades, the UX industry has been obsessively focused on screen design, click-reduction, visual hierarchy, and graphical user interfaces (GUIs). Traditional UX asks, “How do we make this form easier for the human to fill out?” AI-native design asks, “Why does this form exist at all, and can an autonomous agent negotiate this data exchange in the background without human intervention?”

However, workflow redesign at this scale is, at its heart, a massive service design problem. It requires taking a step back, examining the ultimate goal of the business ecosystem, and architecting an entirely new way to achieve that goal. It should be attacked with solid user research and innovative service-design methods. These are firmly within the broader UX wheelhouse, and I firmly believe the best, most adaptable UX professionals of today will evolve into the AI workflow designers of tomorrow.

Introducing the Forward Deployed Designer (FDD)

To realize the true transformative value of enterprise AI and bridge the massive gap between technical capability and organizational transformation, I suggest inventing a new consulting category. Whether formalized within DeployCo, adopted by legacy consulting companies like McKinsey and Bain, or championed by the inevitable wave of new agile boutique firms founded specifically to exploit AI opportunities: We need Forward Deployed Designers, or FDD.

FDEs are great, but we also need FDDs to realize the full potential of AI for improving company performance.

An FDD is a hybrid professional: part ethnographic researcher, part macro-systems service designer, and part AI product strategist. Like the FDE, the FDD does not sit in an ivory tower at headquarters. They embed directly on the factory floor, in the trading room, in the hospital ward, or within the back-office cubicle farm. But where the FDE embeds to understand the data architecture and API endpoints, the FDD embeds to understand the business intent, the human psychology, and the deeply ingrained legacy constraints of the organization.

What exactly makes a Forward Deployed Designer? It is not simply a traditional UX designer given a trendy new title, nor are they merely an AI prompt engineer. They combine ethnographic observation, systems reasoning, organizational judgment, and enough technical intuition to know which fantasies can be built.

The missing fourth ingredient is political literacy. Workflows are not merely sequences of tasks; they are settlements among departments, professions, budgets, regulators, unions, managers, and status hierarchies. A field designer who cannot read the informal power map will mistake an org chart for an operating system. The real workflow is often hidden in who can say no, who can override the system, who gets blamed when exceptions occur, and which spreadsheet everyone trusts more than the official dashboard.

Map the internal company politics and power structures, which often deviate from the official org chart.

Core FDD Attitudes and Mindsets

• Constructive Irreverence (Radical Deconstructionism): FDDs must possess an almost ruthless willingness to kill existing processes. They cannot be intimidated by “the way we’ve always done it.” They must have the fearless willingness to look a client executive in the eye and say, “We aren’t going to build an AI tool to help your team process these forms 40% faster. We are going to build a system that eliminates the need for these forms to exist entirely.”

• Replace User Advocacy with Outcome Advocacy: Traditional UX rightly minimizes user effort within the current task. The FDD goes one level higher. Sometimes the right design is not to make the current job easier, but to eliminate the task and move the human into governance, judgment, or relationship work.

It’s probably a bitter pill to swallow for many old-school UX folks, but user advocacy is no longer our job. We should not advocate for the outcome of AI processes, many of which will involve no human users.

• Extreme Comfort with Ambiguity: Pre-AI software is deterministic: if a user clicks a button, the exact same thing happens every single time. AI is probabilistic, generative, and non-deterministic. Responses vary based on context; hallucinations happen, even if less frequently, as models improve. The FDD must thrive in this ambiguity, designing systems that accommodate flexible, conversational, or agentic interactions rather than rigid, linear pathways.

Core FDD Skills

• Macro-Systems Thinking: The ability to zoom out from a single user interface and hold a mental model of an entire enterprise’s operational architecture. An FDD must understand how changing a workflow in the procurement department will impact the data pipelines and human cognitive load in the legal department downstream.

• Deep AI Capability Literacy: While they do not need to write production-ready Python code or train neural networks, an FDD must fluently understand the “grain” of AI. They must know the practical limits of context windows, the nuances of harnesses, the realities of data latency, and the boundaries of model reasoning. Without this literacy, they will design science fiction that cannot be built.

• Workflow Observability: FDDs must make invisible work measurable before they redesign it. They should instrument cycle time, queue length, rework, exception frequency, approval latency, handoff failure, data re-entry, and the number of times people leave the official system to get the real job done. Without this observability layer, redesign becomes workshop theater: persuasive diagrams unsupported by operational evidence.

• Rapid Conceptual Prototyping: FDDs must move at the speed of thought. Using off-the-shelf AI, API wrappers, and no-code connection tools, the FDD must be capable of stringing together low-fidelity mock-ups of AI workflows to test human reactions and system logic in days, rather than waiting months for formal engineering.

Uncovering the Invisible: Methods for Observing Users in the AI Era

Before an FDD can redesign a workflow, they must deeply understand the reality of the current state. However, traditional UX research methods, like my beloved lab-based usability testing, where you watch a user click through a prototype and ask what they think, are woefully inadequate for AI redesign. Human beings are notoriously bad at accurately describing their own workflows. They omit steps they perform automatically; they fail to mention ad-hoc workarounds; and they confidently state they follow standard operating procedures when, in reality, they rely heavily on tacit intuition.

FDDs must act as workplace anthropologists, deploying immersive research techniques to uncover the “invisible work” that AI is perfectly suited to absorb. (See the comic strip I made about why UX Anthropologists have the most valuable skills in tech these days.) Tacit knowledge elicitation becomes the decisive research method.

Just as important is decision-rights mapping. The FDD must learn not only what people do, but what they are authorized to decide, what evidence they consider sufficient, when they seek cover from a superior, and which approvals are genuine safeguards rather than inherited ceremony. Many workflows look like information-processing systems, but are actually liability-distribution systems. Automating the information flow while leaving the liability architecture untouched produces timid AI: intelligent enough to recommend, but never empowered enough to transform.

Contextual Inquiry and Cognitive Task Analysis (CTA): Traditional shadowing often focuses on what a user does on their screen (Click A, Open B, Type C). Because AI is fundamentally a cognitive automation technology, the FDD must utilize Cognitive Task Analysis to discover what the user is thinking.

When an experienced insurance underwriter evaluates a complex policy, they aren’t just reading a checklist; they are applying years of intuition, recognizing subtle patterns in risk, and cross-referencing disparate data sources. The FDD’s job is to deconstruct this intuition. What memories are they accessing? What data points are they synthesizing? What specific edge cases cause them to pause? By mapping the cognitive workflow rather than just the physical workflow, FDDs translate human heuristics into system prompts and agentic reasoning frameworks, designing AI agents that augment high-level decision-making rather than just automating basic data entry.

Hunting for “Glue Work” and Shadow IT Archaeology: One of the most fertile grounds for AI workflow innovation lies in a company’s “Shadow IT,” the unofficial, unapproved systems employees invent to get around the limitations of their official software. FDDs aggressively hunt for sticky notes on monitors, sprawling, undocumented Excel macros passed around via email, and informal Slack channels where employees ask each other policy questions.

In legacy workflows, humans often act as the APIs between disjointed software systems. The FDD watches for the “swivel-chair integration moments” where a user exports data from System A, reformats it, and pastes it into System B. This human glue is cognitive drudgery. Any such workaround is an indicator of system failure and a blueprint for where a multimodal AI agent could simply read the screen of System A (or, later, retrieve it through a “headless” API), interpret the unstructured data, and autonomously populate System B.

In “glue work,” the user acts as a human computer and laboriously executes steps to connect different computer systems. AI should do this.

But shadow IT is more than evidence of broken integration. It is often the company’s real ontology. The unofficial spreadsheet reveals the categories employees actually use. The Slack workaround reveals the questions the official knowledge base failed to answer. The sticky note reveals the risk signal no database field was designed to capture. Before replacing these artifacts, the FDD must mine them for meaning. Otherwise, the new AI system will faithfully automate the official process while missing the practical intelligence that kept the business running.

Analyzing the Exception Landscape: In most enterprise workflows, standard operating procedures cover the routine 80% of the work. Humans spend a disproportionate amount of time and mental energy navigating the 20% of exceptions, edge cases, and anomalies. Traditional automation breaks down completely in the face of exceptions. Generative AI, however, thrives on unstructured ambiguity. FDDs should observe how experts investigate anomalies. By capturing the intuition and external research humans use to solve edge cases, the FDD can design AI guardrails that handle a vast majority of future anomalies autonomously.

Outcome Mapping via the “Magic Wand” Technique: Because users are anchored to the constraints of their current tools, if you ask them what they want, they will ask for a faster version of their current tool (the proverbial “faster horse”). FDDs bypass this by using the Magic Wand technique during contextual interviews.

They ask stakeholders: “If you had an infinitely capable intern who knew everything about this company, worked at the speed of light, and never made a mistake, how would you instruct them to achieve this outcome for you? What high-level work would you focus on while they did it?”

Try the magic wand technique in your next user interview.

This shifts the user’s mindset from executing tasks to managing outcomes. It decouples the user’s intent (the ultimate business goal) from their action (the steps they currently take to get there), revealing the true parameters of a successful job and providing the blueprint for what the AI needs to achieve autonomously.

Architecting the Future: Service Design Methods for AI Workflows

Once the existing realities of the work are understood, the FDD does not look for ways to incrementally speed them up. Instead, they pivot to advanced Service Design methodologies to synthesize their findings and build entirely new paradigms that take full advantage of AI capabilities. Service design is the craft of organizing people, infrastructure, communication, and material components of a service to improve its systemic flow. In the AI era, the infrastructure now includes autonomous, reasoning agents.

Zero-Based Workflow Design (First-Principles Ideation): Borrowing from the financial concept of zero-based budgeting, FDDs employ Zero-Based Workflow Design. Instead of taking an existing 15-step process and asking, “Which of these steps can AI do faster?”, the FDD starts with a completely blank slate.

Instead of taking an overly complicated legacy workflow and designing the most annoying parts out, success is more likely to come from a blank-slate approach: start with nothing and add only the most necessary parts.

They define the ultimate business goal, for example, issuing an accurate refund to a frustrated customer within 60 seconds. Then, they ask: “Given today’s frontier AI capabilities, if we assume an AI can instantly read the policy, verify the purchase history via an API, and generate the necessary database queries, what is the absolute minimum number of steps required?” The answer could easily be a reduction from 15 steps to two. Zero-based design forces the organization to let go of its attachment to legacy processes and prevents it from paving the cow path (automating inherited bureaucracy). It recognizes that using an AI to write an email, which is then sent to another human who uses AI to summarize that email, is an absurd waste of energy. The new workflow dictates that the two AI systems simply negotiate the refund directly via API.

This is a paradigm change for UX. The interface is no longer always a screen shown to a person. Sometimes the interface is a contract between agents: the data schema, confidence threshold, policy constraint, audit log, exception trigger, and permission boundary that allow two systems to complete work without dragging humans through the middle. In AI-native enterprises, designers will increasingly design service encounters that no customer, employee, or manager ever directly sees.

AI-Augmented Service Blueprinting: The core architectural tool of the FDD is the Service Blueprint. A traditional service blueprint maps the customer journey across the top, showing the “Front Stage” (what the customer sees) and the “Back Stage” (what employees do behind the scenes to support the customer).

The FDD introduces a radical update: the AI-augmented service blueprint. This framework introduces new, critical lanes:

• Front-Stage AI (The Copilot): AI systems that interact directly with the customer or collaboratively with the front-stage human in real-time.

• Back-Stage AI (The Autonomous Agent): AI systems running asynchronously in the background, executing long-chain tasks, monitoring unstructured data streams, and preparing environments before the human even knows they are needed.

Front-stage AI is AI that interacts with a user. But most of AI design will be back-stage AI that works on its own, without humans.

By mapping these lanes together, the FDD visually demonstrates how the workflow shifts from “human doing the work, assisted by a machine” to “machine doing the work, governed by a human.” It clearly defines where entire columns of traditional back-stage human processing can be eliminated, and where human-AI handoffs must occur.

Capability Matching and Role Re-architecture: In a pre-AI world, human job roles were dictated by the limitations of technology. A “Data Entry Clerk” job only exists because computers couldn’t read unstructured handwriting.

The FDD uses a matrix called Capability Matching to challenge this. They map the required steps of the newly designed, zero-based workflow against the unique strengths of Frontier AI (pattern recognition, infinite patience, instant synthesis, multilingual translation, parallel processing) versus the strengths of humans (empathy, moral judgment, relationship building, physical-world presence, legal accountability).

One of the many strengths of AI is its ability to do many things in parallel. Humans can do only one thing at a time, and when they try to multitask, errors explode, and inefficiencies abound.

Tasks are assigned strictly based on this matrix. If a task requires empathy and accountability (e.g., calling a client to inform them their loan was denied), it is assigned to a human. If the task requires synthesizing 400 pages of financial history to determine if the loan should be denied, it is assigned to the AI. This process inevitably results in the complete rewriting of HR job descriptions as a natural byproduct of the design process.

Designing the “Human–AI Handoff” (Friction as a Feature): Because generative AI models are probabilistic, meaning they can confidently hallucinate or make incorrect moral judgments, workflows cannot be fully autonomous out of the gate, especially in enterprise environments burdened with compliance and risk. Therefore, one of the most critical elements of AI service design is the point at which the AI stops, and the human takes over.

Traditional software design strives for seamlessness. In AI systems, FDDs must deliberately practice “Seamful Design.” They design moments of cognitive friction with escalation paths and checkpoints that require the AI to transparently communicate its confidence level and explain its reasoning to the human operator.

We need to retain some “seams” in the workflow to pause and check.

The FDD designs the UI of this handoff not to be a simple “Approve/Deny” button (which inevitably leads to dangerous automation bias, where tired humans blindly approve everything). Instead, it is designed as an evaluative “Proof of Work” interface. The AI must present its conclusion alongside cited sources, identified risks, and alternative options, forcing the human into a critical-thinking mindset before proceeding.

The strongest handoff also shows what would change the answer. A useful AI review screen should not merely say, “Here is my recommendation.” It should say, “Here is the evidence that drove my recommendation, here is the weakest part of my reasoning, here is the missing information that would reduce uncertainty, and here is the counterfactual evidence that would make me reverse course.” This converts human oversight from rubber-stamping into a true review.

The FDD and FDE Symbiosis: Two Halves of the AI Brain

I certainly believe an FDD will work hand-in-hand with an FDE, operating as an inseparable two-person vanguard within the client organization. The sheer complexity of the enterprise environment and the frontier nature of the technology demand it. There’s too much to know about implementing highly secure, performant, latency-optimized solutions with the next generation of AI models for a UX or service design specialist to be the best at bringing the designs to production life.

Consider the technical realities of deploying AI at a Fortune 500 company: navigating massive data privacy compliance frameworks, managing token limits and inference costs, fine-tuning open-source models for highly specific proprietary data, architecting complex vector databases, preventing prompt injection attacks, and ensuring high-availability enterprise infrastructure. These are deep, rigorous engineering challenges requiring world-class talent. An FDD cannot, and should not, be expected to manage them.

There’s no shame for an FDD to need an FDE, just as there should be no shame for an FDE to need an FDD. User research (and the associated systemic design solutions) and technical implementation are fundamentally separate, full-time skills that require different talents and experience. One defines what the system must achieve and how it will impact the human workforce; the other engineers the computational engine to make it a robust reality.

FDD and FDE roles require different skillsets and different mindsets. The two together are unbeatable and can explore anything.

However, AI tools absolutely allow people with each of these two skillsets to blur the lines and dabble in the other’s domain. A UX person can create his or her own functioning prototypes without waiting for a developer. Leveraging AI coding assistants, natural language programming, and advanced no-code environments, an FDD can spin up functional “Wizard of Oz” prototypes to test a prompt chain with users in real-time to validate an assumption instantly.

Engineers should also observe users and prototype solutions themselves. FDEs should actively participate in sitting in on contextual inquiries, bringing their intimate technical intuition directly to the front lines to suggest possibilities the designer might not know exist. This cross-pollination shrinks the gap between idea and execution, fostering deep mutual respect and a shared language.

But when it comes to enterprise-grade transformation, dabbling is not enough. The stakes are too high. The best, most paradigm-shifting research insights, the most radical design solutions, and the most robust, secure, and scalable implementations leveraging the absolute bleeding edge of next-generation AI models will require dedicated specialists working in symbiosis.

When DeployCo or any forward-thinking consultancy embeds a team, that team must be a unified pod. The FDD discovers the right thing to build, maps the organizational psychology, uncovers the true Job-to-be-Done, and architects the blueprint for the new AI-native workflow. The FDE takes this blueprint, selects the optimal combination of foundational models, vector databases, and security protocols, and engineers the system to survive the rigors of reality. Together, they act as the co-founders of the client’s new operational reality.

But even the perfect FDD/FDE pod will fail without an operating sponsor who has the authority to retire the old workflow. Enterprise AI adoption is not primarily a training problem. It is a permission problem. Employees will continue doing the old work in parallel until leadership explicitly removes obsolete steps, changes metrics, rewrites job descriptions, and protects teams from being punished for trusting the new system. Transformation begins when the organization is allowed to stop performing the rituals that AI has made unnecessary.

Even the best FDD/FDE duo will fail unless they secure an executive sponsor at the client who opens up the door to change. This again means that the persuasion skills to convince executives are one of the main job requirements for this job.

Do It Again

The FDD role will likely be long-lasting, because redesigning corporate workflows for AI is not a one-time deal. Whatever new AI workflows are designed now will have to be redone more aggressively in a few years, and then redesigned even more aggressively after that, as AI capabilities keep improving indefinitely as we build more compute.

Some AI influencers have claimed that the fact that OpenAI (and Anthropic, Microsoft, and other AI vendors) are building strong FDE practices means that they don’t really believe in superintelligence. I think that’s an erroneous conclusion. First, we don’t have ASI yet and don’t expect it to arrive until around 2030. Companies need to take advantage of AI now, and anybody who waits until 2030 to redesign their workflows for AI will likely be out of business long before 2030 arrives. Any redesign done now will have to be led by human FDD and FDE staff.

Keep improving. The work is never done, even after launching a redesigned workflow.

Second, even when we get superintelligence, that doesn’t mean that AI will do all the work and that humans will be relegated to the unemployment lines. There will be more work as the economy expands beyond belief, and we keep coming up with new things we want done. Human desires are infinite. There will also be a plethora of new companies founded to serve all these emerging human needs, and all these new companies will need AI workflows designed.

Even when we get artificial super-duper-intelligence (ASDI 😏), we will still need humans in FDD/FDE jobs, because humans will retain two roles that AI is ill-suited for: agency and persuasion/manipulation. Pushing a project forward requires human agency and impatience, and getting other humans to agree requires persuasion and manipulation. Having a physical body that can sit in a meeting room and look executives in the eye while saying “you need to do this,” will remain a human capability. Probably forever: Even though there are certainly initiatives in the works to build robots that are indistinguishable from live meatware humans, other people will still know who’s a human and who’s a robot and will be more likely to be persuaded by a human presence.

For the short-term future (maybe 10 years or so), it’s also likely that the field research I was recommending above should be conducted by human UX anthropologists and not by robots. After that, people may not care whether they are being observed by a living creature or a machine. In fact, I think it’s likely that many workers will prefer field research to be conducted by machines, since it’s less embarrassing to goof up in front of an AI than in front of a human, who will be seen as judgmental, not matter how many times we say, “we’re not testing you, we’re testing the system.”

Conclusion: Redesigning the Future of Work

OpenAI’s massive $4 billion investment in DeployCo and the integration of Forward Deployed Engineers into legacy consulting firms prove that the era of theoretical AI is over. The era of gritty, highly lucrative operational enterprise AI deployment has officially begun.

But as we embark on this transition, consulting giants and enterprise clients alike must avoid the temptation of using revolutionary technology to simply optimize the past. If we just throw brilliant engineers and advanced AI models at outdated, clunky legacy workflows, we will undoubtedly achieve isolated 40% efficiency gains. But those gains will be lost in the friction of broken, human-centric systems, and we will have squandered a once-in-a-generation technological leap.

To truly unlock the exponential economic and creative potential that artificial intelligence promises, organizations must be willing to engage in radical, blank-slate workflow redesign. We must look at our businesses not as a collection of human tasks to be automated, but as a series of business outcomes to be achieved in entirely new ways. We must discard the legacy systems built around human limitations and design new, agentic ecosystems.

This monumental task cannot be accomplished by engineers alone, nor by traditional designers pushing pixels in remote offices. It requires a new breed of practitioner who can bridge the gap between human psychology, complex service systems, and frontier technology. By establishing and championing the discipline of the Forward Deployed Designer, DeployCo and the broader tech industry can ensure that the systems of tomorrow are built on a foundation of deep human understanding and visionary design. The future belongs not just to those who can code the AI, but to those who can design the entirely new ecosystems in which the AI lives.

AI redesign shifts UX value from task completion to enterprise control loops, including authority, accountability, incentives, and operational drift. FDDs will play an important role in driving this transformative AI revolution across business and the global economy. Will you be one of them?

There’s a bright future for those who can redesign workflows for AI and break away from companies’ dependency on legacy human workflows.

About the Author

Jakob Nielsen, Ph.D., is a usability pioneer with 43 years experience in UX and the Founder of UX Tigers. He founded the discount usability movement for fast and cheap iterative design, including heuristic evaluation and the 10 usability heuristics. He formulated the eponymous Jakob’s Law of the Internet User Experience. Named “the king of usability” by Internet Magazine, “the guru of Web page usability” by The New York Times, and “the next best thing to a true time machine” by USA Today.

Previously, Dr. Nielsen was a Sun Microsystems Distinguished Engineer and a Member of Research Staff at Bell Communications Research, the branch of Bell Labs owned by the Regional Bell Operating Companies. He is the author of 8 books, including the best-selling Designing Web Usability: The Practice of Simplicity (published in 22 languages), the foundational Usability Engineering (30,387 citations in Google Scholar), and the pioneering Hypertext and Hypermedia (published two years before the Web launched).

Dr. Nielsen holds 79 United States patents, mainly on making the Internet easier to use. He received the Lifetime Achievement Award for Human–Computer Interaction Practice from ACM SIGCHI and was named a “Titan of Human Factors” by the Human Factors and Ergonomics Society.

· Subscribe to Jakob’s newsletter to get the full text of new articles emailed to you as soon as they are published.

· Follow Jakob on LinkedIn.

· Read: article about Jakob Nielsen’s career in UX

· Watch: Jakob Nielsen’s first 41 years in UX (8 min. video)