effortless-interaction-design

Effortless interaction design

People use an interface without thinking when every action they repeat keeps the same look, place and result. A habit fires on the cue (a position, a shape, a word), not on the goal (Raskin 2000; Wood and Rünger 2016). So the work is to make each cue mean one thing, show it, answer it at once, and make a slip cost one step.

This skill is platform-neutral. It names what must be true and leaves the component to the platform: use the platform's own convention for each operation before inventing one, because users spend most of their time in other products (Nielsen 2000). Where a project has its own written decisions, those win, and an exception to a rule here is written down with its reason.

The five ideas

1. Same cue, same result. Each operation has one name, one symbol, one place and one gesture meaning, inside the product and as the platform taught it. A cue shared by two actions produces the wrong one.
2. Visible first, shortcut second. Every gesture, hover action and keyboard shortcut is a faster route to a control the user can see.
3. Every action answers at once and shows where its result went, even to someone who has looked away.
4. A slip costs one step. Practised hands slip on autopilot, so changes reverse, and work that took effort goes to a place it can be recovered from, for a stated time.
5. Design for the worst moment of use. Tired, one-handed, interrupted, glancing. The next action is the largest target in easy reach, needs nothing remembered, and survives an interruption.

The moment decides what is on screen

Before laying out anything, name the moment: who is here, what they are in the middle of, and the next thing they need to do. Then:

• One primary action per screen, at most three secondary ones. Everything else is one level away, behind a label that says what it holds.
• For each element ask "is this needed right now, to do the next thing?" If "sometimes", it moves one step away. If "no", it leaves.
• Show what the decision needs (the last value, the current state) on the screen where the decision is made, so nothing has to be remembered.
• Nothing added to a frequently used screen may slow its primary action, cover it, or move a control from under a practised hand.

Principles

Habit and consistency

• P1. Habits form on stable cues. A moved control, or a dialog on a routine action, pulls attention away. A familiar cue on a new action produces the old action. (Raskin 2000; Wood and Rünger 2016)
• P2. Consistent inside the product and with the platform. Same words, sequences and visuals for the same thing. Consistent behaviour outranks consistent looks. (Nielsen 1994, heuristic 4; Krause 2021)
• P3. What acts differently looks different. Two flows that share their first steps send the user down the practised branch. A destructive control that looks like a safe one gets pressed. (Norman 1981)
• P4. One visible way, at most one accelerator. Choosing between methods splits the repetition that builds a habit. A second way gives the same result, the same confirmation and the same undo. (Raskin 2002; Laubheimer 2020)

Seeing what to do

• P5. Signifiers, mapping, a correct model. A visible cue shows what can be done, a control sits by what it changes, and after a change the user can see where the item went. (Norman 2008, 2013)
• P6. Recognition over recall. Hidden gestures are rarely found, soon forgotten, and a failed one cannot be told from an unsupported one. Each has a visible twin. (Norman and Nielsen 2010; Budiu 2024)
• P7. A gesture means one thing. One gesture per direction in one area. Row swipes, paging, the back gesture and scrolling compete for the same movement. (Li 2017)
• P8. Few, mindless choices. Options that overlap in meaning stop people more than an extra step does. The most frequent option comes first. (Krug 2014)
• P9. Progressive disclosure, signposted. Rare options go to a labelled second level, one level deep. What the user cannot find does not exist. (Nielsen 2006; Tognazzini 2014)
• P10. The product carries the complexity. Never ask what can be inferred, or the same question on every visit. (Tesler's law)

Errors and recovery

• P11. Slips and mistakes need different defences. A slip (right intention, wrong execution) hits practised users and needs distinct targets and undo. A mistake (wrong intention) needs a correct model and a preview of what will change. (Norman 1981; Laubheimer 2015)
• P12. A delete runs at once and offers Undo. People confirm warnings by habit, so "Are you sure?" on a routine delete protects nothing and slows everyone. Ask only for what no undo can reverse, and then name the item and the action on the button ("Delete project", never "OK"). (Raskin 2007; Nielsen 2018)
• P13. Undo says what it reverses, restores the item in its place and in view, and covers no frequently used control.
• P14. Effortful work goes to a recoverable place with a stated period, after its Undo has gone.
• P15. One visible save model, and work is never lost. People assume nothing is saved until they save. Either save as they go and say so, or keep Cancel and Done in fixed places. Dismissing unsaved work asks or keeps it. A close button appears only where closing loses nothing. No error, crash or timeout loses input. (Harley 2015, 2019)

What else decides effort

• Words. One name per object and one verb per action, everywhere, including messages and companion surfaces. Buttons and menu items start with a verb. A label says what it opens without the screen around it. Search finds an object by the other names a user might type: two people pick the same word for a thing less than a fifth of the time (Furnas 1987).
• Symbols. Use the platform's symbols for add, delete, done, close, search, back and more. Few other symbols are understood alone, so they carry a text label (Harley 2014).
• Response. 0.1 s feels instant, 1 s keeps the flow, past 10 s needs visible progress (Nielsen 1993). A press shows within about 50 ms. A repeated press on a slow action creates one result, not two. Data already on the device never shows a spinner.
• Motion. A removed item leaves and the gap closes. An added item appears in its sorted place, scrolled into view. Motion is brief, never blocks the next input, and reduces to a fade when the user has asked for less motion.
• Feedback channels. Combine channels (visual plus sound or touch) for someone looking away. Each sound or haptic keeps one meaning and comes with a visual change.
• Status. Show status in place. An alert is for critical news the user can act on. A routine save is quiet and a failure shows.
• Defaults and constraints. People keep defaults, so a default is the likely value, never an arbitrary one, and a field accepts only valid input. (Nielsen 2005)
• Modes. The same input giving a different result causes slips. If a mode is needed, show it with two cues, end it with the task, and make sure a slip in it cannot destroy anything. (Raskin 2002; Laubheimer 2019)
• Interruption. State is saved after every action and restored on return, down to the place in a list and a half-typed value, with a cue to what was pending. (Altmann and Trafton 2002)
• Glances. On the move, attention comes in bursts of a few seconds (Oulasvirta 2005). The one number or word needed now is the largest thing on the screen.
• Unavailable actions. Say why an action is unavailable instead of ignoring the input.
• Errors. A message sits beside the problem, says what happened and what to do, does not blame, and keeps the input. (Neusesser and Sunwall 2023)
• Empty states. Say what belongs here, hold the control that adds it, and never show "nothing here" while data is still loading. (Kaplan 2021)
• Reach and targets. About half of phone touches are one-handed and grips change every few seconds (Hoober 2013). Frequent actions sit in easy reach and away from destructive ones. Minimum target: 44 by 44 pt on Apple platforms, 48 dp in Material, 24 by 24 CSS px at the least on the web (WCAG 2.5.8), with space between targets and more at the edges.
• Navigation. Navigation destinations never act, keep their place, and are never hidden or disabled. Every screen shows a title that says where the user is. Back always goes back.
• Larger text and assistive settings. At the largest text size a row stacks instead of cutting off, and every control stays reachable. Every icon-only control has a text label.
• Data entry. The keyboard or pad offers only what the field accepts. A refused key says so. Numbers follow the user's region (decimal separator, units, date order). The field being typed in stays in view.
• First use. People learn by doing: the first real task works without a tutorial, a setup step or an account. A permission is asked when its feature first helps, and a refusal is followed by a plain note and a link to the setting. (Kendrick 2020)
• Outside the product. A notification, widget or link opens the screen it is about. One event alerts once, not through two channels. A notification action does its task without opening the product.

How the principles map to a platform

Principle	Touch (phone, tablet, watch)	Web and desktop
Visible twin for every shortcut	Every swipe and touch-and-hold action is also a visible control within two taps	Every hover action, right-click item and keyboard shortcut is also a visible control; hover alone never reveals the only way
One meaning per gesture	One swipe direction does one kind of thing in every list	One key does one thing everywhere; drag means move, never select in one place and move in another
Signifiers	Rows that open show it; controls look pressable	Links look like links, buttons like buttons; focus is always visible
Back and place	Back button, back gesture and system back agree	The browser's Back, the URL and a reload return the same state
Undo over confirm	Undo in a transient bar that names what went	The same, plus the platform's undo shortcut where one exists
Save model	Explicit Cancel and Done, or autosave said plainly	Same; never lose a form to a timeout, a reload or a validation error
Targets	Platform minimum, thumb reach	Pointer targets large enough to hit without aiming; keyboard reachable in a sensible order
Interruption	Restore after the app is suspended or relaunched	Restore after a reload, a closed tab or an expired session

Where the sources disagree, and what to do

Question	Disagreement	Default here
Confirm or undo a delete	Most sources prefer undo for routine deletes; some accept either	Undo; a question only for what undo cannot reverse
One way or several	Raskin: one way; Nielsen and platform guides: accelerators	One visible way plus at most one accelerator with the same result
Fewer choices or fewer steps	Hick's law against Krug	Fewer steps on paths repeated many times a session; fewer, clearer choices elsewhere
Full swipe or other one-motion destructive gestures	Platforms enable them; field reports show accidents	Allowed only for an action that undo reverses, or one that asks
Target size	24 px to 48 dp across guides	The platform's own minimum, never less
Reordering	Drag alone, or a mode with handles	The platform's convention, plus a way to move an item without dragging

When a project decides one of these differently, it writes the decision down once and applies it everywhere. An inconsistent rule costs more than either choice.

The checklist

Run the questions on every new or changed screen, page, dialog, menu, shortcut and companion surface, once at design time and again on the built thing. Skip a question that does not apply; do not answer it "yes". An answer that shows a fault is a finding: fix the design, or record the exception and its reason first. A report lists the questions that found a fault and what was done. "Checked, no findings" is a valid report.

Every screen

1. Does each action keep one name, symbol and place wherever it appears?
2. Does each colour, icon and position mean one thing?
3. Does each operation use the platform's own component for it, and behave the same on every screen?
4. Where two screens do one operation differently, is the reason written down?
5. Does each object keep one name everywhere, and can everything that can be created be deleted wherever it is shown?
6. Do two flows with different outcomes begin with the same steps? Does a rare action beside a frequent one look clearly different?
7. Does any destructive control share the style and position of a safe one?
8. Can a first-time user tell which elements respond?
9. Does each control sit by what it changes, and after an add or delete can the user see where the item went?
10. Does each frequent action have one primary way, and does any second way give the same result, confirmation and undo?
11. Does each screen have one primary action and at most three secondary ones?
12. On each menu, can a user say in advance which option they want? Do two options sound alike? Is the most frequent first?
13. Is a primary action reachable only inside a menu, or is there a menu of one or two items?
14. Is anything nested deeper than two levels, and does each second level say what it holds?
15. Does the product ask anything it could infer, or the same question on every visit?
16. Do the universal actions use the platform's symbols, and does every other symbol carry a label?
17. Is every target at least the platform's minimum size, spaced, and larger near edges?
18. Does any mode change what an input does? Is it shown by two cues, ended with the task, and safe from a slip that destroys?
19. When an action is unavailable, does the screen say why instead of ignoring the input?

Lists, gestures and shortcuts

20. Does every row that opens something show that it does, and no other row?
21. Does activating a row do the same thing (open, or select) across the product?
22. Does every gesture, hover action and shortcut also exist as a visible control close by?
23. Does one gesture or key do the same kind of thing everywhere, whatever the item's state?
24. Is the destructive action in the same place and style in every list, with few enough actions that the row stays identifiable?
25. Does a one-motion destructive gesture run only what undo reverses, or what asks?
26. Do two gestures compete for one movement in one area (paging against row swipes, a scroll that triggers a drag)?
27. Does a context menu work on every item of a kind or on none, with delete last and marked destructive?

Adding, opening and going back

28. Is add in the same place on every collection screen?
29. Does a new item appear in its sorted place, in view?
30. Does a double activation of Add create one item?
31. Does each empty list say what belongs there and hold the add control, hidden until the first load answers?
32. Does each object open the same way wherever it is listed?
33. Does any dialog open another on top of itself?
34. Does every dialog name its task and have an obvious exit?
35. Does Back always go back, with the product's back, the system's and the gesture in agreement?
36. Do navigation destinations only navigate, stay visible, and keep their place?

Editing and saving

37. Are Cancel and Done in the same places in every editing view?
38. Can the user tell whether a change is saved? Does the close control mean one thing everywhere, and appear only where closing loses nothing?
39. Does dismissing an edited view ask or keep the edits, while an unedited one closes at once?
40. Does a failed save keep the input and say what went wrong?
41. Do fields take only valid values, and is each prefilled value the likely one?
42. Does a broad action (merge, import, bulk delete) preview what will change?

Deleting and undo

43. Does every delete run at once and offer Undo that names what went? Is a question asked only for what no undo can reverse, naming what will change?
44. Is every delete control marked destructive in the platform's way?
45. Can a stray input destroy data with no way back?
46. Does each Undo say what it reverses, leave frequent controls uncovered, and restore the item in place, in view?
47. Can effortful work be recovered after its Undo has gone, and does the product say for how long?

Reordering, selecting, searching

48. Do user-ordered lists reorder the platform's way, and do sorted lists refuse to?
49. Can a wrong move be undone, and is there a way to move an item without dragging?
50. Is multiple selection entered by a visible control, does the toolbar act on the selection, and does a confirmation name the count?
51. Do results update as the user types, and does a result behave as the same item does in its own list?

Feedback

52. Does every add, delete, edit and save change the screen within 0.1 s, and can the next input land during the animation?
53. Does every press show a pressed state at once?
54. Does each sound or haptic always mean the same thing, and come with a visual change?
55. Can a user who looks away know the action worked?
56. Is a routine success quiet while a failure shows? Is any alert purely informational?
57. With reduced motion, is each add, removal and move still visible?

The frequent path

58. Can the next action be found and done in one glance and one step?
59. Is the frequent action the largest target, in easy reach, and at least one target away from any destructive control?
60. Is everything the frequent task needs on the first level, with what a decision needs on screen?
61. If the product closes mid-entry, does the typed value survive, and does the return show the next step?
62. How many steps and decisions does each frequent task take, and does any need a scroll, a hidden gesture or a menu?

Words and wayfinding

63. Does each object keep one name in titles, buttons and messages, and does search find it by other names?
64. Does every button and menu item start with a verb, and does each label say what it opens without the screen around it?
65. Does every error say what happened and what to do, beside the problem, without blame, keeping the input?
66. Does each setting say what turning it on does, and does a message that depends on a setting link to it?
67. Does every screen show a title that says where the user is?

Memory, settings and first use

68. After a restart or reload, are the place, the scroll position and any half-typed value where the user left them?
69. At the largest text size, does each row stack instead of cutting off, with every control reachable?
70. Does every icon-only control carry a label that names its visible meaning?
71. Do numbers, dates and separators follow the user's region?
72. Can a new user do the first real task without a tutorial, a setup step or an account?
73. Is each permission asked when its feature first helps, and after a refusal does the feature say so and link to the setting?
74. Does a tip for a hidden shortcut show once, and only to people who have not used it?

Outside the product

75. Does a notification, widget or link open the screen it is about?
76. Does one event alert once, not through two channels?
77. Does each notification action do its task without opening the product, the most used first?
78. Do companion surfaces (watch, widget, extension) name and order their controls as the main product does?

Auditing an existing product

An open-ended "review this for usability" is unreliable: one evaluator finds about a third of the problems (Nielsen 1994), two evaluators can agree on very little (Hertzum and Jacobsen 2003), and an AI reviewing screenshots from an open prompt reported mostly false positives (Holst 2023). Fixed yes-or-no questions, an inventory that compares screens, and several methods together do better. These figures are as cited in the research digest this skill came from; read the source before quoting one elsewhere.

1. Read the written decisions the product already has, so the audit reports departures from them and does not reopen them.
2. Inventory objects and operations. One row per object, operation and place: trigger, label or symbol, visible without prior knowledge, confirmation, feedback, undo and for how long, steps, reach, the same operation elsewhere, and how it differs.
3. Inspect for consistency. Sort the inventory by operation and compare trigger, label, confirmation, feedback and undo. Each difference that no written decision explains is a candidate finding.
4. Walk the tasks. For each step ask two questions: will the user know what to do, and will they know it worked? Count the steps and decisions. Walk the most frequent tasks first, then the rare ones, then first use from a clean install, then entry from outside (notifications, links, widgets). Check lists at real scale, not only with sample data.
5. Run the checklist, screen by screen.
6. Report each finding in one form: a title under ten words; what was seen and where; the principle or question; severity; one specific proposed change with an example.

Severity, rated on frequency, impact and persistence (Nielsen 1994):

Rating	Meaning	Typical case
0	Not a problem
1	Cosmetic	A word or symbol on a rare screen unlike the rest
2	Minor	A rare operation needing a second look or an extra step
3	Major	A stop or slip on a frequent path; an operation with only a hidden way; a delete unlike the others
4	Catastrophe, fix before release	Data lost for good; a slip that discards work in progress

One rater is unreliable, so a person who owns the product confirms every 3 and 4.

Working rules

• Decide the rule once, write it down, apply it everywhere. A second way to do an operation, or a delete that asks, needs a written exception with its reason.
• Design the change, run the checklist, build it, run the checklist again on the built thing.
• A built screen that differs from its design is changed to match. A problem the design causes is fixed in the design first.
• Fix the class, not the instance: when one list's delete is wrong, compare every list.
• Give a workaround for a one-off problem before adding a feature for it.

Sources

Named above by author and year. The ones this skill leans on most:

• Raskin, The Humane Interface, 2000.
• Norman, "Categorization of Action Slips", Psychological Review 88(1), 1981; The Design of Everyday Things, revised edition, 2013; "Signifiers, not affordances", 2008, https://jnd.org/signifiers-not-affordances/
• Norman and Nielsen, "Gestural Interfaces: A Step Backwards In Usability", 2010, https://jnd.org/gestural-interfaces-a-step-backwards-in-usability/
• Nielsen, "10 Usability Heuristics", 1994, https://www.nngroup.com/articles/ten-usability-heuristics/
• Nielsen, "Response Times: The 3 Important Limits", 1993, https://www.nngroup.com/articles/response-times-3-important-limits/
• Nielsen, "Confirmation Dialogs Can Prevent User Errors (If Not Overused)", 2018, https://www.nngroup.com/articles/confirmation-dialog/
• Nielsen, "Progressive Disclosure", 2006, https://www.nngroup.com/articles/progressive-disclosure/
• Nielsen, "The Power of Defaults", 2005, https://www.nngroup.com/articles/the-power-of-defaults/
• Krug, Don't Make Me Think, Revisited, 2014.
• Krause, "Maintain Consistency and Adhere to Standards", 2021, https://www.nngroup.com/articles/consistency-and-standards/
• Laubheimer, "Preventing User Errors", 2015, https://www.nngroup.com/articles/slips/ and https://www.nngroup.com/articles/user-mistakes/; "Modes in User Interfaces", 2019, https://www.nngroup.com/articles/modes/; "Flexibility and Efficiency of Use", 2020, https://www.nngroup.com/articles/flexibility-efficiency-heuristic/
• Li, "Using Swipe to Trigger Contextual Actions", 2017, https://www.nngroup.com/articles/contextual-swipe/
• Harley, "The Case of Autosave", 2015, https://www.nngroup.com/articles/efficiency-vs-expectations/; "Cancel vs Close", 2019, https://www.nngroup.com/articles/cancel-vs-close/; "Icon Usability", 2014, https://www.nngroup.com/articles/icon-usability/
• Budiu, "Memory Recognition and Recall in User Interfaces", 2024, https://www.nngroup.com/articles/recognition-and-recall/
• Kaplan, "Designing Empty States in Complex Applications", 2021, https://www.nngroup.com/articles/empty-state-interface-design/
• Kendrick, "Mobile-App Onboarding", 2020, https://www.nngroup.com/articles/mobile-app-onboarding/
• Neusesser and Sunwall, "Error-Message Guidelines", 2023, https://www.nngroup.com/articles/error-message-guidelines/
• Hoober, "How Do Users Really Hold Mobile Devices?", UXmatters, 2013, https://www.uxmatters.com/mt/archives/2013/02/how-do-users-really-hold-mobile-devices.php
• Oulasvirta et al., "Interaction in 4-second bursts", CHI 2005.
• Furnas, Landauer, Gomez and Dumais, "The Vocabulary Problem in Human-System Communication", Communications of the ACM 30(11), 1987, https://doi.org/10.1145/32206.32212
• Altmann and Trafton, "Memory for goals", Cognitive Science, 2002.
• Platform guides, read for the platform in hand: Apple's Human Interface Guidelines, https://developer.apple.com/design/human-interface-guidelines/; Material Design 3, https://m3.material.io; WCAG 2.2, success criterion 2.5.8 (target size).