What does “help me order dinner” mean?

Start with a tired, hungry person

It is 7:30 p.m. You want something spicy for under $25, including fees. The assistant returns twenty restaurant names. That is information, but you still have to do the comparison yourself. Your product should help someone reach a suitable decision with less effort.

This module is the first step toward a DoorDash ordering assistant. You will build the request-understanding stage. The examples use fictional information; recommendations and ordering come later.

First separate a hard constraint (a requirement), a preference (something to optimize), and an unknown (something to ask about or verify). “Must be under $25 total” is a constraint. “Thai would be nice” is a preference. An unstated delivery area is unknown.

A diner’s request branches into a wallet and receipt representing the $25 total constraint, a Thai noodle bowl representing a preference, and a map with a question mark representing the unknown delivery area. — Separate what must hold, what would be nice, and what is missing.

Check your understanding

Match each part of the request to its role.

A price is only useful if you know what it includes

A fictional meal costs $19. Delivery is $3, service fees are $2, and tax is $2. The total is already $26 before a tip. The menu price alone cannot establish that the order fits a $25 all-in budget.

Do not guess missing fees. Show which prices are known and which remain unverified. If a user says “under $25,” ask whether that includes fees, tax, and any tip rather than silently choosing an interpretation.

Check your understanding

Which response best handles a $25 all-in limit when delivery fees are unknown?

Define success before adding features

For this first module, measure request fidelity: did we preserve the stated requirements? Also check unsupported assumptions: did we invent a location, currency, or preference? Finally inspect question usefulness: did the follow-up remove a real obstacle?

A small test set is enough to begin: write five fictional requests and expected summaries. Count correct fields and invented fields. Later, you can measure time to a suitable decision with real users. A short interaction is useful only if it still respects their needs.

Check your understanding

Name two ways to judge whether the request-understanding step helped the user.

Save your product brief

Write your fictional dinner request, its constraints, preferences, unknowns, and three observable success checks. Keep this brief: you will use it again in the final lesson.

Key takeaways

Start with the decision the user needs to make.
Hard constraints define acceptable results; preferences help rank them.
An unstated fact remains unknown.
Judge request understanding by fidelity, assumptions, and useful questions.