These notes explain how to design interfaces under the constraints of "small screens, finger operation, and fragmented usage". A phone is not a shrunken computer: the screen is small, input is via thumb taps, users often only have 15 seconds, and they frequently use devices while walking. The full text is divided into eight sections —
(1) Physical constraints(Tap cost from Fitts's Law + 15-second microsessions) form the foundation;(2) Overlays and navigation(Bottom sheets/accidental overlay dismissal/tabs/carousels) are the easiest type of controls to get wrong on mobile;(3) Forms and input(Checkout/time zones/data tables) are the hard battle of "making users type less on small screens";(4) Three states of system status(Indicators/validations/notifications) tell you "which method to use to communicate with users";(5) Error messages Provide a scoreable evaluation rubric + writing guidance;(6) Push notifications List five mistakes that make users uninstall apps;(7) Onboarding guidance Use experimental data to prove "tutorials are basically useless; build contextual help instead";(8) Cross-device and physical-digital bridges(Responsive content dispersion/QR codes/smartwatches/banner blindness).
One core principle that runs through the entire text:Every tap, every scroll, every second of waiting on mobile has a higher cost than on desktop— so saving taps, saving typing, and saving memory load is always the right choice.
1. Physical constraints of mobile interaction: Fitts's Law + 15-second microsessions
This is the physics foundation of the entire set of notes.Fitts's Law is a law validated over decades: the time required for a user to move a pointer (mouse cursor or finger) to a target is determined by the size of the target and distance together —移动时间 T ∝ log(距离 D / 宽度 W). Two intuitive conclusions:Larger targets are tapped faster, closer targets are tapped faster. Note that this is a logarithmic (log) relationship, so if distance doubles, time increases but does not fully double (people accelerate when starting movement and decelerate when approaching the target).
| Design levers | How to apply | Why / Counterexamples |
|---|---|---|
| Make targets larger | Make buttons, icons, and tappable areas as large as possible | Large targets reduce mistaps and enable faster tapping |
| Add text labels to icons | Labels expand the entire tappable area | Pure icons have small tap zones; adding the text "Delete" enlarges the area and improves clarity |
| Place related controls close together | Put form "Submit" next to the last input field, not at the top of the page | Reduce finger/cursor movement distance (Sephora placing Save at the far end of the form = counterexample) |
| Do not crowd elements too tightly | Leave sufficient whitespace margins between targets | Elements placed too close together cause mistaps (echoes error prevention principles) |
| Edge "infinite targets" — only valid for mouse interfaces | The macOS menu bar sits at the top of the screen, the Windows taskbar sits at the bottom — the cursor cannot move past the screen edge, no deceleration is needed, so movement time is extremely short | On touchscreens it is the opposite: fingers may slide past the screen boundary causing mistaps, so edge targets on touchscreens are actually harder to tap; do not place critical actions along screen edges |
Menu geometry: Linear menus (arranged vertically) have hard-to-reach items at the far end; rectangular/large Mega Menus use both horizontal and vertical directions to shorten average distance; Pie Menus place every item equidistant from the center for highest efficiency. Aligning the trigger handle to the middle of a linear menu also reduces average movement time.
Mobile Microsessions— the extension of Fitts's Law in the time dimension. Definition:Phone operations lasting less than 15 seconds(The term originates from research by Ferreira et al., who found that over 40% of mobile sessions are microsessions; the threshold for older users can be relaxed to approximately 22 seconds). Core principle:Even if the task itself is complex, shortening the "step time required to complete it" still improves experience. Four design patterns that support microsessions:
| Method | How to implement | Key points / Counterexamples |
|---|---|---|
| Notifications | Approximately60% of microsessions involve reading/acting on notifications | Notifications must be self-contained(usable without opening the app, e.g., Lyft directly shows driver + arrival time); even truncated content must leave enough clues (YouTube truncates titles but the keyword "Everleigh" is sufficient for judgment); support direct actions within notifications. Counterexample: Amazon only says "Delivered" without stating what was delivered |
| Widgets | Compressed app views on the home screen that display dynamic information | Do not truncate critical information (CNN widget still truncates headlines when expanded = forces users to open the app); allow limited interaction (Gmail widget supports scrolling); focus on one data point |
| Quick Actions | Long-press app icons to jump directly to tasks (United Airlines long-press → direct check-in) | Only place high-frequency, important tasks; do not include low-frequency items such as "Invite friends" (Airbnb) or "Your contributions" (Google Maps); keep the count limited |
| Voice assistants Siri/Google Assistant | Reach tasks directly via voice commands (PayPal suggests setting the shortcut word "Cheese" for frequent transfers) | Combine time and location for smarter behavior; analyze behavior to proactively recommend shortcuts |
Current status: Except for notifications, user adoption of widgets/quick actions/voice assistants remains low — but they deliver significant efficiency gains for users who do use them. In-app promotion and education are needed to raise awareness.
2. Mobile overlays and navigation controls: Bottom sheets, accidental overlay dismissal, tabs, carousels
These are the mobile controls that are easiest to get wrong, with the common problem that "users cannot tell what this is, how to close it, and what they will lose if they close it".
2.1 Bottom Sheets
Definition: Overlays that pop up from the bottom of the screen to display additional information or actions. They are a form of Progressive Disclosure — hidden by default and appearing only when needed; because they cover content, they are only suitable for temporary information/actions, not for persistent tools. Three forms + five guidelines:
| Form | Meaning | Example |
|---|---|---|
| Modal | Cannot perform other actions until resolved, often with a semi-transparent scrim | UniFi network disconnected prompt (must resolve first) |
| Nonmodal | Does not force interaction, background remains operable | Google Maps destination details (user can still pan and zoom the map at the same time) |
| Expandable | Tap/drag to expand to full screen; nonmodal when minimized, becomes modal when expanded | Apple Podcasts mini player bar → full screen |
| Guideline | Key point | Counterexample |
|---|---|---|
| 1 Support closing via the "Back" key | Full-screen sheets are easily mistaken for regular pages, so users will press the back key | Many sheets do not support this, breaking established habits |
| 2 Provide an explicit X close button | Not everyone will "grab the top handle and swipe down"; swiping also depends on gesture precision | Pocket places the handle at the top of the screen, making it easy to accidentally open the notification shade, and requires a long continuous downward swipe to close |
| 3 Do not stack multiple sheets | Multiple stacked layers make it unclear whether closing dismisses the top layer or the entire stack | Walmart opens product details inside a bottom sheet, then stacks a review sheet on top; "Back" closes one layer, "X" closes the whole stack, confusing users |
| 4 Use only for brief interactions | These are temporary UI; do not place content that requires long reading/browsing | Soundbrenner places course content in a sheet; when scrolling, an accidental downward swipe bounces the user directly back to the home page |
Common misconception: assuming bottom sheets are "easier to tap" (closer to the thumb). In reality,the bottom of the screen is not always the easiest place to tap — it depends on how the user holds the phone.
2.2 Accidental Dismissal of Overlays
Overlays = layers placed over main content (navigation menus, bottom sheets, product details, in-app browsers). Classified along two dimensions:Partial coverage vs full-screen coverage(full-screen is almost indistinguishable from regular pages),modal vs nonmodal. There are four closing methods (X/back button, tapping outside empty area, downward swipe gesture, device back key); the problem is that users cannot predict which method will produce the desired result:
- Choosing the wrong close method: Walmart tapping X closed the entire stack instead of the top layer; LinkedIn using the back key to close a submenu instead returned to the initial page and lost navigation history; Instagram accidentally returned to the main screen instead of the previous layer.
- Lost work: Overstock tapping outside accidentally closed the menu and lost the selected subcategory.
- Stacking amplifies confusion: Google Maps trying to close restaurant details to return to the list instead closed all overlays back to the map, requiring a new search.
Prevention methods: ① Prioritize alternative designs(standalone pages / accordion menus) to avoid overlays; ② If overlays are necessary,prioritize partial coverage(easier to recognize, reduces back-key misuse, except for long scrollable content); ③ Do not stack; ④ Provide an explicit X button (Best Buy positive example); ⑤ Support device back key closing the overlay instead of directly exiting the page (Dillards positive example).
2.3 Tabs
Tabs let users select one option from multiple choices to view its panel.Do not mix the two types of tabs — this is the core point:
| Dimension | Navigation Tabs | In-page Tabs |
|---|---|---|
| Content | Broad scope, unrelated to each other, different content | Narrow scope, related to each other, similar content |
| Position | Top/left of the viewport (often at the bottom on mobile) | Not fixed, embedded within the page layout |
| Scrolling | Sometimes fixed to the viewport | Rarely fixed |
| User expectations | Jump to a new view, may have loading delays | Stay in the current view, load immediately |
| Default selection | Usually present (may be absent when entering from footer links) | Always present |
When to use tabs: Content is long with clear groupings, few groups (fewer is better), uneven importance (the default tab gets the most attention), tab names can be kept short, and there is no need to compare multiple panels at the same time.Counterexample: Google Ads Manager uses tabs for categorization, forcing users to switch constantly to see all content, which is cumbersome (should be changed to a single page).Compared to accordions: Accordions are suitable for mobile + long tab names + short FAQ content; tabs are suitable for desktop + long content + complex layouts.
Visual best practices (condensed):① Use at least 2 selection indicators(shared area/underline/bold font/size/icon — multiple indicators are especially important when there are only 2 tabs; CNN’s faint bolding alone is a counterexample); ② Unselected tabs must also be clearly legible (MongoDB’s unselected tabs had too low contrast and were mistaken as unclickable, a counterexample); ③ Selected tabs must be placed close to and connected with their panel (PaneraBread’s large padding + full-width line separated tabs from the panel, a counterexample); ④Use only one row, do not stack(Amazon’s stacked tabs in 2000 are a classic counterexample: clicking back-row tabs either broke the connection or scrambled the order); ⑤ Place the tab list above the panel (Okta placed it on the right + auto-advanced to the next tab with animation, a counterexample). Content practices: Place high-frequency content first and select it by default;Tab names should be 1–2 words, descriptive, and not in all caps(All caps harms readability; Penguin Random House is a counterexample). Tab management features (add/delete/rename) should not rely solely on right-click (Excel is a counterexample). Accessibility: Keyboard-navigable (select with Enter/Space), high-contrast focus, correct ARIA roles.
2.4 Carousels
Multiple banners displayed in rotation to save space, but UX is often suboptimal.Challenges: ① Users often ignore them, treating them as ads and swiping past directly (countermeasure: do not place key information only in the carousel; repeat it elsewhere); ② Autoplay —autoplay is not recommended on mobile; on desktop, use testing to set the playback interval, disable it if you cannot determine one, and always let users switch manually; ③ Navigation controls (dots/arrows) are hard to discover and tap (countermeasure: use large buttons/swipe gestures, show part of the next frame for visual cues); ④Mobile users typically only view 3–4 frames(countermeasure: limit frames to ≤3–4, do not make content themes too scattered); ⑤ May dilute key content (countermeasure: evaluate whether each frame is important enough; if necessary, show only one key banner).
Resolving team conflicts: Carousels are often used to "settle internal fights over page real estate." If there is too much argument, simply use a single banner to force the team to focus on the most important information.
III. Mobile Forms and Input: Checkout, Time Zone Selectors, Data Tables
The main battleground is "making users type less and scroll less on small screens."
3.1 The Mobile Checkout Experience
Checkout directly impacts conversion and revenue. Four groups of key points:
| Stage | Do | Counterexamples |
|---|---|---|
| Cart and checkout entry | Tapping the cart icon goes directly to the full cart; clear "Remove" button; changes take effect automatically without an "Update" button; cross-device sync (Apple Handoff relays between iPhone/iPad/Mac);guest checkout prioritized over login/registration | PSSW requires extra taps to reach the full cart; HP requires setting quantity to 0 to delete items; ThingsRemembered requires tapping "Update" to save changes |
| Order summary and pickup | Place the summary at the top of the page and expand it to show every line item; use location to estimate taxes and offer nearby store pickup (Target) | Adidas places the summary at the bottom and collapses it, making price breakdowns hard to see |
| Form fields and input | Match each field to the appropriate keyboard(numeric keyboard for number fields, email keyboard with @ and.); auto-fill city and state by ZIP code (editable); compatible with browser autofill;Use open input boxes instead of long dropdowns(typing state names or credit card expiration dates is faster than scrolling dropdowns) | Staples makes users scroll through a long dropdown to select state names |
| Mobile payments | Offer PayPal/Apple Pay etc., but not too many to avoid choice overload; place the most-used option first/most prominently (Vineyard Vines places PayPal on both cart and payment pages to prevent misses); support credit card scanning via camera(Safari autofill) | —— |
3.2 Time-Zone Selectors
Seemingly simple but actually very hard (time zones change with DST, there are many types, users think about them differently, and there is no globally unified organization method).Research data(qualitative: 13 people across 8 countries + quantitative: 83 people across 4 countries):
- 73% can accurately write their own time zone name (e.g., "Pacific Time"),18% use offsets (e.g., UTC-3) — therefore do not sort only by offset(Google Calendar/Slack sort by offset, a counterexample; most people do not understand what offsets mean).
- GMT is more familiar than UTC: 55% know their GMT offset, only 34% know their UTC offset (especially UK users).
- Search is almost a must-have: when search is disabled, almost everyone looks for the search box; on first search 44% use city names, 24% use time zone names.
- Grouping (by region/continent) allows faster location than pure offset sorting.
Design recommendations: ① Auto-detect the time zone and allow changes (or highlight and pin the user’s time zone to the top); ②Provide search(visible when active); ③Sort alphabetically by city name, with country/state + offset labeled beside; ④ Display in groups, pin major regions to the top, avoid sorting by offset; ⑤ For UK users, GMT can be used instead of UTC.
3.3 Four User Tasks for Data Tables (tablet/desktop-focused, but same principles apply to mobile)
Tables are more scalable and better for direct comparison than cards/modular displays (cards require the eyes to repeatedly reposition between cards, which is cognitively costly). Design around four core tasks:
| Task | Design key points |
|---|---|
| 1 Find records that meet criteria | Use readable identifiers(person names/record names) in the first column rather than auto-generated IDs; column order reflects importance, related columns are adjacent; filters are discoverable + fast + intuitive, and clearly indicate "this is filtered data" |
| 2 Compare data | Freeze header row + first column(with a drop shadow implying they float above the data), light borders,zebra striping to aid visual scanning; easy to hide/rearrange columns, clear status prompts (e.g., "15 columns hidden") |
| 3 View/edit/add a single record | For narrow tables use inline editing(edit state must look different to prevent misoperation);non-modal side panels are best (allow editing while viewing other data); modal popups that cover content are not recommended; accordions after expansion are often left uncollapsed by users, cluttering the interface |
| 4 Act on records | Place single-record action buttons inline (too many will crowd or hide under hover, reducing discoverability); for batch actions use checkboxes + "Select all" |
IV. Three States of System Status: Indicators vs Validations vs Notifications
"Visibility of system status" is one of the ten usability heuristics (see NNGroup Usability Testing and the Ten Usability Heuristics (complete table of 10 heuristics · complex application use · user delight hierarchy · testing methods 5-user rule/recruitment/remote/task scenarios/step-by-step tasks/attitude vs behavior/4-step analysis/small-sample errors/competitive evaluation)). But using the wrong communication method harms the experience. The three methods are distinguished along three dimensions:
| Indicators | Validations | Notifications | |
|---|---|---|---|
| Global vs contextual | Contextual | Contextual | Global or contextual |
| Passive vs requires action | Passive | Requires action | Requires action or passive |
| Triggered by | User action or system event | User action | System event |
| Implementation | Icon/font change/size animation | Red text + icon marking the erroneous field | Popups/banners/badges |
| Examples | Yelp red flame icon = hot new business; unread email badge; stock up/down arrows | Form prompt "Please enter your street address" | Order status updates, new messages, low battery, app updates |
How to choose: ① When the user needs to pay attention and act immediately(e.g., input error) → validation or "action-required notification"; ② When the information is only supplementary(dynamic data changes) → status indicator; ③Urgent system events→ notifications (prominent popups/banners).Core principle: Do not make passive information into interruptive notifications; do not make items requiring immediate handling into passive indicators that are easily ignored.Counterexample: Visual Comfort placed the "Added to cart" notification at the top of the page far from the "Add to cart" button, so users might not see it and add items repeatedly (Mango’s hybrid notification that occupies part of the screen is more reliable).
V. Error Messages: Scoring Rubric + Writing Guidelines
5.1 Error Messages Scoring Rubric
A quantifiable scoring tool (created by Tim Neusesser & Evan Sunwall):Three dimensions × 4 criteria each, each criterion scored 1–4, average score maps to A–D grades.
| Dimension | 4 criteria |
|---|---|
| Visibility | Display near the error source / use prominent, redundant, accessible markers (icons, borders, shadows) / style according to error impact / do not display too early |
| Communication | Human-readable language (no jargon) / describe the problem concisely and accurately / provide constructive suggestions / positive tone that does not blame the user |
| Efficiency | Prevent common errors / preserve user input / reduce error-correction cost / teach users to understand the system |
Grades: A (4.0–3.3 top tier)/ B (3.2–2.5 good)/ C (2.4–1.6 needs improvement)/ D (≤1.5 severe).Three real-world test cases: Craigslist 2.08(error message not near the field, does not describe the problem, clears input); Google Flights 3.17(good communication and efficiency but weak visibility, does not explain the cause); J.Crew 3.67(good across all dimensions, only misspelled Items as Item).Team usage: First align on the scoring rubric to eliminate ambiguity, have each member score independently to avoid groupthink, then take the average.
5.2 Error-Message Guidelines
Based on Nielsen usability heuristics:
- Visibility: Near the source of the problem;multi-channel redundancy(bold + high contrast + red text + border + icon; do not rely solely on color/animation — accessibility requirement); choose format by severity (toast for minor, modal for severe); do not report errors too early (high-error-rate interactions like passwords can use real-time inline validation, but do not report before the user finishes typing).
- Communication: Plain language, minimize error codes;concise and accurate but not overly precise(to avoid disconnecting from users’ mental models); give constructive suggestions;positive tone— do not use blaming words like "invalid/illegal/error"; using the system correctly is the developer’s responsibility, not the user’s fault;do not use humor(it feels inappropriate in high-frequency error scenarios).
- Efficiency: Proactively prevent errors (prompt before sending without attachments);preserve user input so they can edit instead of retyping; auto-suggest correct options (give candidates when "city and ZIP code do not match"); use hyperlinks to teach users but do not overuse them.
- For severe outages(server overload), novel/fun content can be used to ease frustration (e.g., ChatGPT uses entertainment + user education during downtime).
VI. Five Mistakes in Mobile Push Notifications
Push notifications are a powerful tool for re-engagement, but done poorly they lead directly to uninstalls (in 2016 users received 56 notifications per day on average). Two types of notifications: action-required vs passive. Five mistakes + fixes:
| # | Mistake | Fix / positive & negative examples |
|---|---|---|
| 1 | Requesting notification permission on first open | Trust is not yet established, leading to easy rejection.Provide value first, then request: The game Conquest waits until the user’s first level-up to request (FreePrints pops the request immediately on entry, a counterexample) |
| 2 | Not explaining what the notifications will contain | Vague requests lead to easy rejection.Clearly state content and value: Night Sky explains it will push "stargazing conditions, celestial rise times" (Tasty gives no explanation, a counterexample) |
| 3 | Sending many notifications in a short time | Annoys users into turning off notifications/uninstalling.Combine + improve quality: Instagram combines 11 likes into 1 notification; iOS 12 groups notifications by app (Wunderlist pushes a separate notification for every due task, a counterexample) |
| 4 | Sending irrelevant content | Push content relevant to the user: Reddit pushes hot posts from subreddits you subscribe to (Venmo pushing friend-to-friend transfers irrelevant to you = counterexample) |
| 5 | Difficult to dismiss notifications | Reduces trust.Provide convenient in-app notification settings: Elevate allows toggling per category in its settings page (The Economic Times forcing users to go to global phone settings = counterexample) |
7. Onboarding Guidance: Tutorials Are Largely Useless; Build Contextual Help Instead
Two sets of notes reached the same conclusion using experimental data:Don’t put blind faith in tutorials; build readily available contextual help.
Experiment on mobile tutorials(70 participants, 4 obscure iOS apps, split into "Mandatory Tutorial Group A" and "Skip Group B"):
| Metric | Tutorial Group A | Skip Group B | Conclusion |
|---|---|---|---|
| Task success rate | 91% | 94% | No significant difference (p=0.443) — 91% vs 94% success rate, users could complete tasks without reading the tutorial |
| Perceived difficulty (1 = hard, 7 = easy) | 4.92 | 5.49 | The skip group felt it was easier(p=0.047) — tutorials actually made the app feel more complex |
| Completion time | 93.49s | 85.17s | No significant difference (and this does not even count the time spent reading the tutorial) |
Why tutorials are ineffective(common flaw of Push Revelation): interrupts the current task, is timed out of alignment with users’ real needs, is easy to skip, hard to remember, and consumes mental effort.Solution — Pull Revelation / Contextual Help: Based on signals from user actions,provide help only when the user needs it(Figma only prompts about text rendering changes after the user adds a text box). Implementation key points: ① Easy to dismiss and easy to bring back up (Evernote keeps "What's New" in the sidebar); ② Use progressive disclosure (Photoshop shows a short animation on hover plus a "Learn more" link); ③ Align help for multi-step flows alongside the steps to reduce memory load; ④Skip the obvious(don’t explain that a gear icon means settings); reserve help for complex features; ⑤ The most important and hardest point —understand users’ usage paths, and rely on user research to judge when help is most likely needed.
Recommendation: Prioritize investing resources in optimizing the interface itself, do not force tutorials, keep tutorials short and skippable, and only provide guidance for truly complex/innovative interactions —tutorials are a supplementary measure, not a replacement for intuitive design as the primary approach.
8. Cross-Device and Physical-Digital Bridges: Responsive Content Dispersion, QR Codes, Smartwatches, Banner Blindness
8.1 The Negative Impact of Mobile-First on Desktop
Mobile traffic has exceeded 55%, and mobile-first has become mainstream — but directly scaling up mobile layouts to desktop causes Content Dispersion: content is stretched across large areas of white space, giant images, and large text; pages become longer, information density is low, and more scrolling is required. Three major causes: mobile-first, minimalism, and large-image design.13 qualitative usability tests comparing "dispersed vs condensed" prototypes found the following negative impacts:
- Increased interaction cost: Longer pages require excessive scrolling to find information; accordions on desktop actually increase clicks and reduce efficiency.
- Increased cognitive load: Content is broken up, forcing users to remember and compare across multiple viewports (condensing into a 2×2 grid allows same-screen comparison and is much better).
- Difficulty building a conceptual model + illusion of completeness: There is no cue at the bottom of the screen that "there is more content", so users mistakenly think they have reached the end and miss important content.
- Reduced trust: Users feel content is hidden and suspect the company is intentionally concealing information.
Positive exceptions(where dispersion can be used strategically): when users need to focus on complex content and understand it piece by piece; high-value large images (that actually let users see product details clearly).Recommendations: Evaluate whether desktop rendering is too dispersed, prioritize high-value images (use fewer purely decorative images), group key related content within the same viewport, and avoid forcing mobile-exclusive interactions (accordions) on desktop.
8.2 QR-Code Usability: 13 Usability Guidelines
Three major uses of QR codes: progressive disclosure (information beyond limited space), cross-channel transition (physical ↔ digital), and reducing printing. 13 guidelines (condensed):
- Tell users what it does and where it leads(the code itself has no informational cues, so pair it with a label/short URL; the unlabeled code on the bottom of a Yeti cup = counterexample); 2. When necessary,indicate which device/app to scan with; 3. Link to a mobile-friendly page(Papa Johns linking to a page that displays poorly on mobile = counterexample); 4. Deep link to the relevant page/action(KFC redirects to the App Store or Google Play based on system; the code on Nike shoe tongues redirecting to the generic homepage = counterexample); 5. Do not use a code when displaying and accessing on the same device(providing a direct link is more convenient); 6. Do not invert colors (light code on dark background); 7. Use for cross-device authentication(scanning a code on a TV/computer with a phone to log in, e.g., WhatsApp/smart TVs); 8. Progressively disclose additional details (avoid generic labels like "Learn more"); 9. Ensure linked information is up to date(expired links should redirect to updated pages; a 2019 flyer code still linking to an old page in 2023 = counterexample); 10. If scan exposure is <15 seconds, use a short URL instead(e.g., roadside billboards); 11. Do not rely solely on codes for high-frequency access (codes cannot be memorized); 12. Place them where users will notice them(Gestalt principle of proximity; Walmart self-checkout machines place codes on both the screen and the keypad); 13. Make them large enough(adjust based on scanning distance,minimum 2cm × 2cm). Security: Risks of phishing/malware/forgery — only scan codes from trusted sources, preview before tapping, and ensure HTTPS.
8.3 6 Types of Useful Smartwatch Interactions
Background: By 2020, approximately1 in 5 Americans owned a smartwatch/fitness tracker. From 11 participants' 200+ instances Six interaction patterns are summarized:
| Interaction Type | Meaning | Key Success Factors |
|---|---|---|
| Receiving | The watch pushes information to the user to get their attention | More welcome than on phones (silent and non-intrusive + worn on the body so hard to miss); must have sufficient information density (no need to check the phone),understandable in 2–3 seconds, personalized, and well-timed; Updates/Reminders/Feedback are welcome, Promotions are disliked as intrusive |
| Referencing | Users actively check always-available information (weather/heart rate/progress) | Keep it simple and only show the most important content, use visualizations (charts, progress bars), place frequently used information on the home screen, and allow personalization |
| Recording | Actively tracking events (exercise/water intake/sleep) | Contextual prompts (prompt to record when running is detected), accurate data, easy to launch (shortcuts/voice); value lies in long-term aggregation |
| Controlling | Starting/stopping/adjusting devices (music/door locks/temperature) | Prioritize displaying commonly used functions, sync with other devices (watch app lagging behind the phone = pain point) |
| Communicating | Sending and receiving messages/taking calls | Show as much content as possible when receiving,prioritize voice input for sending(typing on a watch is difficult) |
| Guiding | Real-time guidance during tasks (navigation/workouts/meditation) | Standalone (no need to frequently interact with the phone),haptic feedback(vibration to prompt turns), only show the current step |
Inefficient interaction types on watches(do not force them in): consumption (watching videos, reading articles), creation (even text input is difficult), browsing (users do not casually browse on watches), search (difficult input + small screen makes displaying results hard) — these should all be done back on the phone.
8.4 Banner Blindness
Users have learned to ignore content that looks like ads, is near ads, or appears in traditional ad positions— this is a form of selective attention (eye-tracking studies confirm users do not even look at ads at the top of search result pages). Three mechanisms:
- Location: Ignore top-of-page banners and right-side columns (traditional ad placements), even when legitimate content is placed there.
- Visual design: Visual characteristics of ad styles trigger skipping — small rectangles in the middle of text, fancy typography, colored background blocks on a white background, text embedded in images.
- Gestalt proximity + hot potato effect: Content near ads is guilt-by-association ignored as ads; after ignoring an area once, users continue to ignore similar positions on other pages/sites (Cascada users glanced at the right column and never looked at it again).
- On mobile: Smaller screens make ads harder to fully avoid (large ads are forced into view), but any element that differs greatly in style from its surroundings may be mistaken for an ad and swiped past (Generac users skipped a section containing installation information because it looked like an ad).
How to prevent ads from "poisoning" legitimate content: Don’t make important content look like ads (choose colors/fonts/backgrounds carefully); use usability testing to confirm key content is noticed even when placed in traditional ad zones; don’t mix content and ads in the same area.
Sourced from NNGroup Topics / Mobile & Tablet - Mobile Devices and Tablets (19 articles). Mobile overlays/navigation patterns are deeply complementary with NNGroup Interaction Patterns: Overlays, Scrolling, Mobile & Responsive (13 patterns · Accidental overlay dismissal/Bottom sheets/Coaching marks/Infinite scroll alternatives/Scroll position preservation/Scroll fade-out/Scroll hijacking/Cookie permissions/Mobile permission requests/Mobile onboarding/Responsive breakpoints/Mobile-first drawbacks/Task switching); for heuristic foundations such as system status visibility, error recovery, and recognition over recall, see NNGroup Usability Testing and the 10 Usability Heuristics (Full table of 10 heuristics · Complex application design · User pleasure hierarchy · Testing methods: 5-user rule/Recruitment/Remote testing/Task scenarios/Step-by-step tasks/Attitude vs behavior/4-step analysis/Small-sample error/Competitive evaluation); for tablet/cross-device (Split View, Handoff, iPad multitasking) and Apple official specifications, cross-reference with Apple HIG iPad & Mac Special Topics (Platform differences/Cursor/Navigation/Copywriting/Charts/Windows/Subscriptions/Dynamic components) / Flow patterns (Loading/Onboarding/Notifications/Feedback)Apple HIG Interaction Patterns (25 flow patterns · Onboarding/Input/Feedback/Media/System collaboration). Images/videos/original documents (including eye-tracking heatmaps, screenshots of various apps, craigslist/jcrew/pocket videos) are retained in sources.
Sources and Related Materials
- NNGroup Interaction Patterns: Overlays, Scrolling, Mobile & Responsive (13 patterns · Accidental overlay dismissal/Bottom sheets/Coaching marks/Infinite scroll alternatives/Scroll position preservation/Scroll fade-out/Scroll hijacking/Cookie permissions/Mobile permission requests/Mobile onboarding/Responsive breakpoints/Mobile-first drawbacks/Task switching)
- NNGroup Usability Testing and the 10 Usability Heuristics (Full table of 10 heuristics · Complex application design · User pleasure hierarchy · Testing methods: 5-user rule/Recruitment/Remote testing/Task scenarios/Step-by-step tasks/Attitude vs behavior/4-step analysis/Small-sample error/Competitive evaluation)
- Apple HIG iPad & Mac Special Topics (Platform differences/Cursor/Navigation/Copywriting/Charts/Windows/Subscriptions/Dynamic components)
- Apple HIG Interaction Patterns (25 flow patterns · Onboarding/Input/Feedback/Media/System collaboration)