The happy path is polite.

The user remembers their password, has the correct permissions, selects an available date, enters valid data, does not close the tab, does not lose their internet connection, and understands exactly what every status means.

The system behaves impeccably too.

Data arrives on time, integrations respond correctly, two processes do not attempt to modify the same object, and the reserved resource does not disappear one second before the form is submitted.

Designing in this reality is exceptionally pleasant.

Unfortunately, users, systems, and reality have not signed an agreement requiring them to follow the happy path.

A user may:

• click twice,
• return to a previous step,
• lose permission during the process,
• open the same form in two tabs,
• begin a task on their phone and continue on a computer,
• enter data in a format nobody anticipated,
• misunderstand the difference between “available” and “ready”,
• interpret a warning as general information,
• close a modal that cannot safely be dismissed,
• do something completely logical that the team never considered.

The system may:

• receive outdated data,
• respond with a delay,
• complete only part of an operation,
• reject a request on the server side,
• lose its connection to an external service,
• save one stage but not the next,
• display the previous status after refresh,
• receive two conflicting instructions almost simultaneously.

Edge cases are not an optional addition designed after the “real” flow is finished.

They are situations in which the assumptions holding the flow together stop being true.

ChatGPT can help you notice them.

Not because it understands your product better than you, a developer, or QA.

Because it can quickly:

• change perspective,
• break a process into conditions,
• generate scenarios,
• compare alternatives,
• identify contradictions,
• raise questions the team has not yet asked.

In The AI Workflow for Product Designers: Lead, Expand, Refine, Elevate, I described a system in which AI expands the range of possibilities while the designer retains direction, evaluation, and responsibility.

In this article, we will apply that model to two tasks:

1. finding edge cases,
2. challenging design decisions before implementation.

The most important principle is:

ChatGPT can help identify questions, risks, and possible scenarios. It cannot confirm that they occur in the product or decide how they should be handled.

An Edge Case Does Not Always Mean a Rare Case

The term “edge case” is often associated with something unusual:

• a surname containing 150 characters,
• a user born on 29 February,
• a file with an unusual extension,
• an exceptionally long address,
• a device running a very old browser version.

These cases exist.

However, many problems described as edge cases are neither exotic nor especially rare.

For example:

• the user does not have the required permissions,
• a payment is declined,
• a date becomes unavailable,
• a file upload is interrupted,
• an invited person does not have an account,
• a form expires,
• a session ends while the user is completing a task,
• someone reverses an action,
• data requires additional verification.

These are normal parts of how products operate.

They sit “at the edge” of the main scenario only because flow diagrams usually run through the middle of the page.

What Is an Edge Case?

A practical definition might be:

An edge case is a situation in which a condition, data value, timing, user behaviour, or system dependency differs from the assumptions of the main flow and requires a different product response.

An edge case may involve:

• data,
• object state,
• sequence of actions,
• time,
• permissions,
• roles,
• integrations,
• devices,
• availability,
• user behaviour,
• process recovery,
• communication,
• business rules.

Not every situation requires a separate screen.

Sometimes all you need is:

• the correct message,
• a blocked action,
• preserved data,
• a retry option,
• redirection to another person,
• clear status information.

First, however, you need to notice that the situation may occur.

Why Teams Miss Edge Cases

It is not always because they work carelessly.

More often, it is because:

The Happy Path Is Easier to Communicate

A clean diagram containing six steps fits on a slide.

A diagram that includes an expired session, lost permissions, booking conflicts, and partially completed operations starts to resemble the public-transport map of a city built without an urban plan.

The Project Begins With Screens

The team sees:

• a form,
• a calendar,
• a table,
• a modal.

It does not yet see:

• the object lifecycle,
• entry conditions,
• dependencies,
• status changes,
• conflicts between processes.

“That Is a Technical Case”

Some scenarios are passed to developers even though they directly affect the user experience.

The fact that an error originates in the system does not mean the product response is not a UX decision.

The Deadline Is Approaching

The primary path is designed first.

Edge cases are postponed.

“Later” usually arrives during QA or after launch, when the edge case has just submitted a support ticket.

The Team Knows the Product Too Well

People working on the system know:

• which permission is required,
• how the statuses differ,
• where to find missing information,
• what to do after an error.

The user does not operate the product with a team member attached to it, explaining its internal logic.

What ChatGPT Can Do Well

ChatGPT is particularly useful when you need to:

• expand an existing flow,
• identify missing conditions,
• check transitions between statuses,
• generate alternative scenarios,
• analyse different roles,
• challenge an assumption,
• compare the consequences of a decision,
• prepare questions for a developer, QA specialist, or Product Manager,
• organise identified cases,
• create a pre-handoff checklist.

For example, it may ask:

What happens if the user’s permission expires after the reservation is made but before the equipment is collected?

That is a good question.

AI does not know the answer.

The answer may depend on:

• policy,
• risk,
• system capabilities,
• equipment type,
• data-synchronisation timing,
• a business decision,
• legal responsibility.

ChatGPT can identify the point at which a rule is missing.

It should not create the rule simply because the document looks more complete without a blank space.

What ChatGPT Should Not Do

It should not independently:

• determine the likelihood of a case occurring,
• add non-existent features,
• define backend behaviour,
• decide whether a risk is acceptable,
• create business rules,
• establish permissions,
• assign priorities without context,
• replace consultation with QA, development, or security,
• turn generated scenarios into requirements.

An AI-generated edge-case list is material for evaluation.

It is not automatically:

• a backlog,
• an MVP scope,
• a bug list,
• acceptance criteria,
• the truth about the product.

Describe the Product Model Before Asking AI

A weak prompt:

Find edge cases for this booking flow.

The model does not know:

• what is being booked,
• who is making the reservation,
• which statuses exist,
• which roles participate in the process,
• when a reservation is confirmed,
• which data is available,
• what the system cannot do.

The response will be generic.

You will probably get:

• no internet connection,
• an invalid date,
• a scheduling conflict,
• incorrect data,
• a payment error, even if the product has no payments, because payments always look professional in a list of potential problems.

Before the analysis, prepare the following.

Objects

What exists in the system?

For example:

• User,
• Equipment,
• Reservation,
• Training,
• Time Slot.

Roles

Who performs actions?

• Student,
• Staff Member,
• Administrator.

Statuses

How does the object state change?

• Draft,
• Pending Manual Review,
• Confirmed,
• Cancelled,
• Expired,
• Equipment Ready,
• Collected,
• Returned.

Rules

What must be true?

• the user belongs to the correct department,
• the required training is active,
• the device is available,
• the user has no overdue return,
• the number of active reservations does not exceed the limit.

Dependencies

What does the flow rely on?

• the permissions system,
• the availability database,
• training records,
• notifications,
• a manual staff decision.

Constraints

What does the system not do?

• it does not update training data in real time,
• it does not allow users to unlock their own accounts,
• it does not support complete inventory management.

Only then can you expect an analysis that relates to the real product.

Apply Lead, Expand, Refine, Elevate

Lead — Define the Flow, Objective, and Boundaries

Provide:

• the primary scenario,
• objects,
• roles,
• statuses,
• confirmed rules,
• the scope of the analysis,
• what AI must not assume.

Example:

I am analysing a university equipment-booking flow. The student selects a device, the system checks eligibility, the student selects a date, and submits the reservation. Standard cases are confirmed automatically, while exceptions are sent for manual review.

I want to identify scenarios that may interrupt the process, change the status, or create inconsistency between the user-facing view and the system state.

Do not add new roles, integrations, or features. Do not treat possible scenarios as confirmed requirements. Mark missing rules as open questions.

This is a strong starting point.

Expand — Generate Possible Disruptions

At this stage, AI can analyse:

• entry conditions,
• the sequence of actions,
• status changes,
• conflicts,
• interrupted processes,
• dependency failures,
• different roles,
• possible misunderstandings.

Example:

Analyse the flow for:

• missing data,
• permission changes,
• availability changes,
• simultaneous actions,
• delayed synchronisation,
• repeated actions,
• leaving and resuming the process,
• partial operation success,
• unclear statuses.

For every case, provide:

• the trigger,
• the possible consequence,
• the rule that is currently missing,
• the information the user needs,
• the person or role required to confirm the behaviour.

You now have a map of questions.

Not a solution.

Refine — Remove Noise and Establish Priorities

AI may generate forty cases.

Not all of them will be:

• possible,
• important,
• relevant to the scope,
• in need of a separate solution,
• worth addressing in the current iteration.

During the Refine stage, remove:

• scenarios that assume non-existent features,
• duplicates,
• cases related to a different product,
• situations already handled by the system,
• overly general problems,
• elements that do not affect the decision.

Then divide the remaining cases, for example, into:

• blocking task completion,
• causing data loss,
• causing an incorrect status,
• misleading the user,
• recoverable,
• requiring manual handling,
• requiring further confirmation.

Elevate — Decide What the Product Should Do

Only now does the actual design decision appear.

For every important case, define:

• how the system should respond,
• what the user should see,
• whether the user can continue,
• whether their data is preserved,
• how they can recover the process,
• who makes the decision,
• which status should be saved,
• what requires implementation,
• what remains outside the scope.

Example:

If the selected time slot becomes unavailable before the form is submitted, the system checks the slot again and does not create the reservation. The user remains in the process, retains the selected device and all other entered data, receives information about the conflict, and can select an alternative date.

This is no longer a generated possibility.

It is a product decision the team can:

• discuss,
• document,
• implement,
• test.

Categories of Edge Cases

Instead of asking AI for one enormous list, analyse the flow through specific categories.

1. Input Data

Check for:

• missing data,
• invalid format,
• values that are too short or too long,
• special characters,
• duplicates,
• conflicting data,
• boundary values,
• data that changes after the process begins.

Example prompt:

Analyse the form for empty, boundary, invalid, duplicated, and conflicting values. Separate validation possible in the interface from cases requiring a system response. Do not invent limits I have not provided.

Important: AI should not decide that a name can contain no more than 50 characters simply because fifty sounds reasonable.

2. Roles and Permissions

Check for:

• a user without access,
• partial access,
• a role change,
• lost permissions,
• conflicting permissions,
• an action started before the role changed,
• an object that is visible but cannot be edited,
• an action performed on behalf of another person.

Prompt:

Analyse the flow for users with full, partial, expired, and changed permissions. Identify moments when permissions should be checked again. Do not define access rules—mark missing rules as questions.

3. Statuses and the Object Lifecycle

Check for:

• invalid transitions,
• a skipped status,
• reversal,
• a final status,
• a status conflicting with another object,
• an outdated state,
• an object stuck in an intermediate status,
• a repeated action.

Prompt:

Map all described status transitions. Identify:

• transitions without triggers,
• statuses without an exit,
• actions available in an inappropriate state,
• conflicts between the user-facing status and the system status.

Do not add new statuses unless you mark them as proposals.

4. Time

Check for:

• expiration,
• delays,
• time-zone changes,
• differences between device and server time,
• actions completed too early or too late,
• data valid for only a limited period,
• dates changing during the process.

Prompt:

Analyse the flow for time-dependent behaviour. Pay attention to session, data, permission, and reservation expiration, availability changes, and actions performed close to a time boundary.

5. Simultaneous Actions

This is a common source of problems in booking systems, shared documents, administrative panels, and team tools.

Check for:

• two people selecting the same resource,
• two edits to the same object,
• an action completed in two tabs,
• a double click,
• a repeated request,
• a delayed response arriving after a newer change.

Prompt:

Identify scenarios in which two people, two devices, or two tabs may change the same object simultaneously. For each one, describe the possible inconsistency and the question that must be discussed with engineering.

6. Process Interruption and Recovery

Check for:

• closing the tab,
• refreshing,
• navigating elsewhere in the product,
• session expiration,
• connection loss,
• device failure,
• returning several hours later,
• a partially completed form.

Prompt:

Analyse every step for possible process interruption. Identify which data may be lost, what should be preserved, and where users need a clear way to resume, retry, or safely exit.

7. External Dependencies

Check for:

• no response,
• timeout,
• a partial response,
• conflicting data,
• delayed synchronisation,
• a service operating in read-only mode,
• a change made outside the product.

Prompt:

Identify steps that depend on external data or services. For each one, prepare scenarios for no response, a delayed response, outdated data, conflicting data, and partial operation success. Do not propose a specific technical architecture.

8. Destructive Operations

Check for:

• deletion,
• cancellation,
• reversal,
• overwriting,
• data loss,
• irreversible actions,
• deleting an object that is used elsewhere.

Prompt:

Analyse the reservation-cancellation operation for reversible and irreversible consequences. Identify what information the user should see before the action, what happens afterward, and which dependencies may block the operation.

Not every destructive action requires a modal.

Not every safe action can do without one.

The decision depends on:

• consequences,
• reversibility,
• likelihood of error,
• frequency of the action,
• cost of interrupting the flow.

9. Messages and Status Interpretation

The problem may not only be what the system does.

How the user understands the situation is equally important.

Check for:

• similar status names,
• messages without a next action,
• warnings that look like errors,
• errors that look like success,
• confirmation that does not mean the process is complete,
• messages requiring technical knowledge.

Prompt:

Analyse the described statuses and messages for possible misinterpretation. For each one, identify:

• what the system intends to communicate,
• what the user may understand,
• the consequence of the misunderstanding,
• which information or next action should be clarified.

10. Accessibility

The user should not be treated as the edge case.

A person using a keyboard, screen reader, or high zoom is not a product edge case.

However, accessibility analysis may reveal scenarios omitted from the primary flow:

• focus returning to the wrong place,
• errors communicated only through colour,
• a modal that cannot be closed with the keyboard,
• a dynamic status change without an announcement,
• a timeout that cannot be extended,
• drag and drop without an alternative.

Prompt:

Analyse the flow for keyboard use, screen readers, zoom, and limited reaction time. Do not treat accessibility as an additional feature. Identify moments when users may lose context, focus, information, or the ability to complete the task.

AI can prepare a checklist.

It does not replace an audit or testing with people who use assistive technologies.

How to Use ChatGPT to Challenge Design Decisions

Finding edge cases is only one use.

The second is checking whether a decision that appears logical remains logical after changing perspective.

Suppose the decision is:

We will show borrowing requirements before the calendar.

That may be a good direction.

However, it is worth asking:

• Does every user need the same information?
• Are the requirements always current?
• What happens if the user loses permission later?
• Does blocking the calendar help, or does it prevent planning?
• Can the user view future dates before completing the training?
• Does earlier information solve the problem, or only move the message?
• Is there a situation in which the user should be allowed to continue despite lacking permission?

Challenging a decision does not mean automatically rejecting it.

It means examining the assumptions on which it depends.

Write the Decision as a Hypothesis

Instead of:

The requirements should be shown before the calendar.

Write:

Showing the requirements before the calendar will help users assess earlier whether they can complete the reservation and reduce the number of processes that end in a restriction.

Now you can see:

• the change,
• the expected mechanism,
• the predicted outcome.

It can be challenged.

Prompt for Analysing a Decision

Analyse the design decision below as a hypothesis.

Decision: [paste decision].
Expected outcome: [paste outcome].
Confirmed evidence: [paste material].
Constraints: [paste constraints].

Identify:

• the assumptions the decision depends on,
• situations in which it may not work,
• possible unintended consequences,
• groups or roles for which the effect may differ,
• information needed to evaluate it,
• decisions that cannot yet be made.

This is much more useful than:

Is this a good UX decision?

AI will happily respond that the decision is a good starting point, provided it is tested with users.

In other words, it will say everything and nothing at the same time.

Ask for Alternatives

Do not ask only whether the current solution works.

Ask which other models are possible.

Example:

Propose four different ways of communicating the requirements:

• before equipment selection,
• in the equipment-details view,
• before the calendar,
• only before confirmation.

For each option, compare:

• when the user receives the information,
• the risk of starting a process that cannot be completed,
• cognitive load,
• the ability to plan,
• impact on flow length.

Do not recommend a final option.

AI does not need to find the solution the team will use.

It is enough if it helps you stop treating the first concept as the only possible one.

Use the Perspectives of Different Roles

A decision may work well for one user while creating a cost for another person.

Prompt:

Analyse the decision from the perspective of:

• a new user,
• a returning user,
• a staff member handling exceptions,
• a developer,
• QA,
• a security specialist.

For every perspective, identify the benefit, cost, risk, and question requiring confirmation.

This is not a substitute for speaking to these people.

It is preparation for a better conversation.

Ask About Unintended Consequences

Every decision can solve one problem while creating another.

Example:

Identify possible unintended consequences of automatically confirming standard reservations. Include user behaviour, operational work, data, statuses, exceptions, and future maintenance. Separate context-supported risks from speculative ones.

AI may identify:

• users assuming the equipment is ready for collection,
• insufficient time to detect incorrect data,
• an increase in automatically created but uncollected reservations,
• greater difficulty explaining exceptions,
• dependence on up-to-date permission data.

Each risk needs to be checked.

Not every risk requires changing the decision.

Use a Pre-Mortem

A pre-mortem assumes that the solution has been launched and failed.

You ask what may have happened.

Prompt:

Assume that six weeks after launching conditional approval, the solution was considered problematic. Prepare possible causes related to:

• misunderstanding statuses,
• incorrect data,
• operational work,
• unforeseen exceptions,
• user behaviour,
• rule maintenance.

For every cause, identify an early warning sign and a way to test it in advance.

A pre-mortem does not predict the future.

It helps the team notice what it should monitor.

Ask for the Strongest Counterargument

This is not about random criticism.

Ask for the strongest possible argument against the decision.

Prepare the strongest possible argument against showing the requirements before the calendar. The argument must be based on the described context, not general UX principles. Then identify the evidence required to confirm or reject it.

This helps determine whether the decision has an answer to a credible alternative.

Not a weak version of criticism that is easy to defeat.

Ask for Conditions That Would Invalidate the Decision

A good decision does not need to be correct unconditionally.

It may work only when:

• the data is current,
• the status is understood,
• a particular rule remains stable,
• the user receives an alternative,
• the system supports process recovery.

Prompt:

Identify the conditions that must be met for the decision to remain safe and useful. Then describe situations in which it should be reassessed.

This prevents the decision from becoming a dogma.

It becomes a deliberate choice based on specific conditions.

Decision Challenge Matrix

You can describe every important decision in a simple table:

Element	Question
Decision	What are we choosing?
Problem	Which problem are we solving?
Assumption	What must be true?
Evidence	What supports it?
Alternatives	What else did we consider?
Trade-off	What do we gain and lose?
Risk	What could go wrong?
Edge cases	When does the decision stop working?
Validation	How can we test it?
Revisit condition	When should we return to the decision?

Prompt:

Complete a working decision challenge matrix based on the material. Do not fill gaps with assumptions. Mark every field without sufficient information as Unknown or Needs confirmation.

This table can later become part of a decision log.

In UX Documentation With AI: User Flows, Decision Logs, and Handoffs, I explained how to turn the analysis into documentation the team can use.

How to Evaluate Generated Edge Cases

A list of cases alone provides little value.

You need to determine which ones matter.

You can use five simple criteria.

1. Likelihood

How realistic is the scenario in this particular product?

Not:

Could this theoretically happen?

But:

Are there conditions under which this could genuinely happen?

2. Impact

What happens?

• temporary confusion,
• inability to complete the task,
• data loss,
• an incorrect decision,
• a permission violation,
• financial cost,
• a security risk.

3. Detectability

Will the system, team, or user notice the problem?

The most dangerous cases are often those in which the operation appears to have completed correctly while the data remains inconsistent.

4. Recoverability

Can the user:

• retry the action,
• go back,
• correct the data,
• contact support,
• reverse the change?

5. Handling Cost

Does the case:

• require an automatic response,
• allow manual handling,
• need to be blocked,
• remain outside the scope of the current version?

Not every edge case must be handled in the same way.

However, every important case should have a deliberate decision.

A Simple Prioritisation Prompt

Evaluate the confirmed scenarios according to:

• likelihood,
• user impact,
• risk of data loss or inconsistency,
• recoverability,
• need for handling before launch.

Do not assign a rating without explaining it. If data is missing, mark the criterion as Unknown. Do not set the final priority—prepare material for a team decision.

AI can organise the arguments.

The team still needs to determine:

• risk tolerance,
• scope,
• cost,
• responsibility.

Example of a Complete Edge-Case Analysis

Scenario

The selected time slot becomes unavailable before the reservation is submitted.

Trigger

Another person reserves the same slot while the first user is still completing the form.

Possible Consequences

• two reservations for the same resource,
• the form being rejected without explanation,
• data loss,
• an incorrect confirmation.

Questions

• When does the system lock the slot?
• Is the slot reserved temporarily?
• How long does the lock remain active?
• What happens when it expires?
• Is the form data preserved?
• Can the system suggest another time slot?
• Does the user see availability updates in real time?

UX Decision

When the form is submitted, the system checks availability again. If the slot has already been taken:

• the reservation is not created,
• all other data remains saved,
• the user receives a clear explanation,
• the calendar displays current availability,
• the user can select another date.

Documentation

• the flow includes a repeated slot check,
• the handoff describes loading, conflict, and recovery states,
• acceptance criteria include simultaneous reservation attempts,
• the decision log explains why the form data is preserved.

A generated question has now become a real part of the design process.

Edge Cases Should Return to the Flow

Do not create a separate list that nobody opens again.

Every confirmed case should be connected to:

• a specific step,
• a status,
• a screen,
• a rule,
• a ticket,
• an acceptance criterion,
• a QA scenario,
• a decision.

You can label them on the flow:

• H — happy path,
• A — alternative path,
• F — failure path,
• OQ — open question,
• BR — business rule,
• DEP — dependency.

This shows not only that the case exists.

It also shows where it affects the product.

Prompt for Mapping Cases to the Flow

Connect the confirmed edge cases to specific flow steps. For each one, identify:

• the step,
• trigger,
• path type,
• expected system behaviour,
• user-facing information,
• recovery method,
• required document or ticket.

Do not add new cases during the mapping.

Use AI Before the Handoff

Before handing over the project, ask for analysis from three perspectives.

Developer

Which rules are ambiguous? Which system responses have no trigger? Where are data or dependencies missing?

QA

Which scenarios require testing? Where is the expected result missing? Which statuses may conflict?

User

At which moments may the user not understand what happened, why the action was blocked, or what to do next?

Complete prompt:

Review the documentation as:

1. a developer beginning implementation,
2. a QA specialist preparing test scenarios,
3. a user trying to complete the task.

For each perspective, prepare a separate list of:

• ambiguities,
• missing rules,
• potential conflicts,
• blocking questions,
• questions that can be resolved later.

Do not fill the gaps independently.

This does not replace team review.

It can ensure that the review begins with better questions.

The Most Common Mistakes

1. Generating an Enormous List Without Context

One hundred edge cases look impressive.

That does not mean the analysis is useful.

The less context you provide, the more the list resembles a collection of problems that could occur in any digital product.

2. Turning Possibilities Into Requirements

AI lists:

The user tries to complete the booking while offline.

That does not mean the product must support a complete offline mode.

First determine:

• whether the scenario is possible,
• how often it occurs,
• what consequences it has,
• whether a message and retry option are sufficient,
• whether it belongs in the scope.

3. Adding Features Instead of Solving the Problem

For every case, AI may propose:

• a new setting,
• a notification,
• a dashboard,
• automation,
• history,
• a help centre.

Sometimes the answer is simpler:

• earlier validation,
• a clearer status,
• preserved data,
• a blocked action,
• a retry option.

4. Treating Every Case Equally

A typo in an optional field and unauthorised data disclosure do not have the same significance.

Priority should reflect consequences, not merely the fact that the scenario appeared on a list.

5. Using AI Instead of the Team

AI does not know:

• how the infrastructure works,
• which legal requirements apply,
• how much implementation costs,
• how support operates,
• which risks the business accepts,
• what is being monitored,
• which data is current.

It can help prepare questions for the right people.

It is not the right person.

6. Failing to Return to the User

Some scenarios require a technical decision.

Others directly affect whether the process is understood.

When you do not know:

• how the user interprets the status,
• whether they notice the restriction,
• whether they understand the recovery option,
• whether they trust the updated data,

you need testing or research.

In How to Use AI in UX Research Without Replacing Research, I explained how to use AI for preparing and analysing research without turning generated responses into evidence.

7. Challenging Everything for the Sake of It

Not every decision requires twenty alternatives and a philosophical debate.

The purpose of a challenge is to:

• find an important assumption,
• reveal a risk,
• examine the consequences,
• improve the quality of the decision.

Not to create a situation in which the team spends three weeks analysing whether the Save button violates the concept of free will.

8. Failing to Make a Final Decision

The analysis may produce:

• options,
• risks,
• questions,
• exceptions.

At some point, the team must decide:

• what it will do now,
• what it will postpone,
• what it will accept,
• what needs further validation,
• what remains outside the scope.

A list of questions is not a product.

9. Failing to Document the Decision

When an edge case is discussed only during a meeting, there is a strong chance it will reappear as a new problem.

Record:

• the decision,
• rationale,
• responsibility,
• date,
• condition for reassessment.

10. Sharing Confidential Context Without Control

Edge-case analysis may require:

• internal rules,
• security information,
• customer data,
• infrastructure descriptions,
• confidential processes.

Before using AI, check:

• organisational policy,
• available internal tools,
• anonymisation options,
• NDA scope,
• the type of data being shared.

Not every security gap needs to be discussed with a public chatbot.

A Complete Prompt for Edge-Case Analysis

Help me analyse edge cases for the flow [flow name].

User objective:
[describe the task]

Primary flow:
[paste the steps]

Objects:
[paste the objects]

Roles:
[paste the roles]

Statuses:
[paste the statuses]

Confirmed rules:
[paste the rules]

Dependencies:
[paste the systems, data, and services]

Constraints:
[paste the constraints]

Analysis rules:

• do not add new features,
• do not create business rules,
• do not assume backend behaviour,
• do not treat possibilities as confirmed cases,
• mark all missing information as Open question,
• separate cases supported by the material from speculative ones,
• preserve the product terminology.

Analyse:

1. input data,
2. roles and permissions,
3. statuses and transitions,
4. time and expiration,
5. simultaneous actions,
6. interruption and recovery,
7. external dependencies,
8. partial operation success,
9. messaging and possible misinterpretation,
10. accessibility.

For every case, provide:

• scenario,
• trigger,
• flow step,
• possible consequence,
• information required by the user,
• possible recovery path,
• missing rule,
• person required to confirm it,
• status: Confirmed / Plausible / Out of scope / Unknown.

At the end:

• combine duplicates,
• identify contradictions,
• separate blocking questions from those that can be resolved later,
• do not assign the final priority.

A Complete Prompt for Challenging a Decision

Help me challenge a design decision without automatically rejecting it.

Decision:
[paste the decision]

Problem:
[paste the problem]

Expected outcome:
[paste the outcome]

Evidence:
[paste the evidence]

Constraints:
[paste the constraints]

Alternatives considered:
[paste the alternatives]

Analyse:

• assumptions required for the decision to work,
• the strongest argument against it,
• unintended consequences,
• roles or segments for which the outcome may differ,
• edge cases in which the decision stops working,
• trade-offs,
• missing evidence,
• possible validation methods,
• conditions that should trigger reassessment.

Do not recommend changing the decision merely to present an alternative. Do not increase the confidence level beyond the available evidence.

Checklist Before Completing the Analysis

Context

• Did AI receive the real product model?
• Are objects, roles, and statuses clearly described?
• Has the scope been defined?

Reliability

• Are possibilities separated from confirmed cases?
• Are missing rules marked?
• Has AI added any system behaviour?

Priority

• Has the consequence been evaluated?
• Is it clear what blocks the task?
• Has recoverability been considered?
• Must the case be handled now?

Decision

• Has the expected behaviour been defined?
• Has the rationale been recorded?
• Is the accepted risk visible?
• Is it clear who confirmed the decision?

Documentation

• Has the case been connected to the flow?
• Is it included in the handoff?
• Has QA received the scenario?
• Are the acceptance criteria consistent?

Responsibility

• Have the appropriate people reviewed the rules?
• Does the decision still belong to the team?
• Has AI become the only source of the analysis?

A Good Edge Case Reveals an Assumption

The greatest value of edge cases is not that the product begins supporting every possible situation in the universe.

Their value is that they reveal what the primary flow depends on.

The question:

What happens if the user loses permission?

reveals that the flow assumes permissions remain stable.

The question:

What happens if the time slot is taken one second earlier?

reveals that the flow assumes availability remains stable.

The question:

What happens if the operation is completed only partially?

reveals that the flow assumes complete success.

The question:

What happens if the user interprets “Confirmed” as “Ready for Collection”?

reveals that the flow assumes a shared understanding of the status.

An edge case is therefore not only a problem to solve.

It is a tool for evaluating the quality of the product model.

AI Does Not Make Decisions. It Helps Find the Places Where a Decision Is Missing.

ChatGPT can generate a list of things that may go wrong very quickly.

That alone is not particularly valuable.

The value appears when you use the list to:

• discover missing rules,
• verify statuses,
• understand dependencies,
• challenge assumptions,
• prepare conversations with the team,
• document decisions,
• design recovery paths.

The most important process looks like this:

flow → assumptions → possible disruptions → evaluation → decision → documentation → validation

AI can significantly accelerate the middle section.

It should not remove the beginning or the end.

Without real context, it will generate a generic list.

Without human evaluation, it will turn possibilities into requirements.

Without a decision, it will leave the team with a collection of problems.

Without validation, nobody knows whether the solution is understandable.

AI helps broaden the field of view. The designer decides what deserves a closer look.

---

Do You Want to Use AI for Decision Analysis, Edge Cases, and Documentation?

The Designer’s AI Playbook includes the Lead → Expand → Refine → Elevate model, a library of 50 UX prompts, and practical workflows supporting:

• user-flow analysis,
• edge-case discovery,
• challenging assumptions,
• comparing alternatives,
• documenting design decisions,
• creating decision logs,
• preparing handoffs,
• communicating with developers, QA, and stakeholders,
• building portfolio case studies.

The book shows how to use AI to expand analysis and organise design work without surrendering decisions, authorship, or responsibility for the product.

Explore The Designer’s AI Playbook →

This article concludes the series on using prompts and AI in real UX and Product Design work.