All writing

Designing in the Age of AI-DLC: How I Lead Product Decisions from Intent to Launch

insights4 min read
Designing in the Age of AI-DLC: How I Lead Product Decisions from Intent to Launch

When building gets cheap, judgement becomes the product

AI can now draft user stories, generate screen variations and build a clickable prototype in an afternoon. For product designers, the hard part is no longer making the thing. It's deciding which thing is worth making, and getting a large organisation to agree fast enough that the speed isn't wasted.

Here is how I use AI-DLC as a Product & UX Strategist: how I take a project from a vague request to a shipped experience, and how I keep decisions moving in enterprise teams.

AI-DLC, through a designer's eyes

AI-DLC (AI-Driven Development Lifecycle) is a methodology AWS introduced in 2025. Its core idea: AI proposes, people decide. Work moves in short cycles called bolts (hours or days, not two-week sprints), and the team reviews AI's proposals together in live sessions.

For a designer, its three phases map to familiar work. Inception is product definition, Construction is designing and building together, and Operations is learning from real use. What the framework doesn't cover is experience quality or who decides what. That's where my process comes in.

My process

1. Frame the problem

Most requests arrive as solutions, like "Redesign onboarding." Before anything gets generated, I agree four things with stakeholders: who it's for, what problem they face, what success looks like (one or two metrics), and what can't change (brand, regulation, accessibility). AI helps me synthesise interviews, tickets and analytics quickly, but I check its themes against the raw evidence. The result is a one-page product intent brief that every session starts from.

2. Define the experience (Inception)

In Mob Elaboration, AI drafts stories, journeys and the states teams forget: empty, error, loading, first use. My job is to own the experience model: information architecture, core flows and product language. AI lists possibilities; we decide which ones matter for this user.

3. Design and validate in bolts (Construction)

Each bolt has one experience goal and ends with something a real person can click. Because AI makes exploring directions cheap, I can test real prototypes with users in the same week. Two rules keep quality high: the design system is the contract (tokens and components the AI can read), and every bolt ends at an Approve / Edit / Reject gate.

4. Launch and learn (Operations)

We release gradually, track the success metric from step 1, and combine behavioural data with user feedback. What we learn feeds the next cycle.

Who does what at each stage

  • Frame: AI helps synthesise research. The designer decides the problem, users and success metric.
  • Define: AI drafts stories and edge cases. The designer decides the experience model and scope.
  • Design & validate: AI generates variations and prototypes. The designer decides which direction ships.
  • Launch & learn: AI summarises behaviour and feedback. The designer decides what to improve next.

How decisions work in a large enterprise

Enterprise design rarely fails because of bad ideas. It fails because decisions stall or get reopened. AI can make this worse: fifty options means fifty things to argue about. Here's how I keep decisions clear.

Sort decisions by how hard they are to undo

  • Reversible (microcopy, layout, visual details): the designer and team decide, in the session.
  • Costly to reverse (navigation, IA, core flows): product owner, design lead and tech lead decide together.
  • Hard to reverse (consent, personal data, pricing, brand, accessibility compliance): the business owner decides, with legal, compliance and brand.

Most day-to-day design decisions then need no meeting at all.

Match the evidence to the decision

A reversible choice can rest on a written-down assumption. A hard-to-reverse one needs usability testing or a live experiment. AI makes prototypes cheap, so testing is realistic even on tight timelines.

Show, don't debate

When stakeholders disagree, I put two working prototypes on screen. Abstract debates usually end within minutes once people can click through both options.

Clear owners, early vetoes

Every piece of work has one named owner who can say yes. Brand, legal and compliance join early for anything hard to reverse, so their "no" comes before the design is finished, not after.

Write it down

Every significant decision gets a short log entry: what we decided, why, the evidence, who approved it, and what would make us revisit it. It stops repeat debates, and the AI reads it too, so it stops suggesting directions we've already ruled out.

The short version

AI-DLC doesn't make designers less important. It moves our value from producing screens to framing problems and leading decisions. My approach comes down to four habits:

  1. Frame the problem with evidence before anything gets generated.
  2. Let AI explore options; let named people decide.
  3. Match evidence and approval effort to how hard a decision is to undo.
  4. Measure the outcome you promised users, not the screens you produced.

If your team is bringing AI into its product process and decisions keep stalling, I'm happy to talk it through. Get in touch.