A good default is easy to change.
A starting choice can save effort without becoming a hidden rule. Put consequential defaults where people can see and revise them.
A default is a small bet about what someone will need.
Suppose a meal-planning tool starts every recipe at four portions. That may be a reasonable place to begin. It becomes a less reasonable choice when a person cooking for one must open settings, change a household profile, and recreate the plan to make the quantities useful.
Four is only a starting suggestion. Changing it should not require rearranging the rest of the application.
I like defaults that help someone begin and then step aside. They should not make the person argue with the application about their own dinner.
For this hypothetical planner, put the portion count beside the recipe quantities. Make changing it ordinary. Explain whether the change affects this meal, the current plan, or future recipes as well. Those are different intentions, even though they may all begin with the same number field.
A preference can save effort later. It should not reach backward and quietly alter meals someone has already arranged.
Put the consequence where the choice is
Some defaults have very little weight. Opening a list in alphabetical order is usually easy to notice and change. Sending reminders, sharing a plan, or replacing an existing value deserves more attention.
The more a default changes something outside the current view, the less comfortable I am leaving it invisible.
In the meal planner, a shopping list might combine ingredients from the selected recipes. A default that rounds quantities up could be helpful for buying whole packages, but misleading if the person thinks they are looking at exact recipe needs. Name the view accordingly and leave the underlying quantities available.
Do not bury that explanation in a general preferences page. The shopping list is where the distinction matters.
This is not an argument for a setup questionnaire before every task. Ask for decisions when they become useful. A person can adjust the portions while planning a meal without first configuring their entire relationship with food.
A visible control at the right moment can do more than a large settings page nobody has a reason to visit.
Remember a choice without making it permanent
There is a difference between remembering what someone chose and deciding they will always want it.
For the imaginary planner, “Use this portion count for new meals” would make that intention explicit. A one-off meal for visitors should not silently redefine the usual plan. Likewise, restoring the original starting choice should not erase unrelated preferences.
Reversibility has limits. You cannot necessarily undo a notification already sent or recover information a destructive action removed. Those choices need clear consent and appropriate safeguards, not merely a setting that can be switched back afterward.
Review a default from the position of someone whose needs differ from the assumed starting point. Change it during the task. Begin another task and see what carries forward. Look at older work and check that it has not changed without an explanation.
A useful default leaves the ordinary path short while keeping other paths available. Four portions can be a suggestion. Dinner still belongs to the person making it.