Measuring Period-for-Space Mis-taps in Browser Search Queries with Logs and User Research

On a touchscreen keyboard, when people type into a browser's input field, the period key and the space bar are placed so that people sometimes hit the period when they meant to type a space. The result is a stray dot in the middle of a search query, for example `coffee.shops near me` instead of `coffee shops near me`. How would you measure this problem and judge its impact, and how would you use user research to validate it? Typing a search query and typing a web address are different needs: a period between two words of a search query is usually a mistake, while a web address needs periods. The example query is illustrative. ### Clarifying Questions - Is the field the browser's combined address and search bar, or a search box on a web page? - What can be logged: individual key taps and deletions, only the submitted text, or only privacy-protected counts computed on the device? - Is a specific fix under consideration, such as moving the period key in browser fields? ### Part 1 — Measure how often it happens How would you detect and count these mis-taps in data, and how would you separate search queries from web addresses? ```hint Errors that get fixed A user who notices the stray dot deletes it. Think about what that leaves behind in keyboard events, and what an unnoticed dot leaves behind in what the browser does next. ``` #### What This Part Should Cover - A precise definition of the error, with detection signals for both corrected and uncorrected cases - Separating search intent from address intent, and excluding legitimate periods - A rate with a sensible denominator and a baseline for comparison ### Part 2 — Judge the impact How would you decide how much this problem matters? ```hint Not all errors cost the same Compare a dot the user deletes immediately with one that turns a search into a failed attempt to open a web address. ``` #### What This Part Should Cover - Reach, frequency and cost per occurrence - The segments where the problem concentrates - Comparison with other typing problems and with the risk of a fix ### Part 3 — Validate with user research How would you use user research to confirm the problem and its cause, and how many participants or respondents would you need? ```hint Discovery versus estimation The number of people needed to see that a problem exists is very different from the number needed to estimate how often it happens. ``` #### What This Part Should Cover - Research methods matched to the questions: cause, frequency, and how much users care - Sample size reasoning for discovering the problem, estimating its prevalence and comparing layouts - How research findings are combined with log data ### What a Strong Answer Covers - A measurable definition of the error that distinguishes searches from web addresses - Both corrected and uncorrected errors, each with its own cost - An impact estimate that combines reach, frequency and severity, broken down by segment - Research designed to explain why the error happens, with sample sizes justified by the research goal - Awareness that a fix for search typing can hurt address typing ### Follow-up Questions - A proposed fix moves the period key away from the space bar in browser fields. How would you test it, and what would you watch so that typing web addresses does not get worse? - Your log-based estimate of the error rate is three times your estimate from research sessions. How do you reconcile them? - How would you prioritize this problem against other typing errors the keyboard team could fix?