01. Overview
I spent over 2 years at Mozilla embedded as the lead designer on the Firefox Search and Suggest team. The Mozilla corporation (and therefore the foundation as well) generates the vast majority of its revenue through search monetization deals with our partner Google. As Firefox usership continues its slow and steady decline, driving metrics like address bar engagement and search volume is an imperative to help offset revenue loss from the decline of daily active users.
This was a complex multi-stream visual and experience enhancement project addressing various functionalities inside the Firefox address bar component. Because we were modifying highly visible and utilized aspects of the Firefox Search experience, we took additional precautions socializing with key internal stakeholders and our most passionate external stakeholders (often found on Mozilla Connect). Another significant complication on this project was how some individual enhancements had overlapping impacts on certain key interactions — this meant that certain enhancements really needed to be defined and released together rather than rolled out in phases and significantly iterated on to function well in each subsequent phase.
Given the significance of search to the company, we had a substantial body of user research we could call upon to influence and guide our decision-making, and I worked closely with our dedicated user researcher to ensure our design decisions and strategic hypotheses relied on and reflected the body of research we had built. I worked alongside our sponsoring Product Manager, our Engineering Manager, multiple engineers, User Research, Content Design, and QA to plan, define, and execute this project.
Projects
Unified Search Button
Intuitive Keywords
Quick Actions
Persistent Search Terms
HTTPS by default
Deliverables
Mid/High fidelity mocks
High fidelity prototypes
Usability testing
Accessibility documentation
Usability testing with assistive technology users
Slide decks for internal socialization
Key Outcomes
Search Counts increased (+1.1% to +1.5%)
Address bar engagements increased (+0.3% to +0.7%)
Tagged SAP Searches increased (+0.5% to +0.7%)
Organic Searches decreased (-0.1% to -0.5%)
Tools
Figma
UserTesting.com
MakeItFable.com
Role
Lead Product designer
Timeframe
1+ year
Problem summary
Within the search space, we consistently see satisfaction rates above 80% alongside qualitative data indicating that there remains room for improvement. The lack of dis-satisfaction with search actually makes identifying opportunities for improvement a fairly difficult task. Additionally, at Firefox we need to distinguish between the search experience (outsourced to our search engine partners) and the pre-search experience, where we have control.
An aside: For the purposes of my time at Mozilla, the pre-search experience is defined as from first interaction with the address bar through to when the user selects an action to take (such as a search suggestion from Google, a history suggestion from Firefox, or a direct navigational suggestion from Firefox to a relevant answer site such as Wikipedia).
Primary user objectives for search are fairly straightforward — users want to find what they’re looking for as quickly as possible. For a basic informational query, search generally meets or exceeds user expectations here. However this gets complicated for queries without a right or wrong answer or when a user is looking for a webpage they’ve previously accessed. In these more complicated scenarios, tweaks to the pre-search experience can facilitate easier search refinement and lead to more seamless task completion.
These tweaks should support task completion in a variety of ways — allowing users to seamlessly move between search engine queries and history search, facilitating quick adjustment of search terms, and (for power users) ensuring intuitive keyboard access to components and controls. It also means, where possible, the delivery of answers, actions, and controls directly to the context of the user.
An entirely different tact would be to take a more dynamic search term processing model, introducing results reactive to non-sensitive user data like days of use. For example our telemetry shows that in the first 30 days users are more likely to switch certain preferences or settings — we could add modifiers to our matching and ranking algorithms to help surface these early on. While our core algorithms were beyond the scope of this particular project, the search team is always actively exploring enhancements to our matching and ranking.
A note on digital accessibility
A moderate severity digital accessibility bug helped us as a team prioritize the Unified Search Button project as a partial fix. Digital accessibility in the address bar component is incredibly complicated, as the component itself is both highly customized and exceedingly high traffic. The address bar is a combo box component, but includes so much custom functionality that navigation inside the component has few documented best practices.
The best methodology for designing the accessibility of the component is co-creation with assistive technology users and user testing. We were lucky to collaborate with a fantastic accessibility team including James Teh and to work for an organization willing to provide the UX team with access to Fable user testing with assistive technology users.
That said, making the address bar component and all of it’s functionality as accessible as possible will continue to be an iterative process, reactive to both direct feedback from users and to changes in industry best practice at large competitors like Google Chrome and Microsoft Edge.
The work
Relying on our backlog of high quality user research, I helped identify a collection of four features to define and ship together, balancing user objectives, business needs, and resourcing constraints.
Unified Search Button
Intuitive Keywords
Quick Actions
Persistent Search Terms
HTTPS by default
I drove the definition of visual design, interaction design, keyboard navigation, validation testing, and accessibility testing. I also heavily supported internal and external socialization projects, including presentations to the Firefox Leadership Team.
02. Scope and Hypotheses
Unified Search Button
We hypothesized that the unified search button would increase the discoverability of our search engine selector functionality. Before this update, users were able to choose a search engine for a particular search by selecting the appropriate icon button from the bottom of the address bar dropdown.
User research revealed a common behavior for users to employ different search engines for different types of searches (many believed some search engines provided “better” results for certain search types). However, usage data for the existing feature was fairly low (possibly due to its diminished hierarchical positioning) suggesting that the feature had untapped value for our general population lost to low discoverability.
Discoverability was less an issue for our more advanced users. They leverage search engine switching in combination with custom search engines (user-added engines) to quickly search workflow related websites like Jira, MDN, or Github. It was important to us not to disturb their existing workflows and incorporate simple keyboard navigation alternatives to the mouse driven Search Button dropdown menu. Keyboard navigation, as well as hide/display logic were extensive conversations with engineering and our a11y team. Pairing the Unified Search Button with the Intuitive Keywords project also helped support alternative keyboard entry points to the functionality.
We expected the Unified Search button to drive increases to search engine switching behavior and local search mode use, reduce organic search (search from places other than the address bar), and increase address bar engagements.
Intuitive Keywords
Intuitive keywords allows users to type @ in the address bar followed by the name of a search engine, and select that engine for their search. Previously, Firefox only allowed what we called “restrict tokens” like *, %, or ^ which correspond to the local search modes bookmarks, tabs, and history respectively. These restrict tokens are fairly convenient for power users but also very difficult to remember. Intuitive keywords extended keyboard access to search engines (not just local search modes). We continued to maintain old restrict tokens to support power user workflows.
We expected that Intuitive Keywords would drive increases to search engine switching behavior and local search mode use, reduce organic search, and increase address bar engagements
Persistent Search Terms
Search refinement is a common behavior — a user types a query, doesn’t see the results they were looking for, and quickly re-formulates that query. This project persists the search term inside the address bar after the user lands on the search engine results page and allows the user to refine their query in the same place they formulated it. Additionally, when paired with the Unified Search Button this functionality provides quick access to the search engine switching technology, allowing a user to quickly recommit their search to a separate engine.
We expected that Persistent Search Terms would increase address bar engagements and refinements, and would support increases to search engine switching behavior when paired with the Unified Search Button.
Quick Actions
Quick actions are system functions like “Browser Restart” that users can access via the address bar. While these existed as part of the Firefox search functionality prior to this project, the visual design language was outdated, the keyword matching strategies rendered these actions fairly undiscoverable, and no one internally could speak to why or how we selected each function to be available here. This project updated the visual language, keyboard interactions, and keyword matching strategies for quick actions. Additionally, I conducted a thorough investigation of existing data and telemetry on browser functions and preferences to create a list of recommendations for modifying the list of available actions to bring them in line with the most commonly used functions and preferences.
We expected quick actions to increase (very incrementally) address bar engagements. The main objective here was to delight users. Users often query Google “How to [insert query] Firefox”. Quick actions could intercept these types of queries and provide resolution directly in context. A recent UR study had revealed that many users choose to search on Google.com simply because they don’t believe Firefox could offer anything above and beyond what google can do for web search. This was one concept for adding value to our address bar that Google (or other engines) couldn’t provide on Firefox via organic search.
HTTPS by default
HTTPS by default hides the “https” string in the URL, treating secure connections as defaults. Removing the secure protocol from the address bar increases the space for a user to see the full domain (important in the event of a URL with many sub-domains or just with a narrow browser window). In the current web environment, threats are more commonly from phishing websites with secure connections, making the domain name possibly the most important piece of information in the URL. In the event of an HTTP connection, we increased the visual prominence of our warnings, actually emphasizing insecure connections significantly more than we used to.
The above screenshots show the new treatment for http and https connections. Previously the connection protocol was always exposed. When an insecure connection was establish, this was only demarcated by a red diagonal line through the lock icon to the left of the addressbar. This new treatment establishes more clear hierarchy for insecure connections. One alternative (or complimentary) path worth considering is Google’s approach of moving away from icons implying security entirely. The reality in the current web environment is that many harmful phishing endeavors take place via a website with a secure connection and implying a secure connection is necessarily a trustworthy one is unhelpful and potentially misleading. This was a consideration we were exploring more in depth in a separate project which would also combine the information underneath the lock and shield icon to be beneath one singular icon button.
We did not expect HTTPS by default to generate measurable impact to key metrics, but believed the cleaner aesthetic (less complicated URL string) and enhancements to security were well worth the investment.
03. Outcomes
Business outcomes
Increased engagement
Engagement metrics increased across the board. We saw Search Counts and Address Bar Engagements go up, and we saw Organic Search rates decrease. Seeing these improvements trending around 0.8% to 1.2% feels quite significant with monthly active user counts over 150M. This was a complicated and highly visible project — being able to point to telemetry as a clear validation of our hypotheses felt like a significant win for our team.
Steady ad-click counts
Unfortunately, the one key metric which decreased slightly was ad click rate (though total ad click counts remained unchanged).
One hypothesis for why we didn’t see ad click rates increase proportionally with engagement is that this project drove about ~1.3% positive change in Default Search Engine Change (i.e. users choosing to search with DuckDuckGo as their default instead of Google). It’s possible that this search volume now taking place on different search engines simply doesn’t monetize as well as on Google. I think this likely explains a part of the small decrease in ad click rates.
Experience enhancements
As I mentioned above, primary user objectives for search are fairly straightforward — users want to find what they’re looking for as quickly as possible. These five enhancements, taken as a group, provide a multi-faceted improvement to the flexibility of the address bar component in the pre-search context and in search refinement and re-formulation. We’ve taken what has historically been viewed as a linear journey and incorporated controls that allow for real-life nuance.
Flexibility in pre-search
Improving discoverability of search engine controls directly responds to the found user sentiment that different search engines are better suited to different categories of search (in both accuracy, speed, precision, and privacy). Though the realities of such a statement can be debated, the user perception consistently appeared in our qualitative research. The Unified Search Button was easily discovered in usability testing and offers quick access to alternative search engines. Intuitive keywords lightens cognitive load by displaying all alternative engines with a single keystroke and filtering those down to a final selection as the user continues typing.
Enhanced Search Refinement
Telemetry data prior to this enhancements project clearly illustrated the incidence of search query reformulation. Persistent search terms and the unified search button together allow the user more flexibility in search reformulation than an organic search site is able to. Users can quickly switch from their default DuckDuckGo to Google if DDG fails to return the shopping results they were looking for, or from Google to DDG to carry on a more private search journey. Additionally, persisting search terms in the address bar ensures consistent keyboard access to search terms on any search engine via CTRL+L (or CMD+L on Mac), a common power user shortcut.
Unique Value in the Address Bar
Providing unique value in the address bar was an important component to a larger strategy of encouraging users to leverage Firefox Search Access Points over using organic search sites like Google.com. Modernizing the UI and keyboard interactions for Quick Actions, refining the list of functions we provide, and enhancing our keyword matching lists allowed us to begin to deliver on this strategy with fairly limited effort — we didn’t have to introduce an entirely new feature. Meanwhile, we had a larger effort moving parallel focused on delivering live data directly to the address bar for certain categories of search (sports data, finance data, etc). This parallel project required user opt-in, making opt-in rates a clear objective target metric for delivering unique value to the address bar.