What is Product Design and how AI is redefining the designer's role

In 1992, Alan Cooper, a software designer, made an unusual decision: Stop writing code.

Instead, he chose to define what the software should do before anyone built the product.

At his previous job, his rule was simple: If a user would see it or touch it, he decided how it worked. Programmers wrote the code. The screens, flow, and words were his call.

He had noticed a pattern.

Features were cheap to add, so the list became the plan. Nobody knew when to stop. Complexity hid behind each new button until the whole thing became hard to use.

His solution was to decide how the product should behave and then build it to that plan.

Cooper argued that design should come before programming, because coders optimize for code, designers for use, and goals matter more than a long task list.

Coding once forced teams to think as they wrote it. Today AI writes code fast, which makes Cooper's rule more important. A clear plan matters more when wrong output arrives quickly.

Product design was never about making things look good. It was about deciding what a product does before building becomes expensive to change.

This article answers two questions that usually get mixed up: What product design is, and how AI changes your role.

What product design is: Messy bets, not a linear checklist

In 1973, planning theorists Horst Rittel and Melvin Webber coined the term wicked problems for work that has no single right answer and keeps shifting while you solve it.

That is what product design is all about.

It is stating the problem clearly, recording the choices, and keeping those choices visible while the product gets built.

AI didn't change that definition. It made it easier to skip the hard part and ship something that looks decided.

Let's pretend a user wants to cancel a subscription.

The job sounds simple: Leave the service, stop the charge.

In practice, product, legal, support, and growth rarely agree.

• Should cancel be one step or several?
• Should you offer pause instead?
• Should a bot cancel for the user, or only guide them?
• What if the user already paid for the year?

There is no perfect answer. There are better and worse bets. That is wicked work.

The product lives on a screen, but the hard part is behind the scenes: Permissions, states, errors, what happens when someone changes their mind. If you only learn a linear process, you'll keep making mistakes.

When you're ready to run gates on a full build, the product design process: a designer's roadmap to building great products will help you do this correctly.

The issue map and how to make the bet visible on a page

Horst Rittel used a notation called IBIS (Issue-Based Information System) for decisions like this.

I call the designer version an Issue Map and it has three parts:

1. Issue: The problem in one sentence.
2. Ideas: Possible directions.
3. Arguments: Short pros and cons tied to users, business, risk, and trust.

For canceling a subscription, the issue might be:

How hard should it be to cancel, and what do we owe the user before money stops?

Ideas and arguments:

• One-step cancel in settings: Pro: Respects user trust. Con: May clash with legal notice rules or retention goals.
• Cancel after one "are you sure" with clear end date: Pro: Clarity on billing. Con: Still feels like friction if copy is vague.
• Pause plan instead of cancel on the main path: Pro: Keeps revenue. Con: Users who want out may feel tricked.
• Support or agent cancels when user asks in chat: Pro: Helps stuck users. Con: Needs strict confirmation and audit trail.

You're not picking a winner in a vacuum.

You're making the decision legible so the team stops mistaking a polished screen for a settled bet.

After the map wins, design handoff done right: what developers actually need from you is how that choice ships. The map is where the choice earns its keep.

How AI is redefining the designer's role

AI is strong at designing screens, writing copy and code.

It's weak at choosing which bet your company should take when legal, growth, and support pull different ways.

Someone still has to run the Issue Map: Name the issue, list ideas, record why one path won.

That's why the role shifts in two ways today:

1. You write intent before pixels multiply. Cooper's rule now means a spec that humans and AI treat as source of truth. When agents build from docs, vague docs become vague products.

2. You keep wicked bets from going quiet. Cheap generation pushes teams to debate polish because polish is what's on the screen. Your leverage is the map in the room early: What are we deciding, what did we reject, what would prove us wrong?

Products also have two users to take into account: Humans, and AI agents that need clear steps and scope.

No matter who you are designing for, the point is the same.

You need to understand behavior so people and systems can follow it without guessing.

AI doesn't replace that work.

It pressures you to clarify what you are building before it becomes expensive.

If you want to build these habits on real projects, Zero to Pro is where I work with designers on Issue Maps, clear specs, and trade-offs you can defend in reviews.

Action checklist

• Pick one live wicked bet. Write the Issue in one sentence.
• List at least three Ideas.
• Add Arguments with user, business, and risk on each idea.
• Share the one-page map before the next design review.
• After a decision, add what you rejected and why.
• Before handoff, check: Could a new teammate read this and know what the product will do?

Final takeaway

Product design is making messy bets explicit before you start building your product, not after.

Cooper said define what users touch before code locks it in.

Rittel said most product bets are wicked.

The Issue Map is how you work that way on one page.

AI makes design cheap, so skipping the map is the new trap. Your job is clarity, not more screens.

Your edge should always be a clearer record of what you decided, what you refused, and what would prove you wrong.

Build that habit on real work through Zero to Pro.

When you're ready to ship a full product, join the next AI Design Sprint.

FAQs

What is Product Design?

Product Design is the work of defining what a product should do for users and the business, recording the main choices, and keeping those choices clear while the product is built and changed. In digital work, that includes flows, rules, and trade-offs, not only how screens look.

What is Digital Product Design?

It is Product Design for software people use on phones, web, or desktop. The product is the behavior and rules behind the interface: Accounts, billing, permissions, errors, and what happens when someone changes their mind. For how UX, UI, and business strategy collide on you day to day, read digital product design: where UX, UI, and business strategy collide.

How is Product Design different from UX Design?

UX Design usually goes deep on user needs, testing, and experience quality in a flow. Product design owns the wider bet: Scope, connections between flows, what the product refuses, and how success is defined. The difference is what you are accountable for in the room, not the label on the door.

When research and design blur on a team, UX Research vs UX Design: different roles, same goal clarifies who owns evidence vs solution.

How is Product Design different from UI Design?

UI Design focuses on visual and interaction craft on screen: Hierarchy, components, states, consistency. Product Design includes that craft but also the product rules and trade-offs behind it. A beautiful cancel button does not replace deciding how cancellation actually works.

How is Product Design different from Product Management?

Product Management prioritizes what the organization builds and when, across teams and metrics. Product Design makes the user-facing shape of those choices clear and usable: Flows, content, states, and documented decisions. You partner with PM. You do not replace them. PM picks what ships when; you make how it ships defensible for users.

Will AI replace Product Designers?

AI replaces parts of production, but it doesn't replace deciding which problem matters, which path the company should take, or what trust you are willing to spend. Designers who only compete on speed of screens feel pressure. Designers who keep Issue Maps and clear intent readable become more important as designing with AI gets cheaper.

Do Product Designers need to code?

No. You need enough literacy to talk with engineers and agents about constraints, data, and states. You need to write behavior clearly. Coding can help on small teams but is not the definition of the role.

What is a wicked problem?

A wicked problem is messy: No single right answer, the question changes as you learn, people disagree, and "finished" is a judgment. Most real product bets are wicked. Product Design is how you work on those.