Think Like the User for Interaction Design
The Problem
When AI writes interactions, it tends to organize the interface in the order of implementation rather than in the order the user carries out the task: whatever data structure comes first becomes the first control; whichever function was written first determines where the button goes. The results:
- The "Save" button on a long form is at the top of the page, forcing the user to scroll all the way back after filling in the bottom fields
- "Delete" sits right next to "Save," looking exactly the same—same color, same size
- The most frequently used feature is buried in the second level of a "More ⋯" menu, while an infrequently changed setting occupies the most prominent spot in the toolbar
- Even with only one option, the user must select it before clicking "Next"
- To rename something: click "Edit mode" → make the change → click "Apply" → click "Save" → confirm dialog: "Are you sure you want to save?"
- A three-step wizard to create something that only needed a name
- Buttons say "Submit," "Execute," or "OK"—the user has no idea what will happen when they click
- On error, a generic "Operation failed" message appears, and all entered content is wiped
Each issue alone is minor, but together they create the feeling: "Why is this so awkward?"
Step 1: Clearly State What the User Came to Do
Before you start, write down (even if only mentally):
- Who is using it: A first-time newcomer, or a daily power user?
- What are the 1–3 most common tasks: These must be the fastest and most prominent.
- The ideal path for each task: From opening the program to completion, what is the minimum number of steps?
Arrange the layout based on this priority, not based on the feature list, database fields, or code modules.
Step 2: Where to Place Buttons and Entry Points
| Principle | How to Apply | Anti-Pattern |
|---|---|---|
| Actions go near their target object | Edit/delete buttons go inside the same row; card actions stay on the card | First select a row, then go to the top of the page to find "Edit" |
| Place according to workflow position | The submit button for a form goes at the end of the form; dialog buttons go at the bottom | A long form's save button at the very top |
| Frequency determines prominence | Most common features are exposed directly; occasional ones go in a menu; rarely used ones go in settings | Frequently used features hidden in a second-level menu |
| One primary action per screen | The primary action uses a prominent style; all other actions use secondary styles | Five equally prominent blue buttons |
| Separate dangerous actions | Use a different color, place a safe distance away, or put it in a menu for the delete action | Delete and save side by side, looking identical |
| Follow platform conventions | Windows: dialog buttons at the bottom-right, "OK" left of "Cancel"; macOS: "Cancel" left, primary button far right; web modals: close button at the top-right | Inventing a custom order |
| Same action, same place every time | Every page's "New" button is in the same location | The position varies from page to page |
| Entry points where users look | When the user thinks "I want to export," they will look at the toolbar, File menu, or the area above the list | The export function is hidden inside the settings page |
Step 3: Eliminate Redundant Steps
List every step of the primary task, then ask for each:
- Can it be deleted? Does the user have to make a decision at this step? If not, delete it.
- Can a default be provided? If 90% of users would pick the same option, pre-select it. Remember the user's last choice.
- Can steps be merged? Can "Edit → Apply → Save" become direct editing with auto-save, or a single save action?
- Can it be deferred? Could registration, detailed settings, or optional fields wait until the user actually needs them?
- Can it be inferred automatically? If the information can be deduced from the file name, context, or existing data, don't ask the user to enter it.
Common redundant steps:
| Redundant Pattern | Better Alternative |
|---|---|
| A reversible action still asks "Are you sure?" | Execute immediately and provide an "Undo" option (Gmail-style toast); confirm only for irreversible, high-impact actions |
| Confirmation dialog says "Are you sure? [OK][Cancel]" | Clearly state the consequence and target: "Delete 3 files? This action cannot be undone. [Delete][Cancel]" |
| User must select the only option available | Auto-select it, or skip the step entirely |
| A separate "Edit Mode" toggle | Make it directly editable |
| A multi-step wizard for a single field | One input + one button, or inline creation |
| After changing a setting, must click "Apply" then "Save" | A single action, or immediate effect |
| After an operation, the user is taken to a different page and must navigate back | Stay in place; update the content in situ |
| User has to re-enter the same information every time | Remember it, or pre-fill it |
Step 4: Don't Add Things the User Didn't Ask For
AI is prone to "just adding extras": the user asked for an "Export" button, and it adds an export format dropdown, export history, and an export settings page; the user wanted a small tool, and it adds a sidebar, settings menu, theme switcher, About page, Help center, and "Coming Soon" placeholder entries.
Every extra feature, menu, or entry point is one more thing the user has to understand and skip—making the primary task's entry point harder to find. Everything on the interface competes for the user's attention.
Before adding something, ask:
- Did the user ask for it? If not and it's not essential for completing the primary task, don't add it.
- Without it, would the user be stuck? If not, don't add it.
- Does it have only one option, or will almost nobody ever change it? If so, there is no need for a setting or dropdown—just use a sensible default.
- Is it empty, unimplemented, or a "might be useful later" placeholder? Do not include placeholder entries, grayed-out "Coming Soon" items, or menu options that do nothing when clicked.
Common extraneous items:
| What's Unnecessary | Better Approach |
|---|---|
| A tool with only one or two features has a sidebar + top navigation + settings menu | One screen that directly presents the functionality |
| Theme switcher, language switcher, per-user personalization that nobody requested | Don't do it; add it only when needed |
| A single-page app is split into "Home / Dashboard / About / Help" | One page |
| The same feature has three entry points (toolbar, context menu, settings page) | One entry point where the user is most likely to look; additional keyboard shortcuts are fine |
| Placeholder "Coming Soon," "Advanced Features," or empty statistics cards | Delete them |
| Every value is made configurable | Provide good defaults; expose only the settings users actually change |
If you genuinely believe an extra feature is useful, mention it as a suggestion after completing the primary requirement and let the user decide whether to include it—don't just build it in.
Step 5: Let the User Always Know What's Happening
- Button label = verb + object: "Export CSV," "Delete project," "Send invitation"—not "Submit," "Execute," or "OK." Use the user's words, not implementation jargon (don't write "Sync payload" or "Trigger job").
- Provide feedback on click: Visual feedback within 100 ms; for operations taking more than 1 second, show progress or a loading state and disable the button to prevent duplicate submissions.
- Tell the user when it's done: A lightweight success notification, or show the result directly in the interface.
- Tell the user what to do on error: Clearly state what went wrong and how to fix it; display the error next to the field that has the problem; preserve all user-entered content.
- Guide the user from empty states: When a list is empty, tell the user what will appear there and provide a "Create the first one" button.
- Keyboard: When a dialog opens, set focus to the first input field; Enter to submit, Esc to close; Tab order should match the visual order.
- Don't surprise the user: Do not move buttons or pop up overlays that block what the user is about to click during their interaction.
The same applies to CLI: common parameters should have short options and sensible defaults; dangerous operations should ask for confirmation but provide a --yes flag; error messages should explain how to fix the problem; long-running tasks should show progress.
Step 6: Actually Walk Through It
Writing it is not the same as making it usable. Before delivery, truly walk through the primary task as a user (screenshot method: see background-friendly):
- Pretend it's your first time: don't look at the code, only at the interface—can you find the entry point of what you want to do within 5 seconds?
- Count the steps: How many clicks/inputs does it take to complete the primary task? Compare to the ideal path you wrote in Step 1—every extra step must have a reason.
- Walk through it using only the keyboard.
- Deliberately make a mistake: enter invalid input, cancel mid-way, disconnect the network—observe what happens and whether the input is lost.
- Shrink the window, fill it with a lot of content, or leave it empty—are the buttons still in reasonable positions?
If you cannot actually walk through it (no runtime environment), explicitly tell the user "Interaction flow not actually verified" and list the steps you designed so the user can check them.
Boundaries
- When the user specifies the layout or workflow, follow it; if you think something is wrong, voice your concern and let the user decide.
- Expert users of professional tools may value efficiency over ease of learning: keyboard shortcuts, batch operations, and high information density may be more important than new-user onboarding. First identify who the user is.
- Irreversible, high-risk operations (payments, deleting production data, sending mass messages) deserve an extra confirmation step—do not remove this just to reduce step count.
- When modifying an existing program, do not drastically change positions that users have already learned just because you think the new layout is "more logical"; if a change is truly necessary, explain why.
Checklist
- What are the 1–3 most frequent tasks? Are they the fastest and most prominent?
- Is every button placed next to its target object and at the point in the workflow where the user completes the action?
- Does each screen have only one primary action? Is the dangerous action separated from the primary one?
- Does it follow platform conventions (button order, position, keyboard shortcuts)?
- For every step of the primary task, have you asked "Can I delete it, provide a default, or merge it"?
- Are every feature, menu, and entry point either requested by the user or essential? Are there no placeholder entries or unrequested settings?
- Are confirmation dialogs used only for irreversible actions? Are reversible actions given an "Undo"?
- Are button labels written as "verb + object" and using the user's own words?
- Are loading, success, error, and empty states handled? On error, is the input preserved?
- Have you actually walked through the flow as a new user and counted the steps? If not, state "Not verified."