Start with the outcome

Before choosing an implementation, know what should become possible for the person using it. Describe the result in terms they could recognize. For an API or library, that person may be another developer.

“Add an export button” describes a control. “An accountant can download the filtered transactions and reconcile their exact amounts” describes an outcome. It tells us what the button must deliver, and what to check.

A useful starting point is one sentence, a sketch or an example response. Before designing the internals, try the interface as though the feature already exists: write the command, response or screen and walk through using it. Check how it fits adjacent features. A small throwaway example can expose an awkward interaction before it becomes an implementation constraint.

Include the constraints that change the answer: who can act, what data they need, what must remain private, and what happens if the operation fails. Ask questions when the answers change the solution. Choose routine details without turning every step into an approval request.

Finish a small, useful piece

Choose a scope that can be used and judged as a whole. An export that works for the current filters and says which records it includes is useful. A row of buttons for unfinished formats is not.

Use defaults that let people begin with little setup. Reveal advanced controls when they become relevant. Prefer familiar behavior and remove choices that do not help someone do their work.

Consider how the change meets the existing product. If the same action is available from a shared link and a signed-in view, carry the behavior through both. Preserve genuine differences in permission; avoid accidental differences in meaning.

State what the release includes and what it leaves out. Do not imply that a preview covers cases it has never handled. Feedback from actual use should help decide what to improve next.