The Designer's Place in the AI Product Lifecycle

Notes and reflections from Robert Redmond's Elvtr class on AI Product Design

There's a version of AI product development that goes like this: engineers define the problem, data scientists acquire and clean data, a model gets trained, it gets deployed, and design gets called in at the beginning to sketch some wireframes and at the end to polish the UI. Job done.

I've often wondered if there was something missing in the process. From taking Robert Redmon's class on AI Product Design, he explains that the model mentioned above is broken. And if you're a designer or product leader working on AI-powered products, accepting it will cost you — and your users — dearly.

The Classical View Doesn't Reflect Reality Anymore

The traditional AI development lifecycle is linear and engineer-driven: problem definition → data acquisition → model development → evaluation → deployment → ML Ops. It's a useful historical artifact, but it describes a world of "train once and deploy forever" that simply doesn't exist anymore.

Today's AI products — especially those built on large language models and multimodal systems — don't behave like a simple pipeline. They drift. They evolve post-launch. They surface unexpected behaviors at scale. They require constant shaping, tuning, and revisiting.

More importantly: they need design thinking woven into every single phase, not bolted on at the beginning and end.

The Modern Stack Is More Complicated Than You Think

Before we can talk about where design fits, it helps to understand what a modern AI product actually looks like under the hood.

Forget the classical "data in, model out" mental model. Today's systems are orchestrated. There's typically an orchestration layer — think of it like a conductor — that interprets user intent and decides how the system should react. Feeding into that orchestrator are prompts and instructions, retrieval mechanisms (RAG) that pull relevant knowledge into the context window, and tools and function calling that let the AI take action beyond simply generating text.

Then, before any response reaches the user, guardrails and safety layers evaluate the output — is it valid? Does it meet established standards? Is it safe from both a security and brand perspective?

The interface layer sits on top of all of this, shaping how everything gets surfaced to the user.

This is important context for designers, because every decision in that stack has a user experience implication. When a model retrieves the wrong information, users don't experience "a retrieval failure" — they experience a hallucinated answer or a bad recommendation. When guardrails trigger poorly, users feel blocked and punished rather than guided. The technical and the experiential are inseparable.

Design Belongs in Every Phase

The AI Product Design Lifecycle — the one worth actually working from — is circular, iterative, and design-inclusive at every step. Here's what that looks like in practice.

Problem Definition & Scope

The lifecycle begins here, and for AI it's especially critical, because AI can solve the wrong problem really convincingly. A model trained on misaligned goals will produce coherent-sounding outputs that deliver no actual value — or worse, harm.

Designers are essential at this stage: conducting user research, writing problem statements the whole team can align around, capturing personas and scenarios that define the domain, and setting success metrics before anyone trains a model. If design isn't at the table during problem definition, the organization is already losing ground.

Data Acquisition & Analysis

Designers aren't writing SQL queries or labeling datasets — that's what data scientists and engineers are for. But that doesn't mean data is "not our problem."

Our job here is to align data strategy with user needs. That means advocating for data quality and inclusivity, helping teams understand how data choices affect UX, and sometimes designing the interfaces that collect new data when gaps exist. Good AI experiences depend on good data. Getting involved early in this phase is how we influence outcomes we'll otherwise be stuck cleaning up later.

Feasibility Study

Before committing to a concept, the team needs to honestly ask: can this actually work with what we have? Does the complexity justify the value? Will users feel like they're doing too much work for too little payoff?

Designers are uniquely positioned to surface these risks early. Sometimes the right answer is "yes, but simpler." Sometimes it's "yes, but only if we stage the rollout to build up data over time." Catching these things at the feasibility stage is far cheaper than discovering them after model training.

Conceptualization & Prototyping

Here's where ideas start becoming tangible. Importantly, prototypes at this stage don't need to be functional — they don't need to simulate real AI behavior. They just need to show the journey, surface decision points, and help the team understand what's possible.

Think of this as exploratory: what is the scope of what we're building? What can the technology actually do? The goal isn't a polished UI. It's understanding.

Prompting — A Core Design Responsibility

This is where many designers opt out, and it's a mistake. Prompting is not a technical step that belongs solely to engineers. It is a UX content strategy step. It's the point at which you are literally shaping the rules by which the AI will operate — its tone, its constraints, its reliability, its behavior under edge cases. The structure of the model's input, the examples it sees, its safety instructions, the format of its outputs — all of these are design decisions.

If you hand this entirely to your engineering partners and walk away, you'll get outputs that are technically functional and experientially inadequate. Empathy and domain knowledge — the things designers bring — are what make the difference between a prompt that produces coherent outputs and one that actually serves users.

Think of prompting as interaction design for the invisible layer of your product. The work you do here determines whether the AI feels helpful and trustworthy, or chaotic and inconsistent.

AI Model Development

Model development doesn't always mean training a large model from scratch. It can mean fine-tuning an existing model, building a RAG pipeline, or configuring an off-the-shelf system. Regardless of the approach, designers are not here to make technical decisions — that's what architects and engineers are for.

What we are here to do is translate design intent into clear requirements, advocate for ethical and fair outcomes, ensure early prototypes test real model behavior (not idealized scenarios), and continually push for transparency in how the system operates.

Design

This is where we're center stage. All of that architectural and behavioral thinking now needs to be turned into a coherent, accessible, polished user experience. Visual identity of AI interactions, micro-interactions, communicating system state, surfacing reasoning outcomes, ensuring the AI feels native within the larger product — this is our domain.

But the bar is different here than in traditional product design. Good AI UX is not about flashy visuals. It's about clarity, predictability, and trust.

Designing for Agents

As AI systems become more agentic — capable of taking action, not just generating responses — the design challenges compound significantly.

Agents can plan multi-step tasks, call APIs, self-correct, monitor their own progress, and sometimes act before the user asks. That power introduces real risk. As designers, our job is to define the boundaries: when can the agent act autonomously versus when does it need confirmation? How does the user know what it's doing and why? How do we prevent over-automation? What are the fail-safes?

The key insight here is that designing for agents is a systems design discipline, not just a UI challenge. The experience is the behavior, not just the interface.

Testing & Validation

AI products fail differently than traditional software. They hallucinate. They reason incorrectly. They drift as new data is introduced. Biases surface when the population of users becomes more diverse than the training data anticipated.

This means our evaluation has to extend well beyond usability testing. We're evaluating correctness, hallucination rate, consistency, bias and fairness, error recoverability, and whether outputs are actually meeting user expectations — not just whether users can find the right button.

Methods include scenario evaluation, human-in-the-loop tests, red teaming, and multi-turn stress tests. The key principle: evaluation is part of design, not something that happens after.

Deployment

Deployment is not the finish line — it's the beginning of real-world learning.

Designers need to ensure fidelity between what was designed and what actually launches. We need to monitor AI behavior continuously, plan for immediate post-launch refinements (because AI products almost always need them), and define what "healthy behavior" looks like so the team knows what to watch for.

One practical note: be very deliberate about timing. Launching complex AI features right before a period when most of your team will be unavailable — say, mid-December — is one of the riskiest things you can do.

Guardrails, Safety, and Transparency

Safety isn't about blocking users. It's about keeping the experience predictable, ethical, and stable.

As designers, we shape how safety manifests in the user experience. Input filtering should feel supportive, not punitive. Output moderation should be framed calmly and clearly. Emergency stop patterns should protect users while maintaining trust. Constraint-based generation should be invisible unless it needs to surface. And users should have moments of transparency — clear signals about what the system is and isn't doing — without being overwhelmed.

Post-Launch: Iteration and Scaling

Post-launch is where the system evolves daily. Improvement cycles replace launch cycles. You're reviewing user feedback, identifying frustration patterns, monitoring behavioral drift, and watching for the slow erosion of trust that happens when recommendations become stale or homogenous.

And as the product scales — from a beta cohort of a few hundred users to tens of thousands — the dynamics change completely. Issues that were invisible at small scale become critical at large scale. Staying reactive and attentive through that growth is an ongoing design responsibility.

The Big Takeaway

The role of design in AI product development is not to make things look good. It is to ensure that AI features behave responsibly, predictably, and in ways that humans can understand and trust — from the moment a problem is first defined to the moment the product is retired.

Every early decision shapes multiple later stages. Your problem statement defines what data is needed. Your prototype shapes the model requirements. Your UX flows define what guardrails are necessary. This is systems design, and it requires disciplined participation across the full lifecycle.

If you're working in an organization where design only shows up at the beginning and end, that's not a reason to accept the status quo — it's a reason to build the relationships, develop the technical fluency, and make the case for being present everywhere in between.

Because we belong in every step of this process. And the products we build will be better for it.