Product teams adopt AI when it measurably improves a user job—speed, relevance, safety—not because "AI" is a marketing checkbox. Successful features define fallback UX when the model is wrong or unavailable.
Discovery questions
- What user pain is painful enough to automate?
- What happens when the model fails—silent wrong answer or graceful degrade?
- Do we have data and labels to iterate?
- Is latency and cost acceptable per request?
UX patterns
- Suggestions user can edit (email drafts, search queries)
- Confidence cues and "report issue"
- Hybrid search: keywords + semantic ranking
- Offline mode without AI when API down
API response shape
# Conceptual product API payload
response = {
"prediction": "likely_spam",
"confidence": 0.91,
"explanation": "matched known phishing patterns",
"model_version": "spam_v12",
}
print(response["model_version"])Practice: Sketch product flows on paper or in a doc—optional Python illustrates API response shapes only.
Important interview questions and answers
- Q: AI-first vs AI-assisted?
A: Assisted keeps human authority; first automates core path—higher risk. - Q: Fallback UX?
A: Cached rules, manual workflow, or honest "unavailable" message.
Self-check
- List two discovery questions before adding AI.
- Why expose model_version in API responses?
Tip: Design fallback UX when the model is wrong or the API is down.
Interview prep
- Fallback UX?
- Rules, manual workflow, or clear unavailable state when model fails.
- model_version in API?
- Enables debugging, rollback, and audit trails.