Human-Computer Interaction (HCI) studies how "human hands, eyes, and brains" interface with "machine interfaces". These 16 articles can be read in three layers, ordered "from hard to soft, from established to emerging":
First layer · Hard laws of human physiology and cognition — These are physical/physiological rules measured by decades of experiments that barely change: how long it takes a finger to move to a target (Fitts's Law), how long it takes to drag along a narrow path (Steering Law), how thick fingertips are and therefore the minimum size buttons should be (1cm touch targets). It also covers well-honed "design processes" (iterative/parallel/competitive testing).This layer does not depend on human will; just follow it.
Second layer · Interface interaction patterns — Built on top of the hard laws, this covers how to get buttons, tables, help, and states right: how toggle buttons should display current state (state-switch controls), how to teach new users (tutorials vs contextual help), how to arrange complex data (data tables), how to study users before building (task analysis).
Third layer · New scenarios in the intelligent era — Smart homes, AI assistants, AR, online queuing. As devices become more "automatic", new problems arise: users cannot understand why devices change on their own (invisibility of automation), AI that acts too human is less trusted, AR requires calibration every time. This layer is the frontier of HCI.
The core principle running through the entire piece, in one sentence:Good interaction = making machines adapt to human bodies and brains, not forcing humans to adapt to machines.
1. Motor Laws: How long it takes a finger/cursor to reach a target
This section covers two laws that are "almost physics". They tell you how big buttons should be, where to place them, and how to arrange menus — this is not an aesthetic issue, it is a question of whether the hand can reach quickly and accurately.
1.1 Fitts's Law: Large targets + close distance = faster and more accurate
Intuition of the formula: Time to reach target T = a + b·log₂(D/W + 1). Three quantities:D = target distance(how far the cursor is from the target),W = target width along the movement direction(how large the target is), a/b are constants (depending on whether a mouse or finger is used). You do not need to memorize the formula, just remember two sentences:The farther the distance, the slower; the larger the target, the faster.
History: Paul Fitts was a psychologist who studied aircraft cockpits during World War II. He found that many accidents blamed on "human error" were actually design flaws — this is the origin of HCI shifting blame away from users. The two-phase movement model (Woodworth, late 19th century) explains why:First move rapidly toward the target direction (driven by distance), then decelerate to align precisely (driven by target size) — the smaller the target, the more time the second phase takes.
| Design levers | How to implement | Why / Counterexamples |
|---|---|---|
| Make targets larger | Add text labels to icons (to expand clickable area); make primary action buttons larger | Larger targets have lower error rates and faster clicks |
| Screen edges = infinite targets | Place high-frequency items at screen edges/corners (macOS top menu bar, Windows bottom taskbar) | The cursor stops when it hits the edge,users do not need to decelerate and will not "overshoot", equivalent to an infinitely large target |
| Do not place targets too densely | Leave sufficient spacing between adjacent targets | Too close → accidental taps on neighbors |
| Place targets close to the prior action | Place submit buttons at the very bottom of forms (adjacent to the last input field); place contextual menus tight against the icon that triggers them | Counterexample: Sephora places "Save" in the top-right corner, requiring fingers to travel a long distance from the last field; positive example: Taxa 4x35 places primary actions at the bottom of the form |
| Choose menu shapes with shorter distances | Average distance: linear menus > rectangular menus > pie menus (pie menu items are equidistant and optimal, but users are unfamiliar so they are rarely used); aligning linear menu handles to the middle can reduce average movement distance | Gmail iOS places ellipsis menu options in a bottom sheet, too far from the menu handle = counterexample |
Padded Target: A small visible target surrounded by a larger invisible active area.Pitfall: If users do not know the padding exists, they will still decelerate to aim at the visible area when approaching, eliminating the time-saving effect — padding is for "error tolerance", not "speed increase"; do not expect it to replace sufficiently large visible size.
1.2 Accot-Zhai Steering Law: How hard it is to move along a narrow path
Fitts's Law governs "pointing at a point",Steering Law governs "moving along a bounded path"(dragging sliders, moving through hierarchical menu corridors, pulling scrollbars). Formula T = a + b·(A/W):A = path length, W = path width. Core principle in one sentence:The narrower and longer the path, the harder and more time-consuming it is to traverse; hand tremors or device movement can easily cause crossing the boundary and triggering accidental actions.
| Scenarios | Problems | Optimizations (how to "widen the path") |
|---|---|---|
| Dropdown/hierarchical menus | On macOS, moving diagonally from "Find" to a submenu causes the cursor to cross the "Spelling and Grammar" area → losing the target and opening the wrong menu (the famous L-shaped narrow corridor problem) | ① Increase vertical/horizontal spacing between menu items = widen the path ② Activate submenus only after a mouse hover delay(to prevent accidental triggers) ③Vector triangle buffer zones(allowing diagonal movement; designed by Bruce Tognazzini for older macOS versions, later removed by Apple) ④ Switch to Mega Menu Mega Menu panels (free two-dimensional movement; Steering Law does not apply, but Fitts constraints still require sufficiently large targets) |
| Avoid deep hierarchy | Menus with more than two levels = paths that are long, narrow, and turning, extremely easy to interrupt | Keep to two levels or fewer whenever possible |
| Sliders/scrollbars/progress bars | Narrow tracks require precise dragging, especially hard on touchscreens | ① Pair with numeric input boxes or fine-tuning buttons for precision adjustment ② Support direct clicks anywhere on the track to jump(not just dragging) ③ Touchscreen slider handles ≥1cm×1cm, do not obscure labels |
Overarching principle across both laws — "Be Generous in design": Add a ring of invisible buffer zones outside visual boundaries, so users do not fail if they deviate slightly from the path (the active area of slider tracks is wider than visible, submenu trigger areas are larger than their borders). In essence, use invisible error tolerance to compensate for the physical fact that human hands are unsteady.
1.3 Touch Targets: How thick are fingertips really
This is the concrete application of Fitts's Law on touchscreens — because the input device changes from a "precise mouse pointer" to "fat fingers", size becomes a hard constraint.
Key numbers (memorize these): Minimum size for interactive elements 1cm × 1cm(0.4in × 0.4in). Average finger width 1.6–2cm, thumb reach range up to 2.5cm. For targets smaller than 1cm, per Fitts's Law tap time increases sharply and accidental tap rates are high.
| Four categories of pitfalls | Manifestations / Counterexamples | Solutions |
|---|---|---|
| Too small size | Glow Baby's visual bars for short feeding/sleep events are only 6mm×1mm, requiring multiple taps to hit | Hold the 1cm bottom line |
| Too tight spacing (Crowding) | McDonald's map markers are too dense; Kate Spade links are too close causing accidental taps (contrast with White House Black Market's sufficient spacing); Instagram follow suggestions' "×" is only 2mm | Leave sufficient gaps between targets; even without mistaps, crowding feels unusable |
| View-Tap Asymmetry | "Visible but not tappable accurately" — David Yurman's color-selection small dots are only 1mm in diameter, causing accidental taps into detail pages; carousel dots have the same problem.Root cause is often desktop designs not adapted to be touchscreen-friendly | Visible ≠ tappable; tap areas must be separately enlarged to match finger dimensions |
| Too small when large targets are needed | —— | Make primary actions large (Target App search/scan buttons 2cm×2cm);special populations require even larger targets: children (fine motor skills not fully developed), older adults (hand tremors), new parents (one-handed operation while holding a baby); Glow Baby's nursing timer main buttons are 2.3cm and spaced far apart |
Counterintuitive fact about screen size: Large screens require larger targets (for visibility); small screens should not shrink targets — if space is insufficient, use gestures or voice instead of shrinking buttons until they are untappable.
1.4 Three high-usability design processes: Not getting it right the first time, but iterating toward it
There is no perfect interface in one draft. The three processes below each independently improve usability; used in combination they explore more possibilities for less cost.
| Process | Method | Measured improvement / Limitations |
|---|---|---|
| Iterative design | Initial draft → user testing → fix issues → new version → test again, linear cycle | Average +38% usability improvement per round; do at least 2 rounds (initial draft + 2 iterations), 5–10 rounds if possible.Limitation = "hill-climbing phenomenon": only optimizing a single solution may miss another higher hill |
| Parallel design | Create 3–5 alternatives simultaneously → test 2–3 with each user → merge the strengths of each into one | Selecting the best alternative and iterating gives +56%; merging the best elements of all alternatives +70%; iterating once more after merging +152%(highest) |
| Competitive testing | Test your own design alongside 3–4 competitor products, distill strengths and weaknesses | Save resources (use existing designs); the goal is not to find a "winner", but to observe user behavior to steal ideas and discover unmet opportunities |
Optimal combination: First competitive testing to map out user needs and market status → Then parallel design to explore multiple solutions → Finally iterative design to polish the chosen direction. Combining all three escapes the single-minded "hill climbing" trap.
II. States, Feedback, and Controls: Let users know "what state we are in" at all times
2.1 State-Switch Controls: The infamous "mute" button
A toggle button must convey two pieces of information:what the current state is(is it currently muted?) and what will happen when pressed(will pressing unmute it?). Mixing both on one button is the root cause of countless "mute/unmute" failures.
| Design approach | How to implement | When to use / Examples |
|---|---|---|
| Dual controls(state indicator + toggle button) | One UI element shows the current state, the other shows the post-toggle state, each responsible for one piece of information | First choice when the state is ambiguous, there are no external cues, and users need to judge quickly. Tesla: lock icon shows "locked" + "unlock" button shows post-press state, updated synchronously |
| Single control(button displays both states) | Relies on user inference. Three variants: ① Label shows post-toggle state (OBS "Start Recording" changes to "Stop Recording" when pressed) ② Button visuals show current state (Word "Bold" shows a shadow when pressed) | Usable when the state itself is sufficiently clear |
Counterexample WebEx: Red is used both for "mute" and arbitrarily for "leave meeting" (color has no consistent meaning); the icon is identical for muted/unmuted; forcing users to memorize color meanings and infer states = cognitive load.Positive example Zoom: Icon shows current state (microphone with slash = muted) + label shows post-toggle state (shows "Unmute"),dual information from icon + label reduces cognitive load.
Three self-check questions: Is the state clear? (if not → use dual controls) Are there external cues? (if not → the control must clearly state the current state on its own) Do users need to judge quickly? (if yes → provide a clear indicator + toggle button)?
2.2 States and feedback for smart device apps (applying the previous section's principles to invisible devices)
Special difficulties of smart devices:You can't tell a camera is working and monitoring you just by looking at it, so the app must explicitly communicate the state. These 7 practices are essentially "state visibility + feedback + reducing repetitive work".
| # | Practice | Key points / Counterexamples |
|---|---|---|
| 1 | Naming and categorization | Multiple devices are quickly identified by naming (by room); it can even add fun (users name a light "Moonlight Goddess") |
| 2 | State visible at a glance | See the current state of all devices (light switches, door locks) immediately upon entering the app, with one-tap operation; highlight this on both the overview page and detail pages |
| 3 | Triple cues of color + icon + text | Redundant design prevents misunderstanding and aids accessibility (red = unlocked + lock icon + "Locked" text); a single signal is easily ambiguous |
| 4 | Task progress visible | Time-consuming tasks show remaining time ("45 minutes remaining")/percentage/animation (robot vacuum shows where it has cleaned); send a notification on completion |
| 5 | Shortcuts for repetitive tasks | Save common tasks ("Vacuum living room + dining room" for one-tap reuse), quick actions on the home page, batch editing (turn off all house lights with one tap) |
| 6 | Immediate and sufficient feedback | Show processing state immediately on tap; state both success and failure with reasons. Counterexample: no feedback after changing a schedule, leaving users extremely frustrated because they "don't know if the change succeeded" |
| 7 | Manage other control channels | The app acts as the settings hub for all control methods: voice assistants (Alexa/Siri), physical button customization, child lock,cross-channel synchronization(names changed in the app sync to voice and physical controls) |
III. Instruction, Research, and Data Presentation
3.1 Onboarding tutorials vs contextual help: Push vs pull
| Dimension | Tutorials (push) | Contextual Help (pull) |
|---|---|---|
| Trigger | Pops up proactively at app launch or random times | Provided only when the user performs an action and truly needs it |
| Problems | Interrupts tasks(users are forced to watch when they are eager to work),relies on short-term memory(must remember after reading to use later, heavy cognitive load),easily forgotten, plus requires an extra tap to close | Highly targeted, non-intrusive |
| Counterexamples | Gates Carbon Drive (drops users straight to the main interface after the tutorial, no follow-up guidance); Chase Bank (pops up a stack of new feature cards on login, no context); "new feature" popups in productivity tools (ignored when busy, impossible to find when actually needed) | —— |
| Positive examples | ArcGIS:Require users to do hands-on actions rather than just watch, and do not auto-pop up on first login, placed in the sidebar for revisiting anytime | Figma (shows help for the text tool only when you open it); Photoshop (hover shows animated demo + "Learn more" progressive disclosure) |
Four principles of contextual help: ① Easy to dismiss and revisit (Evernote's permanent "New Features" list) ②Avoid memory burden—— present multi-step flows incrementally, with guidance for each step ③Omit the obvious(don't explain that a gear = settings, only cover complex/unique features) ④Understand the user journey—— use user research + task analysis to locate "the moments when help is most likely needed", which is the core and hardest step.Mental model: Tutorials are not cost-effective in most scenarios; contextual help is the more natural and efficient default.
3.2 Task Analysis: Study how users work before you start designing
First distinguish three concepts:
- Goal = The end result the user wants (build a retirement fund) — abstract, high-level.
- Task = Specific activities performed to reach the goal (search for information, consult an advisor, fill out an application form) —observable, with clear start and end.
- Task analysis ≠ workflow analysis (studies shared organizational goals across multiple users) ≠ job analysis (long-term study of one employee's job requirements).Task analysis focuses solely on the sequence of tasks a single user performs for a single goal.
Two phases:
- Phase 1 · Information gathering: Contextual Inquiry (on-site observation + semi-structured interviews), critical incident interviews, record keeping, activity sampling (record frequency and duration), simulation.Key point: Don't trust only user self-reports; combine with on-site observation.
- Phase 2 · Analyze tasks: Use Hierarchical Task Analysis (HTA) diagrams to break the goal into main tasks + subtasks (e.g., scan a letter = download software → launch → scan → save).
Five evaluation dimensions: Total task volume (can it be simplified?), frequency (which are high-frequency/repetitive?),cognitive complexity(high mental load → error-prone), physical demands (burden on users with physical/disability needs), completion time (estimate via activity sampling or GOMS theoretical modeling).Value: Upgrade from "solving a problem" to "correctly solving the user's real problem".
3.3 Data Tables: Four core user tasks
Tables vs cards:Cards require spatial reorientation and reliance on short-term memory for every comparison, which is cognitively effortful; adjacent data in tables is naturally easy to compare and scalable. Tables are not aesthetically pleasing but highly functional, practical for work scenarios.
| User task | Design recommendations |
|---|---|
| ① Find records that meet criteria | Use human-readable identifiers in the first column (don't use auto-generated IDs); place related columns adjacent (reduce eye movement); make filters discoverable, transparent, and clearly show the current filter state |
| ② Compare data (find relationships, anomalies, ranges horizontally/vertically) | Freeze header row + first column(maintain visual orientation, drop shadow implies "floating above"); light borders/zebra striping/hover highlighting aid scanning; allow hiding/reordering columns (and clearly mark hidden status, e.g., "15 columns hidden") |
| ③ View/edit/add a single row | In-place editing(for narrow tables, must clearly mark editable state);modal popups obscure other data → not recommended for deep editing;Non-modal side panel = recommended(edit a single row while viewing the full table); accordion expansion (does not obscure but easily becomes messy, hard to reference non-adjacent records) |
| ④ Perform actions on records | Single record: inline within the row if few actions, collapsed into a menu if many; batch: checkbox selection + action menu at top/bottom of table + select-all shortcut |
Two reordering methods: Drag column headers directly (low discoverability, poor accessibility, but an efficient accelerator once learned) or drag from a visible column list menu.
IV. Smart Homes: The more automated devices become, the more new problems arise
4.1 What users truly value: Five core motivations
Whether a smart home is "worth it" depends on only five things — convenience, peace of mind, saving money, useful data, and ambiance. Long-term value does not come from novel features,it comes from fitting into daily life; if it doesn't fit in, it will be forgotten once the novelty wears off.
| Motivation | Truth | Design implications / Counterexamples |
|---|---|---|
| Convenience | True convenience is not single operations, it is delegation of repetitive daily routines(scheduling, automation); this is especially true for ADHD users ("takes the burden of remembering to do things off the brain") | —— |
| Peace of Mind | The value is not anti-theft, it is being able to "confirm everything is okay" when away from home, reducing anxiety about the unknown | As long as users can quickly know what is happening and whether they need to intervene, they feel it is reliable |
| Saving | Most people do this to control energy costs rather than out of environmental ideals; they treat smart features as a replacement for expensive hardware upgrades, to "squeeze maximum efficiency out of existing devices" | Smart water heater schedules: users are willing to configure them because the tradeoff between money and comfort is visible |
| Useful Data | Data must be understandable and actionable | Positive example: smart litter box clearly flags pet anomalies → directly triggers a vet visit; Counterexample: energy app with complex bar charts, users don't know if values are normal → abandon it |
| Ambiance | Some users adjust lights/music for mood rather than efficiency, combining multiple devices into a single "state" | The goal of a color wheel interface is to "quickly enter a certain feeling", not to "tune parameters" |
Four design recommendations: ①Flexible, forgiving schedules(can be paused/skipped/tweaked anytime, rather than set once and never touched — rigidity is the top reason automation is abandoned) ②Actionable notifications(three things: what happened, why it matters, what to do next) ③Analysis depth matches device role(light bulbs/outlets need to be "fast, stable, and easy to use", not historical reports; energy/health/environment devices warrant trend comparisons and anomaly detection, and give conclusions before details).
4.2 Beyond the primary user: 3 user types + Zone × Role dual axis
Nearly half of US households and about 80% of UK adults own smart devices. Research debunks a traditional UX assumption:"whoever is next to the device has control" — wrong. Proximity does not equal control.
Two device types: Shared devices (kitchen robot vacuum, usable by the whole family) vs restricted devices (living room door lock, controlled only by adults).
| User type | Characteristics | Pain points |
|---|---|---|
| Device Manager | Tech-savvy, responsible for installation and maintenance, prefers using the device's native app; is the purchase driver + family "tech consultant" | Fragmented control(switching between multiple apps),overburdened(fixes technical issues while meeting the whole family's demands);often executes actions for others, not the decision-maker |
| Everyday User | Only uses basic features, prefers voice/physical buttons/central systems (Google Home), dislikes complex apps | Unclear automation(temperature suddenly changes with no explanation),dependent on the manager(has to ask for help when forced to use the app) |
| Restricted User | Children/guests, almost no control rights | No control, excluded from the experience, equally confused about why devices change |
Five design insights(the section with the most product value in this piece):
- Agency—— the person actually operating the device is often not the decision-maker (child says "too bright", mom adjusts the light). Products must recognize that the "executor" ≠ the "decision-maker", and usability testing must recruit executing users. Mechanism:Delegation Request—— child says "turn down the temperature" → system identifies them as a restricted user → does not adjust directly → pushes to parent's phone "Child requests 27°C→25°C, allow?"
- Zone × Role dual-axis model—— overlay device location (shared/private zones) with the three roles to explain behavior; set safe defaults by Zone (26°C neutral in living room, sleep guard in child's room, soft breeze low noise in elder's room).
- Invisibility of automation—— users' biggest pain point is "not knowing why devices changed automatically".All systems with automatic logic must provide visible explanations + intervention points: visualize automation layers ("Will switch back to sleep mode in 5 minutes (source: baby's sleep preference)" + buttons "Keep my 25°C setting"/"Turn off temporarily for 2 hours"/"View rules"); upfront preview cards ("Next automation: adjust to 25°C at 22:30") that can be modified/delayed/skipped.
- Structured household rules—— turn messy verbal rules into visible, collaborative ones. Three-step rule wizard: select type → select affected people (roles) → select affected rooms (Zones), auto-generate "22:00–7:00 child's room 25°C, manual adjustment disabled, low fan speed".
- Smart things must also be able to do Dumb Work——Critical operations must not depend on the app, account, or network.Core of the degradation strategy:When Wi-Fi drops, lights can still be controlled via physical switches, door locks can still be opened with keys, and air conditioners can still be operated via physical buttons.
4.3 5 Guidelines for Onboarding Connection: Treat "Reconnection" as "First-Time Connection"
- Clear, visual, step-by-step guidance(using myQ smart garage door as an example): use images/animations to show button positions and light changes, paired with concise text;One task at a time(to reduce cognitive load), explain device feedback (whether it will beep/flash lights), include a progress bar + time estimate ("This may take one minute"), provide help access at each step ("Didn't hear the beep?"), and end with personalized naming for easy recognition.
- Treat "reconnection" as "first-time connection"——Disconnections caused by power outages, network drops, or updates are not uncommon, and most users forget how to reconnect. Automatically detect disconnections and send reminders,reuse the detailed visual steps from first-time onboarding, provide clear status feedback, and show real-time progress (Smart Life is a positive example).
- Support flexible device management——Allow quick removal, renaming, room categorization, with changes reflected immediately (deleted items disappear right away).
- Truthful and clear progress prompts——Fake progress bars are a major problem area:A progress bar that appears almost full before failing makes users think they are nearly done (Smart Life loading for over two minutes before ultimately failing = negative example). Provide estimated duration, explain the current status ("Connecting to WiFi"), and do not pretend everything is going smoothly.
- Handle errors transparently——Don't just say "An error occurred"; instead say "Unable to connect to WiFi" + provide solutions + include a built-in support entry + offer a "Retry" option (to avoid starting over from scratch).
4.4 Smart Notifications: 3 Types × 7 Principles
NN/g derived these findings from a2-week Diary Study.Three types:
| Type | Meaning | Example | Recommended channel |
|---|---|---|---|
| Reactive | Just happened, requires immediate response | Person detected at the door, laundry cycle complete | Push / SMS (most urgent, most prominent visual and audio alert) |
| Proactive | About to happen, prepare in advance | Filter needs replacement in 5 days, low battery | Push / In-app (noticeable but does not interrupt the current task) |
| Optimization | Optimization suggestions, not urgent | Shift schedule back 30 minutes to save $10 per month (Google Nest) | In-app / Email (minimize disturbance, no marketing feel) |
Channel characteristics:Push (sound + vibration, for urgent matters), In-app (for non-urgent matters), Email (persistent record,often ignored), SMS (conspicuous, for severe alerts), device-side lights and sounds (for when the user is nearby).Research found that Email is often ignored, while Push is more likely to be handled promptly; channels must match the notification type.
7 principles(Timely/Relevant/Specific/Intensity/Frequency/Channel/Adaptable):
| Principle | Key points | Negative example |
|---|---|---|
| ① Timely | Reactive notifications must be real-time; for Proactive notifications, lead time depends on task complexity (5 minutes before laundry finishes, several days before filter replacement); Optimization notifications should be sent when contextually relevant (e.g., suggest energy savings during high electricity prices) | Robot vacuum got stuck under the bed, but the app status "caught up" and sent a delayed push, leaving users asking "How long ago did this happen?" |
| ② Relevant | Irrelevant notifications cause notification fatigue; notifications should automatically disappear after the issue is resolved (filter replacement reminder disappears after filter is changed) | Security camera sent 99 alerts in one night due to spider webs; low-battery alert persisted after battery was replaced → device appeared unreliable |
| ③ Specific | Answer three questions: what happened, what needs to be done, and when. "Filter expires in 5 days" is better than "Motion detected" | Robot vacuum said "Accessory missing", but it was unclear which accessory was missing or how to replace it |
| ④ Intensity matching | Visual cues (color, font) + audio cues (volume, vibration) should be tiered as "immediate/later/reference". Nest Protect smoke alarm = red flash + voice alert; maintenance reminder = yellow light | A user in their 70s missed a refrigerator filter replacement: both the small fridge light and app prompt were too inconspicuous |
| ⑤ Frequency | Prevent "cry wolf" fatigue: discrete events can trigger a notification each time, while persistent states should use time thresholds to limit frequency (e.g., alert only when humidity >50% for 10 consecutive minutes, alert for anomalies hourly) | Humidity reminder sent every 30 seconds, annoying the user so much they turned it off directly |
| ⑥ Channel | See matching for the three types in the table above | —— |
| ⑦ Adaptable | Adjustable based on context (e.g., turn off motion detection while mowing the lawn); provide "Remind me later/Remind me again" for all types (e.g., user receives a fault alert while out and cannot address it immediately) | —— |
4.5 Prioritize Displaying "Intelligence" over "Emotion": Winning Trust in AI
Counterintuitive but supported by data:In fact/task-oriented scenarios, AI that appears "smart" is trusted more than AI that appears "human-like". Emphasizing emotion actually reduces perceived reliability.
Study(three steps): questionnaire measuring how smart/emotional users perceived ChatGPT to be → 40 demographic questions (with optional choice to follow AI advice, which was actually preset answers) → trust score.Findings:Perceived intelligence ↑ → trust ↑ (positive correlation); perceived emotionality ↑ → trust ↓ (negative correlation). Users trust AI that is "good at handling facts" more than virtual entities that "might be swayed by emotions".
Risks of emotional AI (additional research): Overly warm/sympathetic AI increases error rates by 10%–30%; accuracy drops just by changing prompts12%–14%; it is more likely to give misinformation, spread conspiracy theories, and provide dangerous medical advice.In high-stakes scenarios (such as mental health), being too human-like is more dangerous: it over-accommodates emotions, supports incorrect thoughts, and fails to handle psychological crises properly.
Clarification: Professional ≠ Cold——It is acceptable to respond to user emotions (e.g., saying "I understand" about a late delivery) without showing that the AI itself has emotions; it is acceptable to use "I/my" as conversational pronouns (which does not imply self-awareness); tone can be friendly but "professional and polite" rather than "emotionally resonant".
UX recommendations: ① Present truthfully (avoid human names/fake avatars, frame as "intelligent tool" not "friend" in marketing) ② Clearly state capabilities/limitations (focus on small, refined functions) ③ Reinforce professionalism in system prompts (reward accuracy, neutrality, reliability; do not encourage emotional language) ④Cite real sources (RAG Retrieval-Augmented Generation, display data sources to increase credibility) ⑤ Recruit carefully for user research (do not recruit people who habitually treat AI as a companion tool, as this will contaminate feedback for work-oriented AI).
V. Other Emerging Scenarios: Virtual Queues and AR Calibration
5.1 Virtual Queues: 13 Practices for Managing Waits
Online queuing (to prevent server overload: course registration, ticket grabbing) has a long history; offline virtual queuing (theme parks, restaurants, clinics) is a post-COVID emerging trend to maintain social distancing. The 13 practices are divided into two segments: "before entering the queue / while in the queue":
Before entering/just entering the queue: ① Explain the purpose and necessity of queuing (tax portal "due to high demand"; Attractions.io "for safety") ② Clearly instruct how to join (offline use signs/QR codes/phone numbers; Delaware DMV placed signs at parking lot entrances) ③ Explain why the queue is closed (Disney displayed "Not Boarding" without explaining why = room for improvement) ④ Announce opening times to allow advance preparation (Disney "starts at 7:00" + confirm companions in advance; Ticketmaster "waiting room" automatically enters queue when sales start) ⑤ State prerequisites (bring return receipts, height requirements — Disney displayed height requirements but with insufficient visual weight, making them easy to miss).
While in the queue: ⑥Display wait details in an easy-to-understand way(current position + estimated wait, paired with progress bar; Volcano Bay wearable devices show minute-level countdowns; piano-keyboard-style status trackers; negative example Lush had no status tracker, making it hard for users to track progress on their own) ⑦Automatic refresh(do not make users refresh manually; add a last-updated timestamp to increase trust; Aldi is a positive example, Disney requires manual refresh = negative example but has a banner explaining this) ⑧ Provide notification options (SMS/email/push, so users can step away temporarily) ⑨Clearly state consequences of exiting the page(Hunkemöller "closing the page does not lose your place" = good; Harvey Nichols "leaving loses your place"; Ticketmaster "queue reminder" prevents accidental loss of place) ⑩ Convenient re-access (one-click return from homepage; pediatric emergency homepage shows pending visits) ⑪ Prepare users in advance for when "it's your turn" (Disney "What's next?" informs users to arrive within one hour of notification; Universal "arrive by 4:13") ⑫ Notify users of important dynamic changes (if an item is sold out, don't make people wait for nothing) ⑬ Entertain users without disrupting their main task (online music festival queue plays related songs).
Core principle: A good queuing system allows users to freely do other things while waiting, with core elements being transparency (position/time) + automation (no manual refresh needed) + ability to leave (without losing place) + availability of notifications.
5.2 Augmented-Reality Calibration: 10 Guidelines
First understand calibration: Augmented Reality (AR) overlays virtual objects onto the real world; software needs to "calibrate" to determine the relative size/color/position of virtual and real objects for proper alignment.Unlike "onboarding (done only once)", calibration usually needs to be redone every time an AR feature is used. There are four calibration modes: scanning (scanning textured surfaces such as floors/walls), absolute positioning (affixed to walls/aligned with landmarks), relative positioning (fixed to ground/waist height then moved, common in AR fitness games), and no calibration required (AR try-on such as Warby Parker, AR filters such as TikTok, which only require adequate lighting).Iron rule: Although "reducing instructions" is generally a good practice, calibration is an exception — clear instructions + feedback are critical to success.
Calibration consists of two parts =operational instructions + feedback mechanism:
| Operational Instructions | Key points / Negative examples |
|---|---|
| Step-by-step low granularity | One step at a time; negative example ARvid displayed three instructions simultaneously, leaving users unsure which to do first and causing them to abandon |
| Clear, specific descriptive language | "Move slowly from one side to the other" must specify speed and trajectory; negative example Civilization AR asked users to scan a textured surface but provided insufficient explanation, so users aimed at chair back texture without knowing why it failed |
| Provide visual examples when necessary | Mission to Mars used comparison images to show good/bad lighting and surfaces |
| Allow sufficient time to read and execute | Do not let instructions disappear too quickly |
| Visually prominent | Place in screen center, use high-contrast dark background (MauAR used black background for narrative text, but its UI labels "Story" "1961" should also have this; Kinfolk used conspicuous colors but still lacked a contrasting background) |
| Visual instructions consistent with text | Negative example Active Arcade showed the device at waist-height table level in illustrations but told users to place it on the ground in text, creating self-contradiction; Smartify animation speed and direction misled users into making fast circular motions |
| Consider audio prompts | Can be used when the device is far from the user, but do not force audio playback |
| Feedback Mechanism — echoes Heuristic #1 "Visibility of System Status" | Key points / Negative examples |
|---|---|
| Keep system status transparent | Users often cannot tell if the system is computing or stuck (Civilization AR "It recognized the chair, but I don't know what it's doing") |
| Clear, standardized status indicators | Avoid ambiguous symbols; negative example Target/Etsy used floating dots/scatter points to indicate scanning, users could not understand what the yellow dots meant → abandoned |
| Ensure virtual objects load within the field of view | Negative example ARLOOPA character moved behind the user and was mistaken for having disappeared; use arrows/animations to guide when objects move (MauAR used arrows to prompt users to turn around = good; Civilization dashed lines were not intuitive enough) |
| Give clear feedback for user actions | When errors occur, state the cause (insufficient light/unsuitable surface) + correction suggestions ("Scan in a brighter area" "Hold device parallel to the ground"); negative example Etsy provided no cause feedback when scanning an empty wall failed, leading users to try repeatedly until abandoning |
Sourced from NNGroup Topics / Human-Computer Interaction (16 articles). Cross-reference NNGroup Usability Testing and the 10 Usability Heuristics (complete table of 10 heuristics · complex application implementation · 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 errors/competitive evaluation)(the 10 heuristics including visibility of system status/error prevention/recognition over recall; state switching, feedback, AR feedback, and table design in this article are practical implementations of these),Apple HIG Interaction Patterns (25 flow patterns · onboarding/input/feedback/media/system collaboration)(interaction flow patterns such as Onboarding/Feedback/Drag and Drop/Search, which complement the tutorial vs contextual help and smart device feedback covered in this article),Apple HIG Component Decision Manual (63 Components · When to Use Which)(Component-level specifications for touch target size). Images/videos/original documents are retained in sources.
Sources and Related Materials
- NNGroup Usability Testing and the Ten Usability Heuristics (Complete Table of 10 Heuristics · Complex Application Implementation · User Pleasure Hierarchy · Testing Methods 5-User Rule/Recruitment/Remote/Task Scenarios/Step-by-Step Tasks/Attitude vs Behavior/4-Step Analysis/Small Sample Bias/Competitive Evaluation)
- Apple HIG Interaction Patterns (25 Process Patterns · Onboarding/Input/Feedback/Media/System Collaboration)
- Apple HIG Component Decision Manual (63 Components · When to Use Which)