The question before the prompt
A request such as “make this reminder page smarter” can produce a convincing-looking answer without resolving the product problem. The output may have a tidy layout and agreeable copy, yet it is unclear what a person is trying to do or which information the system actually has.
The useful first step is not a more elaborate instruction about style. It is a smaller, more precise task. What decision is the interface helping with? What is known? What must remain editable? Those questions make an answer reviewable, whether it comes from a person, an AI tool or both.
A synthetic reminder task
The starting request
Design a settings page for an appointment reminder. Make it simple and use AI to personalize it.
The request mixes a task with an unexamined solution. “Personalize” might mean recommending a time, choosing a channel or changing the appointment itself. Those are different products, with different consequences. A brief should resolve the boundary before asking for an interface.
Make the brief inspectable
I would turn the request into five explicit parts. This is a proposed design approach, not a report of a completed client process.
A structured brief
A person can set, inspect and change one reminder for an existing appointment.
The appointment date and the person’s chosen contact channel. No location, preferences or permission status may be invented.
The interface does not reschedule the appointment. Suggestions remain optional. The person confirms a setting before it is saved.
Empty, configured, editing, notifications unavailable and failed save with entered values retained.
The current time is readable. Edit is reachable. Inputs have labels. A failure explains what to do next. Keyboard access and narrow-width layout are required.
This structure does not make the design correct by itself. It makes omissions visible. A reviewer can now point to a missing edit state or an invented permission assumption without arguing about whether the page looks “smart.”
Critique the rough answer
A page shows a recommended time, a “Smart reminder” switch and a Save button. After saving, it says “You’re all set!”
This answer is plausible but incomplete. Where did the recommended time come from? What changes when the switch is enabled? Can the person inspect the saved setting? What happens when notifications are off? “You’re all set” could wrongly suggest delivery is guaranteed when only the setting was saved.
The missing pieces are not decorative improvements. They change the product’s meaning. A vague “smart” control bundles behavior the person cannot evaluate. A generic success message hides the distinction between saving an intention and executing it. Accessibility cannot be assumed from a tidy visual arrangement either.
Revise the interaction
Begin with the existing appointment and the chosen reminder time. Keep the label explicit. If a suggestion is justified by available information, explain the relevant basis briefly and allow another value. If that basis is missing, show a neutral choice instead of manufacturing a recommendation.
After saving, show the setting in a readable summary with an Edit action. Use specific copy: “Reminder time saved. You can change it in reminder settings.” If notifications are unavailable, state that separately and provide a real manual next step. Returning from that step should preserve the reminder configuration.
If saving fails, retain the entered value and explain the failure beside the affected area. A retry should have an observable result. These are proposed interaction requirements, not claims that the synthetic product has been implemented or tested.
A reusable review checklist
- Name the person’s task without embedding an unconfirmed AI solution.
- Separate known information from assumptions and missing data.
- Define default, edit, failure and recovery states before styling.
- Make suggestions optional and their consequences understandable.
- Review copy, semantics, focus order and the longest translation.
The checklist is useful because each item can fail independently. A strong headline does not compensate for a lost edit path, and a fluent translation does not establish the truth of a recommendation.
What this does not establish
A structured brief creates a better basis for discussion; it does not prove that an AI tool saves time or produces usable designs. Those claims require a defined comparison, representative work and recorded evidence. The example here establishes none of those outcomes.
Real users, product constraints and platform behavior can still invalidate the proposed flow. The next step in a real project would be to examine those constraints and review the task with the people who will use and build it.
Sources for the approach
Microsoft HAX provides guidance across capability communication, interaction and correction. Google PAIR discusses trust, errors and control. I use them as prompts for the review questions above, not as proof of the synthetic design’s success.
Voice and examples await Oksana’s review. This article presents design reasoning, not a claim of measured performance or a client study.
Back to the journal