1) Investigation framework and data quality The product is a fictional responsive web prototype for private checklists. The audience is English-speaking US freelance graphic designers managing three to six client projects, with basic web skills and visiting on mobile for the first time. Activation: the first private checklist is successfully saved and visible in the user’s own list. Access confirmation alone is not activation. Immutable constraints: retain the authentication provider, verification requirements, role access, and protective controls. No payment changes, authentication replacement, or use of actual credentials, codes, or user records. Evidence status Available information Observation Described flow; email magic link valid for 10 minutes; optional display name; creation from an existing sample Observation Invalid input receives a generic error; expired link displays “Error” without a next action Evidence limitation Fictional copy inspection only; no screenshots, implementation inspection, or behavioral evidence Missing metrics Step counts, completion times, authentication errors, recovery outcomes, save failures, and activation rates Missing behavior Loading, retries, account routing, recovery, rate limiting, lockout, session expiry, and connection recovery Contradictions None identified Process boundary: entry → magic-link authentication and verification → recovery where needed → setup → sample-based checklist creation → successful save and visibility. Subsequent checklist use is outside scope. No conversion losses can be quantified from the supplied evidence. 2) Access state model “Not documented” means behavior is unknown, not necessarily absent. Step User goal Input or action System state Feedback Next state Possible exit Entry Obtain access Enter email and request link Email entry Entry copy not documented Link request Leave page Empty input Understand required input Submit blank email Not documented Not documented Not documented Abandon Invalid input Correct email Submit invalid input Validation failure Generic error Correction behavior not documented Abandon Link request Know whether request completed Submit valid email Loading and delivery states not documented Indicator and retry control not documented Email link Leave or repeat request Existing account Access prior account Submit associated email Account routing not documented Not documented Not documented Not documented Verification Confirm access Open valid link within 10 minutes Access confirmed Confirmation wording not documented Setup Leave Expired link Regain access Open link after expiry Expired verification link “Error”; no next action Recovery not documented Abandon Failed connection Continue safely Request link, verify, or save during connection failure Not documented Not documented Not documented Leave or repeat action Locked access Understand restriction Attempt access while restricted Lockout behavior not documented Not documented Not documented Not documented Recovery Restore access Recovery action not documented Not documented Not documented Successful recovery not documented Not documented Setup Reach checklist creation Submit form, optionally supplying display name One-page setup Validation and submission feedback not documented Sample-based creation Leave Checklist creation Create useful private checklist Use existing sample Creation and save states not documented Not documented Save Leave Activation Confirm checklist exists Save checklist Saved checklist visible in own list Checklist visibility documented; other feedback unknown Activated Leave after success The described magic-link verification belongs to authentication. Setup is onboarding. No separate password, multi-factor, or account-recovery flow is documented. 3) Friction and trust diagnosis Confidence concerns the diagnosis, not the size of any conversion effect. Dimension Affected step Observable evidence Probable cause / hypothesis Impact and affected group Confidence Understandability Invalid email Generic error Validation copy does not identify the correction needed Users entering invalid email may struggle to correct it High for copy limitation; impact unmeasured Effort Setup A form precedes checklist creation; display name is optional Hypothesis: submitting an optional-only form adds avoidable effort First-time users; actual burden unknown Low Orientation Expired link “Error” without next action Expiry state lacks actionable explanation Affected users receive no stated route forward High Fault tolerance Link recovery Recovery and retry behavior not documented Cannot determine whether users can resume Users with expired links or interrupted requests Unknown Trust Expired link Unexplained failure Hypothesis: users may interpret expiry as a product failure Users opening delayed email Low for psychological effect Accessibility Authentication and setup No visual or interaction evidence Cannot assess labels, focus, announcements, or touch controls Keyboard and assistive-technology users Unknown Technical robustness Requests and save Loading and connection recovery not documented Cannot assess pending, failed, or uncertain outcomes Users experiencing slow or interrupted connections Unknown Keep: verification requirements, private checklist scope, role access, optional display name, the existing sample, and activation defined by a saved and visible checklist. 4) Security and recovery check Invalid email: explain local format errors without revealing whether an account exists. Suggested copy: “Enter an email address in the format name@example.com.” Expired link: replace “Error” with “This sign-in link has expired. Links are valid for 10 minutes.” Offer a fresh-link request only through a supported provider path. Account existence: delivery responses and new/existing-account routing are not documented. Review them before changing server-derived messages; local format validation does not require account disclosure. Retries, rate limiting, and lockout: not documented. Any resend control must respect existing restrictions and communicate the permitted next action. Session expiry and device change: not documented. Determine provider behavior before specifying recovery or cross-device continuation. Successful recovery: verify that a supported fresh link restores authorized access and leads to the appropriate next step without bypassing verification. No protective control should be weakened. Use synthetic test fixtures; do not collect actual links, codes, credentials, or user records. 5) Activation onboarding Step Necessity before activation Recommendation Email verification Required by the stated constraints Retain Access confirmation Communicates authentication success Clearly identify checklist creation as the next action Optional display name No core-function dependency supplied Verify dependencies; if none, defer until after activation Create from sample Supports the described first outcome Retain Save and show in own list Defines activation Retain and verify both persistence and visibility Recommended minimal path: entry → request magic link → verify access → create private checklist from sample → save → show checklist in own list. Deferred: optional display name, provided implementation inspection confirms no dependency. No other fields, decisions, or permissions were described, so none can be labeled unnecessary. 6) Prioritized actions Priority reflects evidence, expected impact, affected users, effort, and risk. Reach and impact remain unmeasured. Problem Concrete change Expected mechanism Affected state Security/privacy risk Effort Evidence strength Priority Expiry gives no direction Explain expiry and add supported fresh-link route Makes recovery action explicit Expired link Low if provider restrictions remain intact Small copy change; recovery effort depends on provider Direct copy evidence P1 Invalid input is unclear Add specific local email-format guidance beside the field Enables correction Invalid email Low; avoid account-existence disclosure Small Direct copy evidence P1 Completion cannot be measured Instrument entry, authentication, creation, save, and list visibility Establishes a usable funnel Full path Minimize properties; exclude sensitive content Unknown until analytics inspected Confirmed data gap P1 Pending states unknown Inspect and explicitly label link-request and save progress Reduces uncertainty during waiting Loading Retain provider limits; do not blindly retry uncertain saves Small if existing hooks exist Documentation gap P2 Recovery outcomes unknown Document and test expiry, connection failure, and supported retry Reveals incomplete recovery paths Error/recovery Avoid bypasses and duplicate saves Unknown Documentation gap P2 Accessibility unknown Check labels, error association, focus, and status announcements Makes states perceivable and operable Input, loading, error Low Small targeted review Documentation gap P2 Optional setup may delay activation Inspect dependencies; defer display name if independent Removes one pre-activation decision Setup Check identity/role dependencies first Unknown Hypothesis only P3 For the four-hour developer allocation, address the two evidenced copy issues first, then verify their accessible error and recovery states. Instrumentation may need separate resources; do not assume it fits the remaining time. 7) Measurable funnel and instrumentation Use an approved pseudonymous session identifier, event timestamp, prototype version, attempt identifier, and documented new/existing-user classification where available. Mark classification unknown otherwise. Event name Trigger Required properties beyond common fields Success definition Exclusions access_entry_viewed Entry becomes usable Entry source category Entry rendered Bots and synthetic tests access_started First email interaction None Authentication attempt begun Repeated focus events magic_link_requested Provider accepts request Request outcome category Request accepted; not proof of delivery Rejected requests access_error Validation or authentication fails Step, safe error category Error recorded Email, link, token, raw server response authentication_succeeded Verified access established Documented account classification Authorized session established Access-screen views alone recovery_started Supported recovery initiated Recovery reason Recovery action begun Unsupported/inferred actions recovery_succeeded Access restored after tracked recovery Recovery reason Verified authorized access restored Unrelated later sign-ins setup_completed Setup submitted None Setup accepted Display-name content checklist_creation_started Sample-based creation begins Sample category, if needed Creation interface usable Repeated renders checklist_save_succeeded Persistence confirmed None Checklist saved Button clicks and uncertain responses activation_reached First saved checklist renders in own list None Save and visibility both confirmed Repeat activation and checklist content Recovery events require an implemented, documented recovery path. Measure an entry cohort over five weekdays, with the same five-weekday follow-up window per entrant. Wait for the final cohort member’s window to mature before comparing completion. Metric Numerator / denominator Access-start rate Unique starters / unique eligible entrants Authentication completion Unique authenticated users / unique starters Activation rate Unique newly activated users / eligible first-time entrants Post-authentication activation Unique newly activated users / authenticated first-time users Error frequency Attempts with an error / attempts at that step Recovery completion Successful tracked recovery episodes / started recovery episodes Time to activation Elapsed entry-to-activation time among activated users; report non-completers separately Separate attempt-level errors from user-level completion. Report existing users separately and unknown classifications explicitly. If no analytics capability exists, establish instrumentation before experiment decisions. 8) Controlled optimization experiments First collect the five-weekday baseline. Direct corrections to unusable error copy do not require preserving an unhelpful control solely for testing. Experiment Hypothesis and target group Control / variant Primary metric Safety metrics Duration and stopping logic Technical requirement Defer optional setup Hypothesis: removing the optional display-name step improves activation among first-time authenticated users Current setup / direct sample creation with name deferred Post-authentication activation Save errors, authorization failures, accessibility defects, support demand if tracked At least one complete five-weekday cycle plus follow-up; extend if evidence remains inconclusive. Stop for access or save regressions Confirm no dependency; stable assignment Explain email handoff Hypothesis: explaining the next action and 10-minute validity improves authentication completion Documented current handoff / explicit email-opening and expiry guidance Authentication completion Repeat-request frequency, throttling events, authentication errors, accessibility defects Same minimum cycle and follow-up; stop for harmful retry behavior or access regression Inspect current handoff first; preserve provider behavior Predefine decision thresholds from the observed baseline and acceptable safety limits. No sample size, significance, or conversion improvement can be specified from the supplied evidence. 9) Implementation handover Immediate Correct expired-link and invalid-email copy. Inspect the supported fresh-link route and preserve provider restrictions. Verify accessible error presentation using synthetic states. Confirm whether instrumentation exists and assign any missing work. After measurement data Identify the most frequent incomplete transition. Evaluate optional setup deferral. Decide whether the handoff experiment has sufficient traffic and evidence. Prioritize loading and recovery changes using observed failures. Only after security or legal review Changes to account-existence messaging, verification, throttling, lockout, sessions, or role access. Any proposed expansion of tracking beyond the approved minimal event plan. Acceptance criteria for the three highest-priority changes: Change Success Error Recovery Expired-link guidance A valid link still establishes authorized access Expired link states expiry and 10-minute validity; message is accessible Supported fresh-link route works and respects existing limits Email validation Valid-format email reaches the existing request flow Invalid format receives specific, associated guidance without account disclosure Correcting input permits another submission; resolved error clears Funnel instrumentation Activation fires once only after confirmed save and list visibility Failures record safe categories without sensitive contents Supported recovery start and success remain distinguishable from repeated attempts Responsible roles: product owns activation and experiment decisions; development owns state mapping and instrumentation feasibility; security owns provider and access-control questions; privacy/legal owns tracking requirements; design or accessibility review owns understandable, accessible feedback. Most important missing insight: which transition most often prevents first-time users from reaching a saved, visible checklist. Collect a deduplicated event funnel with five weekdays of entry cohorts and consistent follow-up before choosing an optimization experiment.